So let’s take a look at some general tips that any SSH server administrator should consider when securing their system. 

Securing an SSH server.

Because SSH is a service that provides access to protected systems, it’s important to secure the SSH server in a responsible way. 

So let’s take a look at some general tips that any SSH server administrator should consider when securing their system. 

Many of these security measures are set in the servers configuration file, /etc/ssh/sshd_config, but others have to do with the system and network around the server instead. 

Within the configuration file, it’s a good idea to disable the ability of the root user to log in through SSH, using the PermitRootLogin directive with a value of no. There are other options available, like prohibit-password, which allows root to log in with a key, but not with a password. But generally, unless you have a very specific reason not to, it’s a good idea to prevent root from logging in remotely through any means. 

Attempting to log in as the root user is a common tactic of bots and attackers.

 It’s also a good idea to prevent normal users from using passwords to log in, if that’s an option that’s available to you. 

Generally speaking, using keys does provide more security, but it also adds some management overhead, as well. 

So that policy is up to you and your security requirements. In the configuration file for the server, we’d use PasswordAuthentication no to prevent logins with passwords. 

And we’d also need to make sure that PubkeyAuthentication yes is set. 

Yes is the default for this option already, but it never hurts to double check. 

Another option that’s available is to move the port the server runs on from 22 to another port. This used to be somewhat effective at preventing bots and other bad actors from finding an SSH server. 

But nowadays, it’s only a matter of time before bots eventually find whichever port your service runs on if your server is connected directly to the internet. 

It’s also possible to specify which encryption methods a server allows. And some security policies require changes to this parameter of the configuration.

 If you need to change the encryption your server allows, be sure to explore the ciphers section of the sshd_config man page. 

Controlling which users and groups are allowed to connect to the server is also a useful method of securing the service. 

To do this, we’ll use the AllowUser, DenyUser, AllowGroup, and DenyGroup directives.

If your server is exposed to the internet and faces repeated login attempts from malicious spots, you may consider installing software like Fail2ban to help the system block repeated logins based on their origin IP address. 

Also consider designing your system to use a bastion host if you have many users connecting to many protected systems. A bastion host and the appropriate client settings not only help to simplify the user’s connection experience, but also provides one point of security control instead of many. 

Another best practice is to put your SSH server behind a VPN so only authorized users are able to access it. While SSH is capable of handling security based on authorized users, exposing an SSH server to the internet will quickly attract bots that try to log in with common user names and perform other attacks on it in order to try to gain access. While this will usually fail, it increases the load on the SSH server and on the system hosting it and can result in large amounts of logs and additional useless traffic. 

If impersonation of your server is a problem, you can provide users with the a fingerprint of your server before they connect so they can add the fingerprint to their known hosts file instead of relying on your server to provide the fingerprint on the first connection. 

To do this, we can use the command ssh-keyscan and provide the server address or other host name and look for the type of key you want to share. Here, we see the surface fingerprint presented in a few different ways. 

This one uses the RSA algorithm. Here’s the information with a different algorithm, and with a third. I could take one of these lines of text here with the address, protocol, and fingerprint and share it with users or add it to their known hosts file. 

Then on the first connection, they wouldn’t be prompted to accept a fingerprint they probably don’t know whether is correct or not. 

And you’ll know they have the correct fingerprint should they ever face a warning about a mismatch. While there’s no such thing as perfect security, we can take steps in configuring our SSH server and in designing the system around it to enhance the security of our system and protect our users. 

When setting up an SSH server, be sure to follow any security guidelines or requirements that your organization provides.