Improving SSH Server Configuration

SSH is a common way to remotely control, or transfer data between, computers. It is a much more secure method compared to alternatives, such as Telnet, which transmit data in plain text. However, there are a few SSH server settings that can be improved. Below are a few changes to get you started.

Create and Upload SSH Key

First, we’ll create an SSH key pair. It’s important to do this now because we’ll be updating the SSH config on the server to only allow us to connect via key-based authentication. The public key will be uploaded to the server while the private key will exist only on the local machine. These should be backed up and it’s important to protect the private key. The public key will be added to the remote server and allow us to log in as a user called “remoteuser” on the server. Replace “host” with the hostname or IP address of the server.

To create a new key:

ssh-keygen -t ed25519

To upload public key to server:

ssh-copy-id -i ~/.ssh/id_ed25519.pub remoteuser@host

Edit Or Add The Following Settings

Open the SSH server configuration file (/etc/ssh/sshd_config) in your editor of choice.

Port port_number

Replace port_number with your desired port number. Port numbers from 1024 to 65535 are usually a safe bet, just make sure it’s not already in use by another service. SSH typically runs on port 22, but selecting a custom port will make it more difficult for someone to gain unauthorized access to your server. This is considered security through obscurity and, while not helpful on its own, it is useful in the context of being one of many layers of security.

Note: In the future you will need to supply your chosen port number when connecting via SSH.

Protocol 2

Most current installations should be using version 2 of the SSH protocol by default, but if it’s set to version 1 update it. Version 2 offers much better security so there is no reason to use version 1.

PermitRootLogin no

Setting PermitRootLogin to no ensures that no one can login remotely as root. Normal users can use sudo to gain root level access when needed instead of logging in as root (this also provides the benefit of better system change auditing).

AllowUsers remoteuser

With AllowUsers you can specify which users are allowed to authenticate remotely. Change user_name to the name of any user you’d like to allow remote access. It’s best to limit access to only the absolutely necessary users.

PermitEmptyPasswords no

Setting PermitEmptyPasswords to no ensures that a user with a blank password cannot remotely login. We will not be using password authentication but there’s no reason to have this setting enabled.

PasswordAuthentication no

Setting PasswordAuthentication to no ensures that no one can login remotely with a password. Instead we will be using key-based authentication. This will prevent someone from having the opportunity to gain access by brute forcing your password.

HostbasedAuthentication no

Unless you need to use host-based authentication, disable it and rely on key-based authentication.

UseDNS no

The UseDNS option specifies whether the server should look up the remote host name when someone connects via SSH and verify that the resolved host name for the remote IP address maps to the same IP address. Leaving this option enabled will only generate a warning in the logs if the remote client’s DNS cannot be resolved, it doesn’t actually prevent an attack. Disabling this can provide improved server performance when logging in.

Wrapping Up

With these changes we’ve restricted the authentication methods that the server will accept and restricted the users that are allowed remote access. These changes also improve other security measures as well as server performance. There are other changes that can provide further improvements but these make for a good start.

To ensure any changes made take effect immediately, run the following command in the terminal:

sudo systemctl restart ssh