Hardening Your Hosting Environment (without killing yourself) Step 3: SSH Obfuscating

Security Through ObscuritySo far, you have updated your packages and configured your firewall for statefully packet inspection, now we get to the final step. The last, and by no means the least important, step would be some manner of obfuscating your SSH access.  There are a few great ways to do this, many of which far beyond the scope of this article, however I will at least discuss the ones that keep managing the server at its easiest without leaving your server open to an easy attack.

Far and away the easiest method of this (even if it does fall into the category of ‘security by obscurity’) would be simply changing the SSH port.  This can be found in your sshd_config located in /etc/ssh/.  Uncomment the following line:

#Port 22

and change 22 to whichever port you desire.  Once you restart the SSH daemon with the following command you will be able to use the new port:

service sshd restart

For the most security you will want to keep the port number below 1024 as only root can bind a port under this value.  It is CRUCIALLY important that you update your firewall configuration to allow access on the port you have chosen, otherwise you will lock yourself out which is pretty embarrassing.

Changing the SSH port is a good practice on any server on which the service is utilized, however this still leaves quite a bit open.  For instance, an attacker can still scan your ports with relative ease to find the one that is serving SSH, rendering the change moot.  You are still protected from the bots that crawl large blocks of IP space looking for a server that is open on port 22, but the approach is mostly meaningless should an attacker actively pursue access to your server.  Another vulnerability that is unsolved by changing the SSH port would be that the initial handshake (which includes your root password) is not encrypted.  Anybody who can scan packets that are routed to your server can capture this data to retrieve your root password, and the only way to mitigate this is to simply not send your root password over the air without encryption.  The two most common options for covering this would be wheel users and SSH keys.  Being the easier of the two both in terms of setup as well as continued management, I tend towards recommending wheel users as a means of keeping your root credentials protected.  By disabling root logins in your SSH configuration and creating a separate user who has access to little other than SSH and the su command you have successfully kept your root password from being transferred over the air without encryption, and adding a new user is as easy as two commands:

useradd new_user
passwd new_user

No really, that’s about it.  The first command creates the user, and the second one gives it a new password.  Now you can log in to SSH using the new_user that we’ve just created, and use the su command to change to root:

su -

The hyphen in this case causes you to inherit root’s environment variables, which is necessary to access many items not allowed to less privileged users.

Don’t get me wrong about the simplicity of this process, there are plenty of great methods of making this even more secure (such as ensuring the new user has access to nothing but the su command), however they would be outside the scope of this document.  I should hope that by now the topic of password strength has been beaten far beyond death, however don’t ever let this lull you into being lazy with your passwords.  Far more embarrassing than locking yourself out of a machine due to an SSH port misconfiguration, losing your server to an attacker because of a weak password has the additional injuries of a costly server rebuild to add to the initial insult.  It is for reasons such as this that I believe any article penned by a Systems Administrator should always mention a good backup strategy.  For if it’s not stated implicitly, you can always bet that the topic of backups is thoroughly permeated throughout the subtext.