In the following instructions, we'll look at the procedures for “hardening” your DigitalOcean Droplet, making it more difficult for malicious hackers to compromise your server.
Here are the steps we will cover:
- Create a new, alternative user to
- Grant this new user administrative privileges.
- Disable SSH access from the
- How to run commands as an administrator as your new user.
- Install fail2ban to block repeated, failed, login attempts.
Create a new user
root user on your account has the highest priveleges; because of that, if a hacker gains access to your server as the
root user, they have a lot of power to do a lot of harm.
Because of this, we're going to disable
root from being able to SSH in to your server.
Before we do that, though, we need to create a new, alternative user that can SSH into your server.
Begin by SSH'ing into your Droplet as
$ ssh root@your-droplet-ip-address
Next we'll use the command
adduser followed by a username of your choice.
During this procedure, you'll be prompted to create a password for this new user. Strong passwords are essential to prevent brute force attacks (where a machine is used to try and guess your password). If you're not confident in your ability to generate a secure password, use a password generator tool.
With your password chosen, initiate the new user (replace
susanbuck with a username of your choosing):
$ adduser susanbuck
The process will look like this:
Adding user 'susanbuck' ... Adding new group 'susanbuck' (1000) ... Adding new user 'susanbuck' (1000) with group 'susanbuck' ... Creating home directory '/home/susanbuck' ... Copying files from '/etc/skel' ... Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully Changing the user information susanbuck Enter the new value, or press ENTER the default Full Name : Susan Buck Room Number : Work Phone : Home Phone : Other : Is the information correct? [Y/n] y
Give your new user admin privileges
Next, we want to give your new user administrator privileges.
While still signed in as the root user, run:
This command uses nano to open the files that controls your server's
sudoers (more on
Search for the line that looks like this:
root ALL=(ALL:ALL) ALL
Below that line, add new line that looks like the following (replace
susanbuck with your username):
susanbuck ALL=(ALL:ALL) ALL
Save your changes (
y, then Enter).
SSH access for your new user
When you first set up DigitalOcean, you created a SSH key connection between your computer and your server. This allowed you to SSH into your Droplet as
root, without having to enter a password.
You'll want the same convenience/security that SSH keys provide for your new user as well, so let's set that up.
(In the following steps, it's assumed that you've already created a public key (
id_rsa.pub) on your local machine when you first followed the Git setup notes.)
Open a new Terminal/Cmder window, so we can grab your public key from your local machine, without losing your connection to your Droplet.
In the new window, on your local computer, get the contents of your
id_rsa.pub file using the cat command.
$ cat ~/.ssh/id_rsa.pub
$ cat C:\Users\YourName\.ssh\id_rsa.pub
The output will look something like this:
ssh-rsa [LONG STRING OF RANDOM CHARACTERS] email@example.com
Select the entire public key and copy it.
Switch back to the Terminal/Cmder window that's SSH'd into your Droplet as
root and run the following command to switch to your new user (replace
susanbuck with your username):
$ su - susanbuck
Your new user does not have any SSH settings yet, so let's start by creating a new
$ mkdir ~/.ssh
For security purposes, we'll make it so only you (i.e. the user you're logged in as) can Read, Write or Execute this directory, by setting the permissions to
$ chmod 700 ~/.ssh
(Permissions are beyond the scope of these notes; if interested, you can learn more here.)
authorized_keys using nano:
$ nano ~/.ssh/authorized_keys
Paste in your public key which you copied above from your local computer.
Save your changes to
authorized_keys and exit (
y, then Enter).
Finally, we'll alter the permissions on
authorized_keys to make sure no other user can edit it. We'll use the permission code
600 which will allow just your user to Read and Write to this file (Execute is not needed since it's a file, not a directory).
$ chmod 600 ~/.ssh/authorized_keys
To confirm the above steps worked, first log out of your new user account:
Then log out of your Droplet:
Then try to SSH back in as your new user:
$ ssh yourusername@your-droplet-ip-address
If everything went well, you should be logged in again.
New SSH key for Github
Your new user will want to communicate with Github, so lets set up a new SSH key pair. You've followed these procedures a couple times now (when first setting up DigitalOcean, when first connecting to Github), so here's the express version of what you need to do:
While logged in as your new user, generate a new key pair:
$ ssh-keygen -t rsa -C "firstname.lastname@example.org"
Output the resulting public key:
$ cat ~/.ssh/id_rsa.pub
Copy the output from the above, and in Github.com -> Settings -> SSH Keys add this new key.
At this point, you might be acquiring quite a collection of keys in Github, so you may want to choose a descriptive name for this key such as:
User: [username], DigitalOcean Droplet: [droplet name]
After the key is added, confirm it's working with:
$ ssh -T email@example.com
SSH Key Cheat Sheet
If you're having a hard time wrapping your head around the various SSH key pairs we've set up in this course, check out this SSH Keys Cheat Sheet.
Using administrative privileges with sudo
You're now logged in as your new user, and this new user has administrative privileges.
However, you'll notice that if you try to do some action that requires admin privileges, you won't be able to.
For example, try to run this command to view
$ cat /var/log/auth.log
You should see this message:
cat: /var/log/auth.log: Permission denied
This doesn't seem to make sense— didn't we just give our new user administrative privileges in the steps above?
We did! However, in order to utilize these privileges, we need to prefix commands with
sudo (/ˈsuːduː/ or /ˈsuːdoʊ/) is a program for Unix-like computer operating systems that allows users to run programs with the security privileges of another user, by default the superuser. The name is a contraction of "do as su" where "su" is an abbreviation for "super user." -ref
Moving forward, if you ever try a command and are told you don't have permissions, try the command again but prefix it with
Change ownership of /var/www/html
If you try to edit files in your
/var/www/html as your new user, you'll run into permission issues because that directory is owned by
root. You can get around permission issues using the
sudo command, as described above, but to make things easier, you can instead change the ownership of that directory to belong to your new user, with the following command.
susanbuck with your username.
$ sudo chown -R susanbuck /var/www/html
-R flag is making this command recursive, so it will change the ownership for only for
/var/www/html but everything inside of it.
Disable root access
Now that you've confirmed you can SSH in as your new user, it's safe to disable
root from SSH'ing into the server.
This is done via the config file,
sshd_config in nano with admin privileges (i.e. prefix with
$ sudo nano /etc/ssh/sshd_config
Once the file is opened, look for the line
PermitRootLogin yes and toggle
When done, save and exit (
y, then Enter).
To make this change take effect, run the following command to restart your SSH services:
$ sudo service ssh restart
Note how that command was again prefixed with
sudo since restarting SSH is something only an administrator can do.
Confirm root user no longer has SSH access
Let's just confirm the above changes worked and the
root user can no longer SSH into your Droplet.
In a new Terminal/Cmder window, try to SSH in as root:
$ ssh root@your-server-ip-address
You'll note that it will now continually ask for a password, instead of just letting you in as it previously did with your SSH keys set up. Even if you had the password, it would still not let you in.
You might look at this whole procedure and think we're chasing our tails. We prevented the
root user from logging in because it's dangerous because
root has administrative privileges.
But, we also created a new user that also had administrative privileges.
Isn't this just as bad?
It's not, and the reason is because hackers target
root. They know many, many servers start with a default admin login with the username
root, and not all server admins will go to the trouble to disable
root. Because of this, they target their attacks on
root since it provides them the greatest payoff.
By using a non-default username, you're greatly decreasing the chances a hacker will brute force enter your server.
Ban failed login attempts
There's a file on your server,
/var/log/auth.log, which logs authorization requests on your server.
Take a look at its contents:
$ sudo cat /var/log/auth.log
If you look at this file that's been running on a server for even a short time, you'd be amazed by how many outside login attempts are being thrown at your server by malicious hackers you don't know.
You'll likely see lots of login attempts for
root, and other random user names as well. If you look up the IP address for these login attempts, you'll also see they're coming from all over the world.
root access and using SSH keys, we've reduced the chances these malicious login attempts will work, however, we can take it one step further by banning the IP addresses of machines that have repeated, failed, login attempts.
This is done using a software module called Fail2Ban. DigitalOcean has a full write up on how to use Fail2Ban, but below are the express instructions.
Tell apt-get to get the latest updates:
$ sudo apt-get update
$ sudo apt-get install fail2ban
Make a copy of the default configs so you can make any needed updates:
$ sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
$ sudo service fail2ban restart
Note that with fail2ban implemented, you do stand the chance of accidentally banning yourself from your own server if you have too many failed login attempts.
The default threshold for getting banned is 6 failed login attempts.
If that happens, you will not be able to login from your banned IP address for the default time of 600 seconds (10 minutes).
Note that these default settings can all be adjusted in your
/etc/fail2ban/jail.local config file. In that file, you can also “whitelist” your IP address so it will not get banned. If your network provider uses dynamic IPs, however, this change will not be permanent.
Take a Snapshot of your Current Configuration
You've now put a fair amount of work in to configuring your Droplet. Given that, you should take advantage of DigitalOcean's Snapshot feature.
whoami command can be used now (or anytime) to tell you who you're logged in as. This can be useful if you're switching between root and your new user
To update your user password, use the
What users exist?
To see what users exist on your server, run
Note that in addition to the new user you created above, and
root, there are many other default users on your server. These users do not have full administrator privileges like you and
Disabling password logins
As an extra level of security, you can completely disable the ability for users to SSH into your server with a password, requiring all logins to have a SSH key. This will eliminate the possibility of a hacker entering your server via a password guessing brute force attack.
We don't suggest this approach in the above steps, because in a class environment, it can be useful to have password logins available (for example, if you need to give a TA or instructor access to your server).
In a real-world environment, however, it's a good approach, so below are the steps to make that happen:
$ sudo nano /etc/ssh/sshd_config
Find this line:
Change it to this:
Save and exit.
sudo service ssh restart
Locked yourself out?
Once you've implemented the above security steps, it's possible you may accidentally lock yourself out of your own account. For example, if you trip fail2ban with too many failed login attempts, or you accidentally delete your private key.
If this happens, you can still login to your Droplet using DigitalOcean's web-based Console Access to fix whatever situation caused you to become locked out.