Top SSH Security Best Practices

SSH is a common system administration utility for Linux servers.  Whether you’re running CentOS, Debian, Ubuntu, or anything in between; if you’ve logged into a Linux server before, you likely have at least heard of it.
The acronym SSH stands for “Secure Socket Shell”, and as the name implies, the protocol is built with security in mind.  Many server administrators assume that SSH is pretty secure out of the box, and for the most part, they’d be correct. SSH by default has fantastic security features out of the box, like encryption of the communication to prevent man in the middle attacks, and also host key verification to alert the user if the identity of the server has changed since they last logged in.
Still, there are a large number of servers on the Internet running SSH, and attackers like to find attack vectors that could potentially affect a large number of servers.  With security, convenience tends to be sacrificed, so many server administrators intentionally, or without much thought, leave their servers running default SSH installations.  For the most part, this isn’t an issue for most of them, but there are some steps that you can take to be ahead of the curve. After all, I believe that being a little bit ahead of the curve is one of the best security practices to reach for, that way your server avoids being one of the lower hanging fruit that can be tempting to attackers.
With that in mind, here are some techniques that you may want to consider for your Linux server to help improve your SSH security.

Brute Force Protection

One of the most common techniques for improving SSH security is brute force protection.  This is because one of the most common security concerns faced by server administrators running SSH services is brute force attacks from automated bots.  Bots will try to guess usernames and passwords on the server, but brute force protection can automatically ban their IP address after a set amount of failures.
A few common open source brute force protection solutions are ConfigServer Firewall (CSF) and Fail2Ban.  CSF is most common on cPanel servers, since it has a WHM plugin.

Pros and Cons of Brute Force Protection

Pros

• Will help to cut down on failed logins from bots by automatically banning them, making it much less likely that a bot will have the opportunity to guess the login details for one of your SSH accounts.
• Very easy to implement with no changes to the SSH configuration required.

Cons

• These brute force programs have no way to tell bots apart from you and your users.  If you fail login too many times by accident, you could lock yourself out. Make sure that you have a reliable means to get on to the server if this happens, such as whitelisting your own IP address, and having a KVM or IPMI console available as a last resort measure.

Changing The SSH Port Number

One of the most common techniques that I see is changing the SSH port number to something other than the default port, 22/tcp.  
This change is relatively simple to make, for example, if you wanted to change your SSH port from 22 to 2222, you would simply need to update the Port line of your sshd_config file like so:
Port 2222
By the way, port 2222 is a pretty common “alternate” port, so some of the brute force bots may still try this port.  It would be better to choose something more random, like 2452. It doesn’t even have to contain a 2, your SSH port could be 6543 if you wanted it to be.  Any port number up to 65535 that is not used by another program on the server is fair game.

Pros and Cons of Changing The SSH Port Number

Pros

• This technique is usually pretty effective at cutting down automated bot attacks.  Most of these are unintelligent scripts and will only be looking for servers running on port 22.

Cons

• This technique amounts to “security by obscurity”.  A bot that is trying alternate ports, or any human equipped with a port scanning tool like nmap will have no problem finding your server’s new port in just a few minutes.
• This technique can make the SSH server a bit more inconvenient to access, as you will now need to specify the port number when connecting instead of just the IP.

Disabling Root Login via SSH

Another common technique is to disable the root user account from logging in via SSH altogether, or without an authorized SSH key.  You can still have root access via SSH by granting “sudo” privileges to one of your limited users, or using the “su” command to switch to the root account with a password.
This can be configured by adjusting the “PermitRootLogin” setting in your sshd_config file.
To allow root login with SSH key only, you would change the line to:
PermitRootLogin without-password
To completely disallow root login via SSH, you would change the line to:
PermitRootLogin no

Pros and Cons of Disabling Root Login via SSH

Pros

• This technique is somewhat helpful, since the username “root” is common to most LInux servers (like “Administrator” on Windows servers), so it is easy to guess.  Disabling this account from logging in now means that the attacker must also guess a username correctly to be able to gain access.
• If you are not using sudo, this technique puts root access behind a second password, requiring an attacker to know or guess two passwords correctly before having full access to the server.  (Sudo can diminish this benefit somewhat as usually it is configured to allow root access with the same password that the user used to login.)

Cons

• This method may increase your risk of getting locked out of the server, in the event that something goes wrong with your sudo configuration.  It is still a good idea in this method to have an alternate way to access the server if you become locked out of root, such as a remote console.

Disabling Password Authentication, in favor of key authentication.

The first thing that everyone tells you about passwords is to make them long, difficult to guess, and not based on dictionary words.  An SSH key can replace password authentication with authentication by a key file.
SSH keys are very secure compared to a password, as they contain a large amount of random data.  If you have ever seen an SSL certificate or key file, an SSH key looks similar to this. It’s a very large string of random characters.
Instead of typing a password to login to the SSH server, you will authenticate using this key file, in much the same way that SSL certificates on websites work.
If you would like to disable password authentication, you can do so by modifying the “PasswordAuthentication” setting in the sshd_config file, like so:
PasswordAuthentication no

