Securing SSH Server

Securing SSH is more important than ever. In a shared hosting environment, you options are somewhat limited, but if you have a well defined user group, you can really lock down SSH such that brute-force attacks are no longer a threat.By default, this access security is provided by the connection encryption and the need of login and password. This how-to propose various methods to harden a SSH server security.

Before we even get started on securing OpenSSH you need to make sure your overall security strategy makes sense. Are you securing actual sensitive information or are you just worried about someone snooping your connection? This tutorial assumes you are protecting sensitive data and require very high security to access the server (and its data).

Client and Server

SSH has two parts: the client used for connecting to a server, and the server daemon itself. This latter one is usually the most important part in deciding how “secure” a connection may be. One example is that the server can decide if normal password based logins are allowed or denied. Even if the client has a preference, it is the server to make the final call.

The client configuration settings can be found in /etc/ssh/ssh_config (system wide) or ~/.ssh/config (per user). For the server configuration file: /etc/ssh/sshd_config

10 Tips to secure SSH

Securing SSH consists of setting parameters in the SSH configuration file. We focus mainly on the SSH daemon, with the following 10 tips:

1. Set SSH protocol

Version 1 of the SSH protocol has weaknesses. Therefore make sure only protocol version 2 can be used.

Protocol 2

2. Use of X11Forwarding

The display server on the client might have a higher exposure to be attacked, when enabling this option. If forwarding of X11 traffic is not needed, disable it by setting this value to “no”.

X11Forwarding no

3. Disable rhosts

While not common anymore, rhosts were a weak way to authenticate systems. By default the use of rhosts is already disabled. Make sure to check if it really is.

IgnoreRhosts yes

4. DNS hostname checking

By default the SSH server can check if the client connecting maps back to the same combination of hostname and IP address. Use this option to perform this basic check.

UseDNS yes

5. Empty passwords

Accounts should be protected and users should be accountable. For this reason the usage of empty passwords should never be allowed.

PermitEmptyPasswords no

6. Maximum authentication attempts

To prevent a brute force attack on the password of a user, limit the amount of attempts. Also enable monitoring for authentication failures, which starts at the half the number of maximum attempts. Use these authentication failures together with your SIEM solution, or forward them to your security administrator.

MaxAuthTries 6

7. Public key authentication

Instead of using a normal password based login, one might opt for using public key authentication instead. Keys are considered much safer and less prone for brute force attacks. Disable password authentication to force using keys.

PubkeyAuthentication yes

PasswordAuthentication no

8. Root login

It is best practice not to login as root directly. Use a normal user account to initiate your connection, together with sudo. Direct root logins may result in bad accountability of the actions by this user account.

PermitRootLogin no

9. Usage of Allow and Deny Users/Groups

When not all users should have access to the system, limit the amount of people who can actually log in. One way is to create a group (e.g. sshusers) and add people to this group. Next set the AllowGroups option to define that only these users can log in.

Other possibilities include to only allow a few users with the AllowUsers, or specifically deny users and groups with the DenyUsers, or DenyGroups.

SSH applies the following order to determine if one can log in: DenyUsers, AllowUsers, DenyGroups, finally AllowGroups.

10. Use HashKnownHosts

Each time the SSH client connects with a server, it will store a related signature (a key) of the server. This information is stored in a file names named known_hosts. The known_hosts file itself is available in the .ssh subdirectory of the related user (on the client). In the case the signature of the server changes, SSH will protect the user by notifying about this chance. This option is useful, but also has a risk. Previously it was common to store the hostname related with the key. This made it easy for worms and other malicious scripts to use this information and spread to other systems, once they had a single system compromised. To counter this, the HashKnownHosts will hash each host, so it’s not readable anymore. While being unreadable for the human eye, it still allows SSH to check for the next time you connect to the same system, as the results in the same hash.

Example output: