Hardening SSH on your Ubuntu Server

Secure Shell (SSH) is an amazing cryptographic network protocol, and it undoubtedly helps secure a huge slice of today’s Internet – giving sysadmins robust remote access to their servers, but also so much much more.

I’ve been using SSH on Linux Servers for longer than I can remember. Well, not quite. I do remember those “telnet” days when nobody had a care in the world, and Edward Snowden was a kid playing video games. Or something.

I’ve learned a thing or two about hardening SSH and locking it down, including generating certificates, and using it as a remote proxy in all kinds of ways. Here is a brief brain dump that I hope you enjoy.

General SSH Configuration Tips

Configuration of SSH starts with the sshd_config file.

sudo nano /etc/ssh/sshd_config

Change the Default Port

The first is the “Port 22” default that SSH listens on; I will usually change this to a different number other than the default, or run it on multiple ports depending.

# What ports, IPs and protocols we listen for
#Port 22
Port 2222

If you don’t change the port from 22 you’ll just be subjecting yourself to endless probes and brute-force logins from everywhere. While changing to something else is not guaranteed to stop any of that, in my experience it will reduce it. A lot.

Ensure you’re using Protocol 2 (SSH2)

The second thing to check, particularly if you have an older Linux server is the version of the SSH Protocol – the line “Protocol 2” does that. Ensures you’re using SSH2 which is far superior that earlier versions of the protocol and shouldn’t be an issue today.

Protocol 2

Don’t Permit Root Login

I’m a strong advocate of always connecting to a server using my own account, and if I need superuser access I’ll “sudo” to get it. This means there’s never a valid reason ever to login as the root user.

Unfortunately, some of today’s cloud VPS hosting providers will provide you with a root login straight away. Um, no thanks.

PermitRootLogin no

Turn Off Password Authentication (if using Certificates)

If you’re using certificate based authentication (which I highly recommend – here’s some useful information on that) you’ll want to turn off any kind of password authentication, by locating and modifying the lines below to “no”.

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Restrict to Known Users

Another thing you can do, which I think a lot of people never bother doing, but might be useful, is to restrict SSH access to certain known users on the system. Even with the right password or certificate a user not in this list (if the setting is present) will not be able to login.

AllowUsers john bob alice

Using the “AllowUsers” setting could be vital if your server is hacked and somebody tries to create a backdoor user – at least this will prevent them getting any remote access, and the failed attempts may show up in your log files.

Disabling Potentially Compromised Modulus

There is some conjecture that the NSA (and others?) could intercept TLS and SSH communications by obtaining the shared private key during the “Diffie Helman” key exchange process.

The speculation about this weakness with DHE is potentially feasible. The concern is that there exists the ways and means through supercomputing power to factor the large primes commonly used for DHE.

Here’s one example news story suggesting it’s possible, which led me to researching and discovering some practical hardening tips here that I’ve refined a little further.

You’ll have to edit the moduli file:

nano /etc/ssh/moduli

Comment any lines that have a value less than 2047 shown in the 5th field on each line – and then don’t forget to restart the SSH service.

I’ve also made this SED one-liner below that you can run as root which will comment out the lines mentioned in one hit as well.

sudo cp /etc/ssh/moduli /etc/ssh/moduli.bak
sudo sed -r -e '/[[:space:]](1023|1535)[[:space:]]/ s/^/#/' -i /etc/ssh/moduli

Restarting the SSH Service

If you’re connected to a remote server via SSH already, and you’re editing the sshd_config there is a real risk that you could inadvertently cut yourself off if you get something wrong.

The biggest tip I can give you is to NEVER logout from any existing sessions until after you have verified your new SSH config is working.

systemctl restart sshd

After you have restarted SSH, try a new connection to the server and if successful everything is fine. If you have any problems, you’ll need to go back to your existing logged in session and fix up the sshd_config (check the log files for reasons why if not clear). You’ll then need to repeat and restart the SSH service until you can login with a new session.

I hope these tips help you secure your SSH server, and until next time, stay safe out there.