logo

Linux OpenSSH Security Hardening Guide

Posted by Marbenz Antonio on May 11, 2022

14 SSH Key Management Best Practices You Need to Know - Hashed Out by The SSL Store™

On Linux platforms, SSH is one of the most extensively used protocols for system management. It’s compatible with a variety of Unix, Linux, and MacOS-based operating systems. It is based on the client-server concept, in which one computer executes the server component while the other accesses it using a client tool.

How does SSH work?

The connection is established by the user (ssh) submitting a request to the server. The server uses the server daemon to listen for incoming requests (sshd). It authenticates itself to the client attempting to connect to it by using its public key:

This ensures that the client is connected to the correct SSH server. After then, the client can connect to the server. To connect to the server on a Windows client, you’ll need to utilize tools like putty. Both the client and server tools may be installed on the same system, which means you can use the client tool to connect to other computers or your system can act as a server that others can connect to. The config file is stored in the same directory as the other files, but with a slightly different name. The ssh client config file is called ‘ssh config’, whereas the server’s config file is called ‘sshd config’:

No description available.

If you have both files on your machine, you should decide which one you need to configure first. In most situations, it is the server that requires security configuration because it is the gateway to the system.

We’ll start by verifying the status of our server’s SSH daemon, or sshd. We can detect if it’s running and allow it to start automatically when the computer boots up. The command following will check the status of sshd:

$ systemctl status ssh.service

Or use the below one:

$ systemctl status sshd.service

No description available.

If you have both files on your machine, you should decide which one you need to configure first. In most situations, it is the server that requires security configuration because it is the gateway to the system.

We’ll start by verifying the status of our server’s SSH daemon, or sshd. We can detect if it’s running and allow it to start automatically when the computer boots up. The command following will check the status of sshd:

Configuring SSH using the Best Practices

And believe it is now time to begin setting the SSH server setup. We should make a backup of the SSH config file with the default settings before we get our hands dirty with it:

$ sudo cp /etc/ssh/sshd_config ~/sshd_config.bkp

After performing the backup, we may be comfortable that if we make a mistake with the main file and break SSH, we can restore normality using the backup file.

1. Changing the default fort

By default, the sshd daemon listens on the server’s port 22. It is advised that this value be changed to anything else in order to limit the reach of automated script attacks. This strategy is known as security by obscurity. To do so, open the code below and search for the line that says ‘#Port 22.’

$ sudo nano /etc/ssh/sshd_config

Uncomment the line ‘#Port 22′ and replace ’22’ with a port number that is not already in use on your system. We had to modify the password to ‘222’ and restart the service. To provide the new port, use the ssh command with the option ‘p’:

$ ssh user@system_ip -p 222

No description available.

2. Disabling login as the root user

The root is the most powerful user on a Linux system, with access to all of the system’s resources. You should disable the root login feature on your server if you do not require tight root access. To do so, open the same file as before:

$ sudo nano /etc/ssh/sshd_config

Set the option ‘PermitRootLogin’ to ‘no’. This will guarantee that the server is safe against random assaults aimed at the root account. The default option is ‘prohibit-password,’ which allows for public-key authentication but not password authentication.

3. Setting the protocol version

SSH1 is the earlier protocol version, and it is less secure than SSH2. They also have distinct networking implementations and are incompatible with one another. Open the sshd config file again and search for the line ‘Protocol’: to see which protocol version is active on your server.

$ cat /etc/ssh/sshd_config | grep 'Protocol'

If you get an empty output, OpenSSH is most likely using version 2, as it was in our instance. Another option is to use the Netcat command:

$ nc localhost 22

Sample output:

SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.4

SSH2 is operational on our machine, as seen by the output.

Try connecting to a remote server using an ssh client with the -Q (query) option to see which protocols version it is running:

$ ssh -Q protocol-version user@server_name

No description available.

The screenshot above depicts an SSH version 2 connection from Kali Linux to an Ubuntu ssh server.

4. Password complexity

Empty passwords are more likely to be abused since weak passwords are always open to being exploited. As a result, the PermitEmptyPasswords option in the sshd config file should be set to ‘no’. Similarly, to lessen the probability of a brute force assault, the number of login attempts with incorrect passwords should be reduced. This may be accomplished by setting the ‘MaxAuthTries’ option to a lower number, such as 3.

No description available.

When we set the ‘MaxAuthTries’ setting to 3, we are refused SSH after three incorrect passwords, as shown in the image above. Using public key authentication for login is another important security feature. Brute force assaults are less resistant to key-based authentication methods. Similarly, we may utilize the PAM authentication module to strengthen the SSH server even further.

Conclusion

We’ve tried to cover the most critical aspects of protecting an SSH server in this article and condense them into four primary points. Although this article is not exhaustive, you can find more ways to enhance your SSH server. You might, for example, deploy a banner message to warn users about utilizing SSH to access your system. You can also disable password-based authentication and use key-based authentication instead. Another feature worth mentioning is the ability to limit the number of SSH users as well as their connection time.

 


Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com

Verified by MonsterInsights