Technology

This is part 1 of the Initial Setup of a Debian 10 server on Digital Ocean.

This is a complement to Initial Server Setup with Debian 10 over on the DigitalOcean tutorials page. The tutorial linked provides an excellent base setup for your to springboard off of on to your own customer setup. That being said, there are always settings, configurations, and utilities that will be helpful for almost any setup. Some of the information below comes from How To Secure A Linux Server and The Book of Secret Knowledge (this is one of favourite repos).

Note: I will do my best to introduce anything that we change so that you can understand what that change might affect. All setups are different so don’t install or configure anything that you don’t need or want. This will just lead to you forgetting about it, it becoming outdated and a security issue.

Text that is highlighted with purple text should be updated with your specific values.

Logging In

If you’re a Windows user then I recommend Solar-PuTTY as a Command Line Client. (Shout to Greg for the find). Otherwise you can use the built-in terminal on your MacOS or Linux OS. Here is how we connect to our server via command line interface (CLI).

 justin@home:/$ ssh root@111.133.134.199

Replace the IP Address with the IP of your new server.

At this point you’ll either a) be asked for the password that you set for the root account or b) the server will be expecting an SSH key if you chose to use SSH keys for logging in. If correct, you’ll be logged in.

Creating a User and Granting Administrator Privileges

You should only use the root account in special circumstances. It’s recommended that you create a standard account that has the ability to elevate to have administrative privileges, when necessary. We’re going to create a secondary account called bastion and then we’ll add it to the sudo group.

 justin@home:/$ adduser bastion
     Adding user `bastion' ...
     Adding new group `bastion' (1000) ...
     Adding new user `bastion' (1000) with group `bastion' ...
     Creating home directory `/home/bastion' ...
     Copying files from `/etc/skel' ...
       New password: <Enter Password>
       Retype new password: <Re-enter Password>
     passwd: password updated successfully
     Changing the user information for bastion
     Enter the new value, or press ENTER for the default
        Full Name []: Bastion
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
     Is the information correct? [Y/n] Y

You’ll be prompted to set and confirm a password on the new account. You can optionally add information such as a Room Number and Home Phone to the account.

 justin@home:/$ usermod -aG sudo bastion     

The usermod command allows us to modify existing accounts. We use the -a switch to append to the account, and the -G switch allows us to to select the Group(s) in which to append to the account. Members of the sudo group (superuser do) are able to run commands with the security privileges of another user. By default, it’s the superuser account.

Now we can append sudo to the beginning of our commands when logged in as bastion. Commands that make system changes, including software installs and uninstalls require elevated privilege that a standard account normally wouldn’t have.

Setting Up The Uncomplicated Firewall

A basic firewall goes a long way. Uncomplicated Firewall or UFW is a simple software firewall for Linux. Let’s install it, and then add a firewall rule for SSH so that we can still access it remotely.

justin@home:/$ apt install ufw

 justin@home:/$ sudo apt install ufw

 justin@home:/$ sudo ufw app list
 
 justin@home:/$ sudo ufw allow OpenSSH

 justin@home:/$ sudo ufw enable
 Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
 Firewall is active and enabled on system startup 

Once you’ve enabled UFW with that last command it will present you with a warning about losing your current SSH connection. As long as you allowed the OpenSSH app on line 3 above, you’re good. You can use the command sudo ufw status numbered to see the currently listed rules.

 justin@home:~# sudo ufw status numbered
 Status: active

      To                         Action      From
      --                         ------      ----
 [ 1] OpenSSH                    ALLOW IN    Anywhere
 [ 2] OpenSSH (v6)               ALLOW IN    Anywhere (v6)

Copying Existing SSH Keys

SSH is attacked all the time. It’s very, very common. If you’ve setup your accounts with SSH keys already, then you may wish to skip the next couple of sections. If you’re going to use the same SSH Keys that you created for your root account, read on.

SSH keys on the root account are stored at ~/.ssh/authorized_keys on your server. If you plan on using the same SSH keys on your bastion account you can simply copy this file over to your bastion account home directory and update the permissions of the .ssh folder recursively. (When copying from your root user, login as your root user)

 justin@home:/$ cp -r ~/.ssh /home/bastion
 

 justin@home:/$ chown -R bastion:bastion /home/bastion/.ssh

Creating SSH Keys (Using PuttyGen)

