One place for hosting & domains

      Server

      How To Set Up a Video Streaming Server using Nginx-RTMP on Ubuntu 20.04


      Introduction

      There are many use cases for streaming video. Service providers such as Twitch are very popular for handling the web discovery and community management aspects of streaming, and free software such as OBS Studio is widely used for combining video overlays from multiple different stream sources in real time. While these platforms are very powerful, in some cases you may want to be able to host a stream that does not rely on other service providers.

      In this tutorial, you will learn how to configure the Nginx web server to host an independent RTMP video stream that can be linked and viewed in different applications. RTMP, the Real-Time Messaging Protocol, defines the fundamentals of most internet video streaming. You will also learn how to host HLS and DASH streams that support more modern platforms using the same technology.

      Prerequisites

      To complete this guide, you will need:

      This tutorial will use the placeholder domain name your_domain for URLs and hostnames. Substitute this with your own domain name or IP address as you work through the tutorial.

      Step 1 — Installing and Configuring Nginx-RTMP

      Most modern streaming tools support the RTMP protocol, which defines the basic parameters of an internet video stream. The Nginx web server includes a module that allows you to provide an RTMP stream with minimal configuration from a dedicated URL, just like it provides HTTP access to web pages by default. The Nginx RTMP module isn’t included automatically with Nginx, but on Ubuntu 20.04 and most other Linux distributions you can install it as an additional package.

      Begin by running the following commands as a non-root user to update your package listings and install the Nginx module:

      • sudo apt update
      • sudo apt install libnginx-mod-rtmp

      Installing the module won’t automatically start providing a stream. You’ll need to add a configuration block to your Nginx configuration file that defines where and how the stream will be available.

      Using nano or your favorite text editor, open Nginx’s main configuration file, /etc/nginx/nginx.conf, and add this configuration block to the end of the file:

      • sudo nano /etc/nginx/nginx.conf

      /etc/nginx/nginx.conf

      . . .
      rtmp {
              server {
                      listen 1935;
                      chunk_size 4096;
                      allow publish 127.0.0.1;
                      deny publish all;
      
                      application live {
                              live on;
                              record off;
                      }
              }
      }
      
      • listen 1935 means that RTMP will be listening for connections on port 1935, which is standard.
      • chunk_size 4096 means that RTMP will be sending data in 4KB blocks, which is also standard.
      • allow publish 127.0.0.1 and deny publish all mean that the server will only allow video to be published from the same server, to avoid any other users pushing their own streams.
      • application live defines an application block that will be available at the /live URL path.
      • live on enables live mode so that multiple users can connect to your stream concurrently, a baseline assumption of video streaming.
      • record off disables Nginx-RTMP’s recording functionality, so that all streams are not separately saved to disk by default.

      Save and close the file. If you are using nano, press Ctrl+X, then when prompted, Y and Enter.

      This provides the beginning of your RTMP configuration. By default, it listens on port 1935, which means you’ll need to open that port in your firewall. If you configured ufw as part of your initial server setup run the following command.

      Now you can reload Nginx with your changes:

      • sudo systemctl reload nginx.service

      You should now have a working RTMP server. In the next section, we’ll cover streaming video to your RTMP server from both local and remote sources.

      Step 2 — Sending Video to Your RTMP Server

      There are multiple ways to send video to your RTMP server. One option is to use ffmpeg, a popular command line audio-video utility, to play a video file directly on your server. If you don’t have a video file already on the server, you can download one using youtube-dl, a command line tool for capturing video from streaming platforms like YouTube. In order to use youtube-dl, you’ll need an up to date Python installation on your server as well.

      First, install Python and its package manager, pip:

      • sudo apt install python3-pip

      Next, use pip to install youtube-dl:

      Now you can use youtube-dl to download a video from YouTube. If you don’t have one in mind, try this video, introducing DigitalOcean’s App Platform:

      • youtube-dl https://www.youtube.com/watch?v=iom_nhYQIYk

      You’ll see some output as youtube-dl combines the video and audio streams it’s downloading back into a single file – this is normal.

      Output

      [youtube] iom_nhYQIYk: Downloading webpage WARNING: Requested formats are incompatible for merge and will be merged into mkv. [download] Destination: Introducing App Platform by DigitalOcean-iom_nhYQIYk.f137.mp4 [download] 100% of 32.82MiB in 08:40 [download] Destination: Introducing App Platform by DigitalOcean-iom_nhYQIYk.f251.webm [download] 100% of 1.94MiB in 00:38 [ffmpeg] Merging formats into "Introducing App Platform by DigitalOcean-iom_nhYQIYk.mkv" Deleting original file Introducing App Platform by DigitalOcean-iom_nhYQIYk.f137.mp4 (pass -k to keep) Deleting original file Introducing App Platform by DigitalOcean-iom_nhYQIYk.f251.webm (pass -k to keep)

      You should now have a video file in your current directory with a title like Introducing App Platform by DigitalOcean-iom_nhYQIYk.mkv. In order to stream it, you’ll want to install ffmpeg:

      And use ffmpeg to send it to your RTMP server:

      • ffmpeg -re -i "Introducing App Platform by DigitalOcean-iom_nhYQIYk.mkv" -c:v copy -c:a aac -ar 44100 -ac 1 -f flv rtmp://localhost/live/stream

      This ffmpeg command is doing a few things to prepare the video for a streaming-friendly format. This isn’t an ffmpeg tutorial, so you don’t need to examine it too closely, but you can understand the various options as follows:

      • -re specifies that input will be read at its native framerate.
      • -i "Introducing App Platform by DigitalOcean-iom_nhYQIYk.mkv" specifies the path to our input file.
      • -c:v is set to copy, meaning that you’re copying over the video format you got from YouTube natively.
      • -c:a has other parameters, namely aac -ar 44100 -ac 1, because you need to resample the audio to an RTMP-friendly format. aac is a widely supported audio codec, 44100 hz is a common frequency, and -ac 1 specifies the first version of the AAC spec for compatibility purposes.
      • -f flv wraps the video in an flv format container for maximum compatibility with RTMP.

      The video is sent to rtmp://localhost/live/stream because you defined the live configuration block in Step 1, and stream is an arbitrarily chosen URL for this video.

      Note: You can learn more about ffmpeg options from ffmprovisr, a community-maintained catalog of ffmpeg command examples, or refer to the official documentation.

      While ffmpeg is streaming the video, it will print timecodes:

      Output

      frame= 127 fps= 25 q=-1.0 size= 405kB time=00:00:05.00 bitrate= 662.2kbits/s speed=frame= 140 fps= 25 q=-1.0 size= 628kB time=00:00:05.52 bitrate= 931.0kbits/s speed=frame= 153 fps= 25 q=-1.0 size= 866kB time=00:00:06.04 bitrate=1173.1kbits/s speed=

      This is standard ffmpeg output. If you were converting video to a different format, these might be helpful in order to understand how efficiently the video is being resampled, but in this case, you just want to see that it’s being played back consistently. Using this sample video, you should get exact fps= 25 increments.

      While ffmpeg is running, you can connect to your RTMP stream from a video player. If you have VLC, mpv, or another media player installed locally, you should be able to view your stream by opening the URL rtmp://your_domain/live/stream in your media player. Your stream will terminate after ffmpeg has finished playing the video. If you want it to keep looping indefinitely, you can add -stream_loop -1 to the beginning of your ffmpeg command.

      Note: You can also stream directly to, for example, Facebook Live using ffmpeg without needing to use Nginx-RTMP at all by replacing rtmp://localhost/live/stream in your ffmpeg command with rtmps://live-api-s.facebook.com:443/rtmp/your-facebook-stream-key. YouTube uses URLs like rtmp://a.rtmp.youtube.com/live2. Other streaming providers that can consume RTMP streams should behave similarly.

      Now that you’ve learned to stream static video sources from the command line, you’ll learn how to stream video from dynamic sources using OBS on a desktop.

      Step 3 — Streaming Video to Your Server via OBS (Optional)

      Streaming via ffmpeg is convenient when you have a prepared video that you want to play back, but live streaming can be much more dynamic. The most popular software for live streaming is OBS, or Open Broadcaster Software – it is free, open source, and very powerful.

      OBS is a desktop application, and will connect to your server from your local computer.

      After installing OBS, configuring it means customizing which of your desktop windows and audio sources you want to add to your stream, and then adding credentials for a streaming service. This tutorial will not be covering your streaming configuration, as it is down to preference, and by default, you can have a working demo by just streaming your entire desktop. In order to set your streaming service credentials, open OBS’ settings menu, navigate to the Stream option and input the following options:

      Streaming Service: Custom
      Server: rtmp://your_domain/live
      Play Path/Stream Key: obs_stream
      

      obs_stream is an arbitrarily chosen path – in this case, your video would be available at rtmp://your_domain/live/obs_stream. You do not need to enable authentication, but you do need to add an additional entry to the IP whitelist that you configured in Step 1.

      Back on the server, open Nginx’s main configuration file, /etc/nginx/nginx.conf, and add an additional allow publish entry for your local IP address. If you don’t know your local IP address, it’s best to just go to a site like What’s my IP which can tell you where you accessed it from:

      • sudo nano /etc/nginx/nginx.conf

      /etc/nginx/nginx.conf

      . . .
                      allow publish 127.0.0.1;
                      allow publish your_local_ip_address;
                      deny publish all;
      . . .
      

      Save and close the file, then reload Nginx:

      • sudo systemctl reload nginx.service

      You should now be able to close OBS’ settings menu and click Start Streaming from the main interface! Try viewing your stream in a media player as before. Now that you’ve seen the fundamentals of streaming video in action, you can add a few other features to your server to make it more production-ready.

      Step 4 — Adding Monitoring to Your Configuration (Optional)

      Now that you have Nginx configured to stream video using the Nginx-RTMP module, a common next step is to enable the RTMP statistics page. Rather than adding more and more configuration details to your main nginx.conf file, Nginx allows you to add per-site configurations to individual files in a subdirectory called sites-available/. In this case, you’ll create one called rtmp:

      • sudo nano /etc/nginx/sites-available/rtmp

      Add the following contents:

      /etc/nginx/sites-available/rtmp

      server {
          listen 8080;
          server_name  localhost;
      
          # rtmp stat
          location /stat {
              rtmp_stat all;
              rtmp_stat_stylesheet stat.xsl;
          }
          location /stat.xsl {
              root /var/www/html/rtmp;
          }
      
          # rtmp control
          location /control {
              rtmp_control all;
          }
      }
      

      Save and close the file. The stat.xsl file from this configuration block is used to style and display an RTMP statistics page in your browser. It is provided by the libnginx-mod-rtmp library that you installed earlier, but it comes zipped up by default, so you will need to unzip it and put it in the /var/www/html/rtmp directory to match the above configuration. Note that you can find additional information about any of these options in the Nginx-RTMP documentation.

      Create the /var/www/html/rtmp directory, and then uncompress the stat.xsl.gz file with the following commands:

      • sudo mkdir /var/www/html/rtmp
      • sudo gunzip -c /usr/share/doc/libnginx-mod-rtmp/examples/stat.xsl.gz > /var/www/html/rtmp/stat.xsl`

      Finally, to access the statistics page that you added, you will need to open another port in your firewall. Specifically, the listen directive is configured with port 8080, so you will need to add a rule to access Nginx on that port. However, you probably don’t want others to be able to access your stats page, so it’s best only to allow it for your own IP address. Run the following command:

      • sudo ufw allow from your_ip_address to any port http-alt

      Next, you’ll need to activate this new configuration. Nginx’s convention is to create symbolic links (like shortcuts) from files in sites-available/ to another folder called sites-enabled/ as you decide to enable or disable them. Using full paths for clarity, make that link:

      • sudo ln -s /etc/nginx/sites-available/rtmp /etc/nginx/sites-enabled/rtmp

      Now you can reload Nginx again to process your changes:

      • sudo systemctl reload nginx.service

      You should now be able to go to http://your_domain:8080/stat in a browser to see the RTMP statistics page. Visit and refresh the page while streaming video and watch as the stream statistics change.

      You’ve now seen how to monitor your video stream and push it to third party providers. In the final section, you’ll learn how to provide it directly in a browser without the use of third party streaming platforms or standalone media player apps.

      Step 5 — Creating Modern Streams for Browsers (Optional)

      As a final step, you may want to add support for newer streaming protocols so that users can stream video from your server using a web browser directly. There are two protocols that you can use to create HTTP-based video streams: Apple’s HLS and MPEG DASH. They both have advantages and disadvantages, so you will probably want to support both.

      The Nginx-RTMP module supports both standards. To add HLS and DASH support to your server, you will need to modify the rtmp block in your nginx.conf file. Open /etc/nginx/nginx.conf using nano or your preferred editor, then add the following highlighted directives:

      • sudo nano /etc/nginx/nginx.conf

      /etc/nginx/nginx.conf

      . . .
      rtmp {
              server {
      . . .
                      application live {
                              live on;
                              record off;
                              hls on;
                              hls_path /var/www/html/stream/hls;
                              hls_fragment 3;
                              hls_playlist_length 60;
      
                              dash on;
                              dash_path /var/www/html/stream/dash;
                      }
              }
      }
      . . .
      

      Save and close the file. Next, add this to the bottom of your sites-available/rtmp:

      • sudo nano /etc/nginx/sites-available/rtmp

      /etc/nginx/sites-available/rtmp

      . . .
      server {
          listen 8088;
      
          location / {
              add_header Access-Control-Allow-Origin *;
              root /var/www/html/stream;
          }
      }
      
      types {
          application/dash+xml mpd;
      }
      

      Note: The Access-Control-Allow-Origin * header enables CORS, or Cross-Origin Resource Sharing, which is disabled by default. This communicates to any web browsers accessing data from your server that the server may load resources from other ports or domains. CORS is needed for maximum compatibility with HLS and DASH clients, and a common configuration toggle in many other web deployments.

      Save and close the file. Note that you’re using port 8088 here, which is another arbitrary choice for this tutorial to ensure we aren’t conflicting with any services you may be running on port 80 or 443. You’ll want to open that port in your firewall for now too:

      Finally, create a stream directory in your web root to match the configuration block, so that Nginx can generate the necessary files for HLS and DASH:

      • sudo mkdir /var/www/html/stream

      Reload Nginx again:

      • sudo systemctl reload nginx

      You should now have an HLS stream available at http://your_domain:8088/hls/stream.m3u8 and a DASH stream available at http://your_domain:8088/dash/stream.mpd. These endpoints will generate any necessary metadata on top of your RTMP video feed in order to support modern APIs.

      Conclusion

      The configuration options that you used in this tutorial are all documented in the Nginx RTMP Wiki page. Nginx modules typically share common syntax and expose a very large set of configuration options, and you can review their documentation to change any of your settings from here.

      Nearly all internet video streaming is implemented on top of RTMP, HLS, and DASH, and by using the approach that you have explored in this tutorial, you can provide your stream via other broadcasting services, or expose it any other way you choose. Next, you could look into configuring Nginx as a reverse proxy in order to make some of these different video endpoints available as subdomains.



      Source link

      Initial Server Setup with Debian 11


      Not using Debian 11?


      Choose a different version or distribution.

      Introduction

      When you first create a new Debian 11 server, there are a few configuration steps that you should take early on as part of the basic setup. This will increase the security and usability of your server and will give you a solid foundation for subsequent actions.

      In this tutorial, we will learn how to log into our server as the root user, create a new user with admin privileges, and set up a basic firewall.

      Step 1 — Logging in as Root

      To log into your server, you will need to know your server’s public IP address. You will also need the password or, if you installed an SSH key for authentication, the private key for the root user’s account. If you have not already logged into your server, you may want to follow our guide on how to connect to your Droplet with SSH, which covers this process in detail.

      If you are not already connected to your server, go ahead and log in as the root user using the following command (substitute the highlighted portion of the command with your server’s public IP address):

      Accept the warning about host authenticity if it appears. If you are using password authentication, provide your root password to log in. If you are using an SSH key that is passphrase protected, you may be prompted to enter the passphrase the first time you use the key each session. If this is your first time logging into the server with a password, you may also be prompted to change the root password.

      About Root

      The root user is the administrative user in a Linux environment that has very broad privileges. Because of the heightened privileges of the root account, you are discouraged from using it on a regular basis. This is because part of the power inherent with the root account is the ability to make very destructive changes, even by accident.

      The next step is to set up an alternative user account with a reduced scope of influence for day-to-day work. Later, we’ll explain how to gain increased privileges for those times when you need them.

      Step 2 — Creating a New User

      Once you are logged in as root, we’re prepared to add the new user account that we will use to log in from now on.

      This example creates a new user called sammy, but you should replace it with a username that you like:

      You will be asked a few questions, starting with the account password.

      Enter a strong password and, optionally, fill in any of the additional information you would like. This is not required and you can just hit ENTER in any field you wish to skip.

      Next, we’ll set up this new user with admin privileges.

      Step 3 — Granting Administrative Privileges

      Now, we have created a new user account with regular account privileges. However, we may sometimes need to do administrative tasks with it.

      To avoid having to log out of our normal user and log back in as the root account, we can set up what is known as superuser or root privileges for our normal account. This will allow our normal user to run commands with administrative privileges by putting the word sudo before the command.

      To add these privileges to our new user, we need to add the new user to the sudo group. By default, on Debian 11, users who belong to the sudo group are allowed to use the sudo command.

      As root, run this command to add your new user to the sudo group (substitute the highlighted word with your new user):

      Now, when logged in as your regular user, you can type sudo before commands to run the command with superuser privileges.

      Step 4 — Setting Up a Basic Firewall

      Debian servers can use firewalls to make sure only certain connections to specific services are allowed. In this guide, we will install and use the UFW firewall to help set firewall policies and manage exceptions.

      We can use the apt package manager to install UFW. Update the local index to retrieve the latest information about available packages and then install the UFW firewall software by typing:

      • apt update
      • apt install ufw

      Note: If your servers are running on DigitalOcean, you can optionally use DigitalOcean Cloud Firewalls instead of the UFW firewall. We recommend using only one firewall at a time to avoid conflicting rules that may be difficult to debug.

      Firewall profiles allow UFW to manage named sets of firewall rules for installed applications. Profiles for some common software are bundled with UFW by default and packages can register additional profiles with UFW during the installation process. OpenSSH, the service allowing us to connect to our server now, has a firewall profile that we can use.

      You list all available application profiles by typing:

      Output

      Available applications: . . . OpenSSH . . .

      We need to make sure that the firewall allows SSH connections so that we can log back in next time. We can allow these connections by typing:

      Afterwards, we can enable the firewall by typing:

      Type y and press ENTER to proceed. You can see that SSH connections are still allowed by typing:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6)

      As the firewall is currently blocking all connections except for SSH, if you install and configure additional services, you will need to adjust the firewall settings to allow acceptable traffic in. You can learn some common UFW operations in our UFW essentials guide.

      Step 5 — Enabling External Access for Your Regular User

      Now that we have a regular user for daily use, we need to make sure we can SSH into the account directly.

      Note: Until verifying that you can log in and use sudo with your new user, we recommend staying logged in as root. This way, if you have problems, you can troubleshoot and make any necessary changes as root. If you are using a DigitalOcean Droplet and experience problems with your root SSH connection, you can also log into the Droplet using the DigitalOcean Console.

      The process for configuring SSH access for your new user depends on whether your server’s root account uses a password or SSH keys for authentication.

      If the Root Account Uses Password Authentication

      If you logged in to your root account using a password, then password authentication is enabled for SSH. You can SSH to your new user account by opening up a new terminal session and using SSH with your new username:

      After entering your regular user’s password, you will be logged in. Remember, if you need to run a command with administrative privileges, type sudo before it like this:

      You will be prompted for your regular user password when using sudo for the first time each session (and periodically afterwards).

      To enhance your server’s security, we strongly recommend setting up SSH keys instead of using password authentication. Follow our guide on setting up SSH keys on Debian 11 to learn how to configure key-based authentication.

      If the Root Account Uses SSH Key Authentication

      If you logged in to your root account using SSH keys, then password authentication is disabled for SSH. You will need to add a copy of your local public key to the new user’s ~/.ssh/authorized_keys file to log in successfully.

      Since your public key is already in the root account’s ~/.ssh/authorized_keys file on the server, we can copy that file and directory structure to our new user account in our existing session with the cp command. Afterwards, we can adjust ownership of the files using the chown command.

      Make sure to change the highlighted portions of the command below to match your regular user’s name:

      • cp -r ~/.ssh /home/sammy
      • chown -R sammy:sammy /home/sammy/.ssh

      The cp -r command copies the entire directory to the new user’s home directory, and the chown -R command changes the owner of that directory (and everything inside it) to the specified username:groupname (Debian creates a group with the same name as your username by default).

      Now, open up a new terminal session and log in via SSH with your new username:

      You should be logged in to the new user account without using a password. Remember, if you need to run a command with administrative privileges, type sudo before it like this:

      You will be prompted for your regular user password when using sudo for the first time each session (and periodically afterwards).

      Where To Go From Here?

      At this point, you have a solid foundation for your server. You can install any of the software you need on your server now.



      Source link

      Initial Server Setup with Rocky Linux 8


      Not using Rocky Linux 8?


      Choose a different version or distribution.

      Introduction

      When you first create a new Rocky Linux 8 server, there are a few configuration steps that you should take early on as part of the basic setup. This will increase the security and usability of your server and will give you a solid foundation for subsequent actions.

      Step 1 — Logging in as Root

      To log into your server, you will need to know your server’s public IP address. You will also need the password or, if you installed an SSH key for authentication, the private key for the root user’s account. If you have not already logged into your server, you may want to follow our documentation on how to connect to your Droplet with SSH, which covers this process in detail.

      If you are not already connected to your server, log in as the root user now using the following command (substitute the highlighted portion of the command with your server’s public IP address):

      Accept the warning about host authenticity if it appears. If you are using password authentication, provide your root password to log in. If you are using an SSH key that is passphrase protected, you may be prompted to enter the passphrase the first time you use the key each session. If this is your first time logging into the server with a password, you may also be prompted to change the root password.

      About Root

      The root user is the administrative user in a Linux environment, and it has very broad privileges. Because of the heightened privileges of the root account, you are discouraged from using it on a regular basis. This is because part of the power inherent with the root account is the ability to make very destructive changes, even by accident.

      As such, the next step is to set up an alternative user account with a reduced scope of influence for day-to-day work. This account will still be able to gain increased privileges when necessary.

      Step 2 — Creating a New User

      Once you are logged in as root, you can create the new user account that we will use to log in from now on.

      This example creates a new user called sammy, but you should replace it with any username that you prefer:

      Next, set a strong password for the sammy user:

      You will be prompted to enter the password twice. After doing so, your user will be ready to use, but first we’ll give this user additional privileges to use the sudo command. This will allow us to run commands as root when necessary.

      Step 3 — Granting Administrative Privileges

      Now, we have a new user account with regular account privileges. However, we may sometimes need to perform administrative tasks.

      To avoid having to log out of our regular user and log back in as the root account, we can set up what is known as “superuser” or root privileges for our regular account. This will allow our regular user to run commands with administrative privileges by putting the word sudo before each command.

      To add these privileges to our new user, we need to add the new user to the wheel group. By default, on Rocky Linux 8, users who belong to the wheel group are allowed to use the sudo command.

      As root, run this command to add your new user to the wheel group (substitute the highlighted word with your new username):

      Now, when logged in as your regular user, you can type sudo before commands to perform actions with superuser privileges.

      Step 4 — Setting Up a Basic Firewall

      Firewalls provide a basic level of security for your server. These applications are responsible for denying traffic to every port on your server, except for those ports/services you have explicitly approved. Rocky Linux has a service called firewalld to perform this function. A tool called firewall-cmd is used to configure firewalld firewall policies.

      Note: If your servers are running on DigitalOcean, you can optionally use DigitalOcean Cloud Firewalls instead of firewalld. We recommend using only one firewall at a time to avoid conflicting rules that may be difficult to debug.

      First install firewalld:

      The default firewalld configuration allows ssh connections, so we can turn the firewall on immediately:

      • systemctl start firewalld

      Check the status of the service to make sure it started:

      • systemctl status firewalld

      Output

      ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2020-02-06 16:39:40 UTC; 3s ago Docs: man:firewalld(1) Main PID: 13180 (firewalld) Tasks: 2 (limit: 5059) Memory: 22.4M CGroup: /system.slice/firewalld.service └─13180 /usr/libexec/platform-python -s /usr/sbin/firewalld --nofork --nopid

      Note that it is both active and enabled, meaning it will start by default if the server is rebooted.

      Now that the service is up and running, we can use the firewall-cmd utility to get and set policy information for the firewall.

      First let’s list which services are already allowed:

      • firewall-cmd --permanent --list-all

      Output

      public (active) target: default icmp-block-inversion: no interfaces: eth0 eth1 sources: services: cockpit dhcpv6-client ssh ports: protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules:

      To see the additional services that you can enable by name, type:

      • firewall-cmd --get-services

      To add a service that should be allowed, use the --add-service flag:

      • firewall-cmd --permanent --add-service=http

      This would add the http service and allow incoming TCP traffic to port 80. The configuration will update after you reload the firewall:

      Remember that you will have to explicitly open the firewall (with services or ports) for any additional services that you may configure later.

      Step 5 — Enabling External Access for Your Regular User

      Now that we have a regular non-root user for daily use, we need to make sure we can use it to SSH into our server.

      Note: Until verifying that you can log in and use sudo with your new user, we recommend staying logged in as root. This way, if you have problems, you can troubleshoot and make any necessary changes as root. If you are using a DigitalOcean Droplet and experience problems with your root SSH connection, you can log into the Droplet using the DigitalOcean Console.

      The process for configuring SSH access for your new user depends on whether your server’s root account uses a password or SSH keys for authentication.

      If the Root Account Uses Password Authentication

      If you logged in to your root account using a password, then password authentication is enabled for SSH. You can SSH to your new user account by opening up a new terminal session and using SSH with your new username:

      After entering your regular user’s password, you will be logged in. Remember, if you need to run a command with administrative privileges, type sudo before it like this:

      You will be prompted for your regular user password when using sudo for the first time each session (and periodically afterwards).

      To enhance your server’s security, we strongly recommend setting up SSH keys instead of using password authentication. Follow our guide on setting up SSH keys on Rocky Linux 8 to learn how to configure key-based authentication.

      If the Root Account Uses SSH Key Authentication

      If you logged in to your root account using SSH keys, then password authentication is disabled for SSH. You will need to add a copy of your public key to the new user’s ~/.ssh/authorized_keys file to log in successfully.

      Since your public key is already in the root account’s ~/.ssh/authorized_keys file on the server, we can copy that file and directory structure to our new user account.

      The simplest way to copy the files with the correct ownership and permissions is with the rsync command. This will copy the root user’s .ssh directory, preserve the permissions, and modify the file owners, all in a single command. Make sure to change the highlighted portions of the command below to match your regular user’s name:

      Note: The rsync command treats sources and destinations that end with a trailing slash differently than those without a trailing slash. When using rsync below, be sure that the source directory (~/.ssh) does not include a trailing slash (check to make sure you are not using ~/.ssh/).

      If you accidentally add a trailing slash to the command, rsync will copy the contents of the root account’s ~/.ssh directory to the sudo user’s home directory instead of copying the entire ~/.ssh directory structure. The files will be in the wrong location and SSH will not be able to find and use them.

      • rsync --archive --chown=sammy:sammy ~/.ssh /home/sammy

      Now, back in a new terminal on your local machine, open up a new SSH session with your non-root user:

      You should be logged in to the new user account without using a password. Remember, if you need to run a command with administrative privileges, type sudo before it like this:

      You will be prompted for your regular user password when using sudo for the first time each session (and periodically afterwards).

      Conclusion

      At this point, you have a solid foundation for your server. You can install any of the software you need on your server now.



      Source link