Introduction
So, you've got your very own VPS. Now what? In this article, we will see how we can secure it and make it usable. With this initial setup out of the way, you can then focus on what you actually want to do with the server. But first, a few assumptions. I'll assume that you have with you a server with Ubuntu 18.04 installed and you're using either password-based or key-based authentication to get root access to your server. And the IP address of your server, for the purpose of this article, will be 1.2.3.4. Mentally replace 1.2.3.4 with your server's IP address.
Setup public key authentication
We tend to chose easy passwords, especially when we know we'll need to enter them many times. Also, passwords are easy to crack. Keys, on the other hand, are long and random and therefore are very hard to bruteforce. Ideally, you'd want to disable password-based authentication completely and log in using key-based authentication only.
Create a public-private keypair for future use :
ssh-keygen -t ed25519 -f mykey
The command above will create 2 files :
- mykey : Private key. Keep this one private. DON'T share this with anybody!
- mykey.pub : Public key. You'll need to upload contents of this file to your server.
Login using root credentials (just this one time!)
If you've got root password with you, use that to log in to your account :
ssh root@1.2.3.4
Or, if you added your public key while you created the server, use it :
ssh -i ~/.ssh/mykey.pub root@1.2.3.4
Once you're logged into the server, move ahead.
Turn that firewall on
It's a jungle out there. Automated bots will start hammering your server in no time trying to get access. Think of your server as an exclusive club. And imagine every Tom, Dick and Harry is trying to get in. So what do you do? You put a bouncer at the front door who will only allow people with proper credentials. The same goes with your server. We will put UFW between your server and the outside world.
But before we turn on the firewall, we must first allow SSH traffic to come in. If you don't do this, you'll be locked out of your server :
ufw limit ssh
Now enable UFW :
ufw enable
Check status of your firewall :
ufw status verbose
Update! Update! Update!
Seriously. Update regularly. Security patches are released frequently and you really don't want to be late applying those patches. Most of the hacks happen because people use outdated, unpatched software.
apt update
apt upgrade
Create a non-root user
Operating as root is dangerous. One wrong command and your entire system can get wrecked. It's beneficial to operate as a 'normal' user who can use sudo when needed.
Create a new user named foo :
adduser foo
Add user foo to the group sudo :
usermod -aG sudo foo
If you used public key authentication to log in to root, add your public key to /home/foo/.ssh/authorized_keys file :
mkdir /home/foo/.ssh/
cp /root/.ssh/authorized_keys /home/foo/.ssh/
chown -R foo:foo /home/foo/.ssh/
Or, if you used password to log in to your server, copy and paste your public key content in /home/foo/.ssh/authorized_keys file :
mkdir /home/foo/.ssh/
vim /home/foo/.ssh/authorized_keys
chown -R foo:foo /home/foo/.ssh/
chmod o-rwx /home/foo/.ssh/
Restart your server :
sudo reboot
Login only using non-root user
From now on, log in using only the non-root user that you created in the last section.
ssh -i ~/.ssh/mykey foo@1.2.3.4
Harden your SSH config
SSH server is pretty secure by default but you can go one step further and harden SSH configuration even more. Mozilla's Modern SSH Configuration can provide high security in latest OpenSSH server instance. You'll need to add following config to /etc/ssh/sshd_config file.
# Supported HostKey algorithms by order of preference.
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
# Password based logins are disabled - only public key based logins are allowed.
AuthenticationMethods publickey
# LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.
LogLevel VERBOSE
# Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.
Subsystem sftp /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO
# Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user:
#
# On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH.
# Additionally, only tools such as systemd and auditd record the process session id.
# On other OSes, the user session id is not necessarily recorded at all kernel-side.
# Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.
PermitRootLogin No
# Use kernel sandbox mechanisms where possible in unprivileged processes
# Systrace on OpenBSD, Seccomp on Linux, seatbelt on MacOSX/Darwin, rlimit elsewhere.
UsePrivilegeSeparation sandbox