If you don’t have any SSH keys currently, or wish to create a new set a SSH keys for this new bastion user, we’ll use PuTTY Key Generator to do that. The image below shows the sequence of buttons you’ll press.

First, click the generate button. The Key window asks you to move your mouse around the blank Key area, randomly. This provides a pseudo-random input, kind of like an initial password to create the SSH key with. Once that’s done it will generate a key!

The Key fingerprint and Key comment are already filled in. A Key passphrase adds an additional layer of security to your SSH Key by requiring a passphrase every time that it’s used. The passphrase is optional, but may secure your SSH keys from being used, if they are ever stolen.

Copy the text in the ‘Public key for pasting into OpenSSH authorized_keys file’ field to a Notepad. Click Save public key and Save private key to save the respective key(s) to your computer. The file extensions don’t matter in this instance, however, you may wish to use the following extensions on your key files:

id_rsa.pub (Public Key)
id_rsa.key or id_rsa.ppk (Private Key)

Keep these safe and secure. Make sure that you keep backups.

Create a third-file called authorized_keys and paste the text that you saved in Notepad, previously.

Uploading SSH Keys

The easiest way to copy SSH keys to your server is by using the ssh-copy-id command, however, ssh-copy-id isn’t available on Windows. I’ll show you the ssh-copy-id way of uploading your SSH public key to your new server, as well as the scp command (Secure Copy).

SSH-copy-id

The ssh-copy-id command is by far the easiest method of moving your SSH public key from your local machine, to your new server. It handles all of the dirty work for us. Dirty work that you’ll see in the scp command below it.

 justin@home:/$ ssh-copy-id -i ~/.ssh/authorized_keys root@111.133.134.199



 justin@home:/$ ssh-copy-id -i ~/.ssh/authorized_keys bastion@111.133.134.199

 # We can also not utilize the -i switch and ssh-copy-id will attempt to find your keys for you, automatically.

 justin@home:/$ ssh-copy-id bastion@111.133.134.199    

The ssh-copy-id command requires very little input. I’ve given it a path to my SSH public key, and then I finish the command with my root login @ my new server. You’ll be prompted for your password after pressing enter. Once it completes your public key will be dropped in the ~/.ssh/authorized_keys file for the user that you logged in with. This example is uploading a public key for the root user.

SCP (Secure CoPy)

Unlike ssh-copy-id, the secure copy (scp) command is available on both the Windows Command Prompt, and PowerShell. Also, unlike ssh-copy-id, the scp command will completely overwrite your authorized_keys file with the contents of your public key.

 justin@home:/$ scp C:\Users\Justin\.ssh\authorized_keys root@111.133.134.199:~/.ssh/

SSH Copy

Here is a third example of copying SSH keys to your server using the SSH command. This is the most explicit way of copying your SSH keys as you are going to be piping several simpler commands together.

 justin@home:/$ cat C:\Users\Justin\.ssh\id_rsa.pub | ssh root@111.133.134.199 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >>  ~/.ssh/authorized_keys"

Secure Remote SSH

By default, the SSH service allows everyone to attempt to connect to it, and to attempt to login with a username and password. Since we’re now using SSH Keys for all of the potential remote users on our server there are several configurations that we now must do in order to secure SSH.

• Disable Root Logins Using Passwords
• Disable Password Authentication
• Change the default SSH port

All of our the configuration for the SSH service is contained within /etc/ssh/sshd_config. Open that file with nano or your favourite editor and change the following settings. I’ve placed a comment character (#) next to the old setting.

# Port 22
Port 2222

# PermitRootLogin yes
PermitRootLogin without-password

# PasswordAuthentication may not be listed in your sshd_config file. If it’s missing, simply add the configuration line to the end of the file.
# PasswordAuthentication yes
PasswordAuthentication no

After you save ssd_config, you’ll want to allow traffic to the new port before restarting the SSH service.

 justin@home:/$ ufw allow 2222/tcp
 
 justin@home:/$ service ssh restart

You might be wondering why we’re changing the default SSH port? SSH is a commonly attacked service with the default port being 22. Servers and computers connected to the Internet are constantly being scanned to find out if this port is open. Changing the port doesn’t prevent attacks, but it adds an extra layer of difficulty as an attacker would need to identify the correct port and adjust their attacks appropriately. It’s not worth the effort to focus on one such server.

We’ll be digging into some more in depth system settings in part 2.

I highly recommend DigitalOcean if you’re looking for discount VPS.