Tips for securing your SSH server
Protected Session
An SSH server facing the Internet will almost certainly be under attack, but a few proactive steps will help to keep the intruders away.
Secure Shell, better known as SSH, is a secure communication protocol used to execute commands on remote servers. SSH works on a client/server architecture. Data transferred through SSH is automatically encrypted using symmetric, asymmetric, and hashing algorithms. At receiving end, the data is automatically decrypted.
About 90 percent of system administrators use SSH to access their servers and configure them remotely. Users overwhelmingly prefer SSH over Telnet, an alternative communication protocol that is now considered insecure. SSH makes the data in transit more secure, but if you wish to secure an SSH server, you need to take some additional steps. Following are some measures that will help you protect your SSH server from attack.
Public Keys Instead of Passwords
The article on "System Hardening" elsewhere in this issue mentioned the benefits of using key authentication rather than passwords with SSH. Your password can be cracked by intruders, and you could end up getting hacked by a simple brute-force password attack. Here is a quick reprise on how to set up key-based authentication.
The first step is to generate the SSH keys on a client machine. You can generate keys in the terminal by running the following command (as shown in Figure 1):
ubuntu@ubuntu:~$ ssh-keygen -y
This command will generate two keys, a public key called id_rsa.pub
and a private key called id_rsa
. By default, these keys will be saved in the /home/user/.ssh
directory.
After generating the SSH keys, you need to move the public key (id_rsa.pub
) to the server.
From the client machine, type the following commands to move the public key to the server:
$ scp -p [ssh_port] ~/.ssh/id_rsa.pub username@server_ip:~/.ssh
On the server, now change the public key file name and permission by running the following commands in the terminal:
:~$ mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
Now change the permissions by running the following commands:
$ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys
Now it is time to test whether the server works or not. Try to access the SSH server from the client machine:
$ ssh -p [ssh_port] username@server_ip -i /path/to/id_rsa
If your client machine connects with the server, you know that key access is working correctly. Otherwise, check through the preceding steps and see if there is something you missed.
Changing the Default SSH Port
By default the client communicates with the server using the well-known port assigned to SSH, port 22, but it is not a good practice to use this default port. The reason is simple: Everyone knows about the default SSH port, and if you use it, you give the attacker a head start for hacking into your server. If you use another port, you add an extra obstacle for the intruder, who first has to find the SSH port before launching an attack.
Open the SSH configuration file with admin privileges using following command in the nano editor:
$ sudo nano /etc/ssh/sshd_config
In this file, find the following line, remove the #
sign, and replace 22 with your desired port number (see Figure 2):
# Port 22
After changing the port, restart the SSH server:
$ sudo systemctl restart ssh
Setting the Password Tries Limit
Another way to keep your SSH server secure from brute force attack is to set a password tries limit. When you set a limit, an attacker will not be able to access the SSH server after a specific number of unsuccessful password tries.
Open the sshd_config
file in your text editor. For example, if you use the nano editor, enter:
$ sudo nano /etc/ssh/sshd_config
Find the following line,
# MaxAuthTries 1
Remove the #
sign and set the number to 3
, as shown in Figure 3.
After changing the sshd_config
file, restart the SSH server by running the following command:
$ sudo systemctl restart ssh
Now, no one will be able to get access to your SSH server after three unsuccessful password tries. Of course, this could also cause complications for an authorized user who is having a bad memory day or forgets to check the Caps Lock key. Another approach is to use the Fail2ban utility, which suspends access for a predefined time interval and then lets the user try again. See the discussion of Fail2ban in the "System Hardening" article elsewhere in this issue.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
Gnome 47.1 Released with a Few Fixes
The latest release of the Gnome desktop is all about fixing a few nagging issues and not about bringing new features into the mix.
-
System76 Unveils an Ampere-Powered Thelio Desktop
If you're looking for a new desktop system for developing autonomous driving and software-defined vehicle solutions. System76 has you covered.
-
VirtualBox 7.1.4 Includes Initial Support for Linux kernel 6.12
The latest version of VirtualBox has arrived and it not only adds initial support for kernel 6.12 but another feature that will make using the virtual machine tool much easier.
-
New Slimbook EVO with Raw AMD Ryzen Power
If you're looking for serious power in a 14" ultrabook that is powered by Linux, Slimbook has just the thing for you.
-
The Gnome Foundation Struggling to Stay Afloat
The foundation behind the Gnome desktop environment is having to go through some serious belt-tightening due to continued financial problems.
-
Thousands of Linux Servers Infected with Stealth Malware Since 2021
Perfctl is capable of remaining undetected, which makes it dangerous and hard to mitigate.
-
Halcyon Creates Anti-Ransomware Protection for Linux
As more Linux systems are targeted by ransomware, Halcyon is stepping up its protection.
-
Valve and Arch Linux Announce Collaboration
Valve and Arch have come together for two projects that will have a serious impact on the Linux distribution.
-
Hacker Successfully Runs Linux on a CPU from the Early ‘70s
From the office of "Look what I can do," Dmitry Grinberg was able to get Linux running on a processor that was created in 1971.
-
OSI and LPI Form Strategic Alliance
With a goal of strengthening Linux and open source communities, this new alliance aims to nurture the growth of more highly skilled professionals.