One place for hosting & domains

      Setup

      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

      How To Execute Ansible Playbooks to Automate Server Setup


      Introduction

      Ansible is a modern configuration management tool that facilitates the task of setting up and maintaining remote servers. With a minimalist design intended to get users up and running quickly, it allows you to control one to hundreds of systems from a central location with either playbooks or ad hoc commands.

      While ad hoc commands allow you to run one-off tasks on servers registered within your inventory file, playbooks are typically used to automate a sequence of tasks for setting up services and deploying applications to remote servers. Playbooks are written in YAML, and can contain one or more plays.

      This short guide demonstrates how to execute Ansible playbooks to automate server setup, using an example playbook that sets up an Nginx server with a single static HTML page.

      Prerequisites

      In order to follow this guide, you’ll need:

      • One Ansible control node. This guide assumes your control node is an Ubuntu 20.04 machine with Ansible installed and configured to connect to your Ansible hosts using SSH keys. Make sure the control node has a regular user with sudo permissions and a firewall enabled, as explained in our Initial Server Setup guide. To set up Ansible, please follow our guide on How to Install and Configure Ansible on Ubuntu 20.04.
      • One or more Ansible hosts. An Ansible host is any machine that your Ansible control node is configured to automate. This guide assumes your Ansible hosts are remote Ubuntu 20.04 servers. Make sure each Ansible host has:
        • The Ansible control node’s SSH public key added to the authorized_keys of a system user. This user can be either root or a regular user with sudo privileges. To set this up, you can follow Step 2 of How to Set Up SSH Keys on Ubuntu 20.04.
      • An inventory file set up on the Ansible control node. Make sure you have a working inventory file containing all your Ansible hosts. To set this up, please refer to the guide on How To Set Up Ansible Inventories.

      Once you have met these prerequisites, run a connection test as outlined in our guide on How To Manage Multiple Servers with Ansible Ad Hoc Commands to make sure you’re able to connect and execute Ansible instructions on your remote nodes. In case you don’t have a playbook already available to you, you can create a testing playbook as described in the next section.

      Creating a Test Playbook

      To try out the examples described in this guide, you’ll need an Ansible playbook. We’ll set up a testing playbook that installs Nginx and sets up an index.html page on the remote server. This file will be copied from the Ansible control node to the remote nodes in your inventory file.

      Create a new file called playbook.yml in the same directory as your inventory file. If you followed our guide on how to create inventory files, this should be a folder called ansible inside your home directory:

      • cd ~/ansible
      • nano playbook.yml

      The following playbook has a single play and runs on all hosts from your inventory file, by default. This is defined by the hosts: all directive at the beginning of the file. The become directive is then used to indicate that the following tasks must be executed by a super user (root by default).

      It defines two tasks: one to install required system packages, and the other one to copy an index.html file to the remote host, and save it in Nginx’s default document root location, /var/www/html. Each task has tags, which can be used to control the playbook’s execution.

      Copy the following content to your playbook.yml file:

      ~/ansible/playbook.yml

      ---
      - hosts: all
        become: true
        tasks:
          - name: Install Packages
            apt: name={{ item }} update_cache=yes state=latest
            loop: [ 'nginx', 'vim' ]
            tags: [ 'setup' ]
      
          - name: Copy index page
            copy:
              src: index.html
              dest: /var/www/html/index.html
              owner: www-data
              group: www-data
              mode: '0644'
            tags: [ 'update', 'sync' ]
      
      

      Save and close the file when you’re done. Then, create a new index.html file in the same directory, and place the following content in it:

      ~/ansible/index.html

      <html>
          <head>
              <title>Testing Ansible Playbooks</title>
          </head>
          <body>
              <h1>Testing Ansible Playbooks</h1>
              <p>This server was set up using an Nginx playbook.</p>
          </body>
      </html>
      

      Don’t forget to save and close the file.

      Executing a Playbook

      To execute the testing playbook on all servers listed within your inventory file, which we’ll refer to as inventory throughout this guide, you may use the following command:

      • ansible-playbook -i inventory playbook.yml

      This will use the current system user as remote SSH user, and the current system user’s SSH key to authenticate to the nodes. In case those aren’t the correct credentials to access the server, you’ll need to include a few other parameters in the command, such as -u to define the remote user or --private-key to define the correct SSH keypair you want to use to connect. If your remote user requires a password for running commands with sudo, you’ll need to provide the -K option so that Ansible prompts you for the sudo password.

      More information about connection options is available in our Ansible Cheatsheet guide.

      Listing Playbook Tasks

      In case you’d like to list all tasks contained in a playbook, without executing any of them, you may use the --list-tasks argument:

      • ansible-playbook -i inventory playbook.yml --list-tasks

      Output

      playbook: nginx.yml play #1 (all): all TAGS: [] tasks: Install Packages TAGS: [setup] Copy index page TAGS: [sync, update]

      Tasks often have tags that allow you to have extended control over a playbook’s execution. To list current available tags in a playbook, you can use the --list-tags argument as follows:

      • ansible-playbook -i inventory playbook.yml --list-tags

      Output

      playbook: nginx.yml play #1 (all): all TAGS: [] TASK TAGS: [setup, sync, update]

      Executing Tasks by Tag

      To only execute tasks that are marked with specific tags, you can use the --tags argument, along with the tags that you want to trigger:

      • ansible-playbook -i inventory playbook.yml --tags=setup

      Skipping Tasks by Tag

      To skip tasks that are marked with certain tags, you may use the --exclude-tags argument, along with the names of tags that you want to exclude from execution:

      • ansible-playbook -i inventory playbook.yml --exclude-tags=setup

      Starting Execution at Specific Task

      Another way to control the execution flow of a playbook is by starting the play at a certain task. This is useful when a playbook execution finishes prematurely, in which case you might want to run a retry.

      • ansible-playbook -i inventory playbook.yml --start-at-task=Copy index page

      Limiting Targets for Execution

      Many playbooks set up their target as all by default, and sometimes you want to limit the group or single server that should be the target for that setup. You can use -l (limit) to set up the target group or server in that play:

      • ansible-playbook -l dev -i inventory playbook.yml

      Controlling Output Verbosity

      If you run into errors while executing Ansible playbooks, you can increase output verbosity in order to get more information about the problem you’re experiencing. You can do that by including the -v option to the command:

      • ansible-playbook -i inventory playbook.yml -v

      If you need more detail, you can use -vv or -vvv instead. If you’re unable to connect to the remote nodes, use -vvvv to obtain connection debugging information:

      • ansible-playbook -i inventory playbook.yml -vvvv

      Conclusion

      In this guide, you’ve learned how to execute Ansible playbooks to automate server setup. We’ve also seen how to obtain information about playbooks, how to manipulate a playbook’s execution flow using tags, and how to adjust output verbosity in order to obtain detailed debugging information in a play.



      Source link