5 tips for securing SSH on your Linux server or desktop

David Merron Photography/Getty Images

I’ve been using Secure Shell (SSH) for decades. With this remote login tool, I can rest assured my remote machines accept logins securely and efficiently. At the same time, I also understand nothing is ever 100% secure on any device connected to a network, which is why I always take time to better secure SSH on every computer I use.

Also: The best VPN services (and how to choose the right one for you)

You might be surprised at how easy it is to add a few extra “layers” of security. As I highlight below, there are some easy-to-apply tips that will help your Linux desktop and server machine to be a bit more secure, so you can trust they’re better protected against unwanted logins.

Let’s get to work.

1. Install fail2ban

One of the first things you should do (especially on a server) is install fail2ban, which prevents malicious and brute-force login attacks and can also be used to monitor other networking protocols (such as HTTP, SSH, and FTP). 

Also: Do you need antivirus on Linux?

With fail2ban, you create jails, which are configurations that tell the system what to do when certain things happen (such as a failed SSH login attempt). Jail files (typically named jail.local) are housed in /etc/fail2ban/ and might look something like this:

enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 300
bantime = 28800
ignoreip =

You can install fail2ban on a Debian-based system, with the following command:

sudo apt-get install fail2ban -y

On a Fedora-based system, that command would be:

sudo dnf install fail2ban -y

2. Change the default port

By default, SSH uses port 22 for incoming connections. This connection is common knowledge and can lead to trouble. On my more important systems, I’ll always change the port to something else, like 2124. It’s important that you change the port to something that is not being used by another system. 

The port configuration is set in the /etc/ssh/sshd_config file and in the line #Port 22. 

Also: 4 key security steps you’re probably forgetting

Make sure to remove the # character and change 22 to whatever port you want to use. Once you’ve made the change, remember to restart SSH with:

sudo systemctl restart ssh

In the case of Fedora-based systems, that command would be:

sudo systemctl restart sshd

3. Block users with blank passwords

Although you probably don’t have users on your system with blank passwords, this tip falls under the category of “better safe than sorry”. If you have a user with a blank password, and a bad actor discovers it, they could access your machine with ease. To prevent that situation, open the /etc/ssh/sshd_config file and look for the line:

Change that line to:

Save and close the file and then restart SSH.

4. Restrict logins to specific IP addresses

Another very handy trick is to limit SSH access to specific IP addresses. For example, if you have only one person who needs to access a machine, and their IP address is, you could limit SSH access with the help of the /etc/hosts.allow file. Open that file with your favorite text editor, such as nano, and add the following line at the bottom:


If you have more than one IP address you want to allow in, you can add as many as necessary, separating each address with a comma, like so:


Save and close the file.

5. Use SSH key authentication

The importance of SSH key authentication cannot be overstated. I’ve already shown in another article how this technique is set up, so make sure to read through that piece and implement the tactic. In conjunction with fail2ban, SSH key authentication is a great way to prevent unwanted SSH logins.

And there you have it — five easy ways of securing SSH on both your Linux desktops and servers. Just because SSH has the word secure in it, doesn’t mean it should be viewed as a means to a secure end. With a bit of extra configuration, your SSH logins will be better protected from the bad actors who roam the internet looking for access to systems.

Source link

Leave a comment