My goal is to show you how to initially harden your server a bit by
configuring the SSH server and my enabling sudo. This can be both done
on new installations or on existing machines.
NOTE: I’m using ‘mpkossen’ as an example username here. Please replace it with a username of your choosing.
What you do here, is copy a public key (in this case .ssh/id_rsa.pub [indicated by -i], which is often the default name for an SSH key) to your server at 198.51.100.100. It then adds the public key to the .ssh/authorized_keys file on the server for the user you’ve used in the command. From this point on, you only need your SSH key to log in. Be sure to use a strong password for it and don’t leave it lying around, since it is the entrance to your server.
Next, login to the server. We’re going to tweak some SSH server settings to make it more secure. Open up /etc/ssh/sshd_config with an editor (vim, nano, or anything else). First, we’re going to disable password authentication. Look for the following line:
Now look for the following line:
Again, only as a non-root user with sudo privileges, run:
But why should you use sudo, because inconvenience in itself isn’t an argument. Sudo adds an extra layer of security. When you log in as root, the only thing you need is either your private key or your root password. When you’re in, you’re in and you can do everything you want. Sudo prevents that last part. If you use sudo and somebody manages to get hold of your private key, they can log into the server but still not do much to ruin it, since they haven’t got your password. That alone is, for me, enough reason to use sudo rather than log in as root.
There are additional reasons for using sudo, which are listed here. Not all of them are very strong, though.
So, let’s enable sudo for you. These are instructions for both Ubuntu and CentOS.
Next, add it to the sudo group:
Now the newly created user is all set up, log out and transfer the SSH key for this user (like we’ve done above):
Finally, remove root’s SSH authorized_keys:
Next, add sudo right to the user. Run ‘visudo’. It will open a file. Look for the following line:
Now the newly created user is all set up, log out and transfer the SSH key for this user (like we’ve done above):
Remove root’s SSH authorized_keys:
For now, get used to a life with sudo! It’s going to get annoying at some moments, but it is more secure.
NOTE: I’m using ‘mpkossen’ as an example username here. Please replace it with a username of your choosing.
Securing SSH
The first thing you should always do with a server, it upload your public key (that matches your private key) and enable password-less login. This will prevent people from guessing passwords to enter your server from ever succeeding. Let’s first upload the public key. From a terminal on a Linux or Mac OS machine, run:ssh-copy-id -i ~/.ssh/id_rsa.pub root@198.51.100.100It then asks for the password for the root user. Fill that in. Once that’s done, it gives you a notice telling what has happened.
What you do here, is copy a public key (in this case .ssh/id_rsa.pub [indicated by -i], which is often the default name for an SSH key) to your server at 198.51.100.100. It then adds the public key to the .ssh/authorized_keys file on the server for the user you’ve used in the command. From this point on, you only need your SSH key to log in. Be sure to use a strong password for it and don’t leave it lying around, since it is the entrance to your server.
Next, login to the server. We’re going to tweak some SSH server settings to make it more secure. Open up /etc/ssh/sshd_config with an editor (vim, nano, or anything else). First, we’re going to disable password authentication. Look for the following line:
#PasswordAuthentication yesAnd change it to:
PasswordAuthentication noThis disables password authentication and forces you to use only public keys. No worries, in case you ever loose your private key you can always access your server via an out-of-band console. In case you have a dedicated server without any out-of-band access, well, don’t loose your private key ;-)
Now look for the following line:
PermitRootLogin yesAnd change it to:
PermitRootLogin noThis disables logging in as root. When these things are done, we would usually restart SSH to get these changes live. However, this time, we need to make sure we have a non-root account with sudo access first. If you’ve installed Ubuntu on a KVM machine, this should already be the case and you can safely run the following command. WARNING: if you are currently logged in as root, do not log out, or you’ll have a nice trip to your console ;-)
Again, only as a non-root user with sudo privileges, run:
sudo /etc/init.d/ssh restartNow, if you’ve run this command, that’s it for you! Otherwise, head over to the next part.
Sudo
Sudo… the ground of quite some discussion. To many, sudo is an inconvenience. Rightly so, because inconvenience in security is good. If your security doesn’t annoy you ever, you’re either a very patient human being or your security isn’t good enough.But why should you use sudo, because inconvenience in itself isn’t an argument. Sudo adds an extra layer of security. When you log in as root, the only thing you need is either your private key or your root password. When you’re in, you’re in and you can do everything you want. Sudo prevents that last part. If you use sudo and somebody manages to get hold of your private key, they can log into the server but still not do much to ruin it, since they haven’t got your password. That alone is, for me, enough reason to use sudo rather than log in as root.
There are additional reasons for using sudo, which are listed here. Not all of them are very strong, though.
So, let’s enable sudo for you. These are instructions for both Ubuntu and CentOS.
Ubuntu
Logged in as root, make sure sudo is installed first:apt-get install sudoOnce that is done, add a new user:
adduser mpkossenThis will ask you for the password twice, make sure you pick a strong one. It then asks some additional questions like you name, room number, etc. Fill these out to your liking. Once done, you need to confirm the information after which your user was created.
Next, add it to the sudo group:
usermod -a -G sudo mpkossenThe above command modifies the user. It adds it to the group(s) mentioned by using -G. The -a is for append. If you wouldn’t use -a, the user would only be in the sudo group, causing all kinds of different problems.
Now the newly created user is all set up, log out and transfer the SSH key for this user (like we’ve done above):
ssh-copy-id -i ~/.ssh/id_rsa.pub mpkossen@198.51.100.100Finally, log in to the server to disable the root account and clean up. First, disable the root account:
sudo passwd -dl rootWhat you do here, is delete the root password (-d) and lock the account (-l). From this point on, logging in a root is impossible, even via the CLI.
Finally, remove root’s SSH authorized_keys:
rm -rf /root/.sshAnd you’re done! From now on, commands that require root access should be prefixed with sudo and you will be asked for your password.
CentOS
Logged in as root, make sure sudo is installed first:yum install sudoOnce that is done, add a new user:
adduser mpkossenAnd add a password to the user:
passwd mpkossenThis will ask you for the password twice, make sure you pick a strong one.
Next, add sudo right to the user. Run ‘visudo’. It will open a file. Look for the following line:
root ALL=(ALL) ALLAdd the following line under it:
root ALL=(ALL) ALLNow, save the file and exit. What you just did was ensure that user ‘mpkossen’ can run any command as any user (even as root).
mpkossen ALL=(ALL) ALL
Now the newly created user is all set up, log out and transfer the SSH key for this user (like we’ve done above):
ssh-copy-id -i ~/.ssh/id_rsa.pub mpkossen@198.51.100.100Finally, log in to the server to lock the root account and clean up. First, disable the root account:
sudo passwd -l rootWhat you did here is lock (-l) the root account. You could optionally delete (-d) the password first. CentOS doesn’t like combining -d and -l, though.
Remove root’s SSH authorized_keys:
rm -rf /root/.sshAnd you’re done! From now on, commands that require root access should be prefixed with sudo and you will be asked for your password.
Final notes
Now, with the above, you’ve definitely made your server more secure. Other good security practices would add to this one, though. Like keeping a strong password and changing it regularly. The same goes for your SSH key. A good firewall is a must as well, but that is something for a future guide!For now, get used to a life with sudo! It’s going to get annoying at some moments, but it is more secure.