Pros and Cons of Disabling Password Authentication, in favor of key authentication.

Pros

• This method strongly decreases the likelihood that a brute force attempt against your SSH server will be successful.
  • Most brute force bots are only trying passwords to begin with, they will be using the completely wrong authentication method to try to break in, so those bots will never succeed.
  • Even if someone was doing a targeted attack, SSH keys are so much longer than passwords that guessing one correctly is orders of magnitude harder, simply because there’s so much entropy and potential combinations.

Cons

• This technique can make it less convenient to access the server.  If you don’t have the key file handy, you won’t be able to SSH in.
• Due to the above, you are also increasing risk of getting locked out of SSH, for example if you lose the key file.  So, it’s a good idea to have an alternative way to access the server if you need to let yourself back in, like a remote console.

In the event that someone gets ahold of your key file, just like a password, they will now be able to login as you.  But, unlike passwords, keys can be easily expired and new keys created, and the new key will operate the same way.
Another interesting quirk about the SSH keys method is you can authorize multiple SSH keys on a single account, whereas an account can typically only have one password.
It’s worth noting that you can use SSH keys to access accounts even if password authentication is turned on.  By default, SSH keys will work as an authentication method if you authorize a key.

Allow Whitelisted IPs Only

A very effective security technique is only allowing whitelisted IP addresses to connect to the SSH server.  This can be accomplished through firewall rules, only opening the SSH port to authorized IP addresses.
This can be impractical for home users or shared web hosting providers, since it can be difficult to know which IP addresses will need access, and home IP addresses tend to be dynamic, so your IP address might change.  But, for situations where you are using a VPN or mostly accessing from a static IP address, it can be a low maintenance and extremely secure solution.

Pros and Cons of Allowing Whitelisted IPs Only

Pros

• This method provides very strong security, since attackers would need to have access to one of your whitelisted IPs already in order to try to SSH in.
• Arguably, this method can supercede the need for other security methods like brute force protection or disabling password authentication, since the threat of brute force attacks is now basically nullified.

Cons

• This method increases your chances of getting locked out of the server, especially if you are in a location where your IP address may change, like a residential Internet connection.
• The convenience of access is also reduced, since you will be unable to access the server from locations that you haven’t whitelisted ahead of time.
• There is some effort that goes into this, since you now have to maintain your IP address whitelist by adding and removing IPs as the needs change.

On my own personal servers, this is usually the technique that I use.  This way I can still have the convenience of authenticating with a password and using the normal SSH port, while having strong security.  I also change my servers frequently, creating new ones when needed, and I find that implementing this whitelist is the fastest method for me to make my new servers secure without messing with other configurations, I can simply copy my whitelist from another server.

A Hybrid Approach: Allow passwords from a list of IPs, but allow keys from all IPs.

If you want to get fancy, there are a number of “hybrid” approaches that you can implement that combine one or more of these security techniques.
I ran into a situation once with one of our customers at GigeNET where they wanted to provide staff with password access, so that they could leave a password on file with us, but they wanted to only use key authentication themselves and not have password authentication open to the Internet.
This was actually very simple to implement, and it provides most of the security of disabling password authentication, while still allowing the convenience of password authentication in most cases.
To do this, you would want to add the following lines to your sshd_config:
# Global Setting to disable password authentication
PasswordAuthentication no
[...]
# Override the Global Settings for IP Whitelist
# Place this section at the -end- of your sshd_config file.
Match address 1.2.3.4/32
PasswordAuthentication yes
For the above, 1.2.3.4 is the whitelisted IP address.  You can repeat that section of the configuration to whitelist multiple IPs, and you can change the /32 to another IPv4 CIDR such as /28, /27, etc in order to whitelist a range of IPs.
Remember that the Match address block should be placed at the very end of your sshd_config file.

Pros and cons of a hybrid approach

Pros

• This technique can provide the security of key authentication by preventing passwords from working for most of the Internet, but allowing the convenience of password authentication from frequent access locations.  So, it allows you to reduce some of the drawbacks while keeping most of the security.
• If your IP address changes and you are no longer whitelisted, you can still SSH in with the key file so long as you have it saved locally.

Cons

• Like the IP whitelist firewall method, this method takes some maintenance since you have to update your SSH configuration if your IP address changes or you need to whitelist other locations, but unlike other methods, updating the whitelist here is less critical since you can still access via the key method even if you’re not whitelisted.

Ultimately, you will have to choose what’s best for your use case.  

Hopefully this list of techniques and examples provides some food for thought that you can use when you are security your servers: what the risks are and what possible techniques exist to mitigate them.
Based upon how important you think the security of the server is, and the practicality of implementing the various security solutions toward mitigating the risks you’re concerned about, you can choose one or more techniques to move forward.
At the end of the day, I always remind everyone that security is relative.  You will never have anything that is fully impenetrable, and the main thing is to keep yourself at least one step ahead of everyone else.  Even if you implement just one of these security practices, you are more secure as a result than a large number of Linux servers out there that are running with the default settings and SSH wide open to anyone that wants to try to login.
 
How can GigeNET keep your business secure? Chat with our experts now.