Open SSH security best practices

Although Open SSH has become the norm when it comes to remote access, using its default installation still poses a few security risks. This guide proposes ways to considerably increase the security level of an Open SSH installation.

Use private/public keys authentication

Using encrypted keys for authentication is useful as it eliminates the need to enter passwords. Even the most inventive hackers won’t be able to interfere or sneak onto a session, and no more cracking password attempts.

1. Generate a public/private keys pair using this command: $ ssh-keygen -t rsa. This creates two files in the (hidden) ~/.ssh director; the private key is called id_rsa and the public one id_rsa.pub.
2. Choose a password which will be used to unlock the public key upon each connection. Optionally, an encryption protected with a passphrase can be added when creating the key.

   Pressing Enter without entering a passphrase works too. Be aware, however, that creating a key without a passphrase automatically gives SSH access to the remote server to anyone gaining access to your local machine.
3. Copy the public key (id_rsa.pub) to the server:

   Scp –p id_rsa.pub remoteuser@remotehost:
   ```   <div data-gb-custom-block data-tag="hint" data-style='danger'>The `remoteuser` should never be root. Select the default non-root user as `remoteuser` instead.</div>

4. Log in with SSH and copy the public key to the right place:

   ssh remoteuser@remotehost mkdir ~/.ssh chmod 700 ~/.ssh cat id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys mv id_rsa.pub ~/.ssh logout

5. Then delete the public key from the server, otherwise the SSH client does not allow logging in to the server:

   rm id_rsa.pub

6. Set file permissions on the server (these two are required if "StrictModes" is set to yes):

   $ chmod 700 ~/.ssh
   $ chmod 600 ~/.ssh/authorized_keys

7. Once logged in using the key passphrase, password authentication can be disabled entirely. To do so, open the /etc/ssh/sshd_config file and add the following lines to it:

   # Disable password authentication forcing use of keys
   PasswordAuthentication no

Disable username and password authentication

To fully eliminate password-based authentication and force the use of SSH keys or certificates, update SSH configuration by adding the following lines in the /etc/ssh/sshd_config file:

PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no
UsePAM no

Then, restart the SSHD service by entering either /etc/init.d/sshd restart or service sshd restart. Once this is done, the server should reject all username/password logins and only accept authentication via key or certificate.

Configure idle timeout interval

An Idle timeout interval can be set to avoid having an unattended SSH session. To do so, open the /etc/ssh/sshd_config file and add the following line:

ClientAliveInterval 360
ClientAliveCountMax 0

The idle timeout interval is in seconds (360 seconds = 6 minutes). Once the interval has passed, idle users are automatically logged out.

Disable empty passwords

For added security, it is recommendedto prevent remote logins from accounts with empty passwords. Open the /etc/ssh/sshd_config file and update the following line:

PermitEmptyPasswords no

Limit SSH access to a few users

In cases where username/password authentication cannot be avoided, it is recommended to limit SSH login to only certain users who need remote access, thus minimizing the impact of users with weak passwords.

To limit SSH login, open the /etc/ssh/sshd_config file and add an AllowUsers line, followed by the list of usernames separated with spaces:

AllowUsers user1 user2

Then restart the SSHD service by entering either /etc/init.d/sshd restart or service sshd restart.

Disable root login

To disable root logins, open the /etc/ssh/sshd_config file while logging on as root and change the line #PermitRootLogin to PermitRootLogin no. Make sure to remove the # symbol, otherwise it will not work.

Then restart the SSHD service by entering either /etc/init.d/sshd restart or service sshd restart.

Disable weak cipher

Open the /etc/ssh/sshd_config file and add in these lines:

# Ciphers moderns
Ciphers [e-mail],[e-mail],[e-mail]

# KEX robusts
KexAlgorithms curve25519-sha256,[e-mail],ecdh-sha2-nistp256,ecdh-sha2-nistp384

# MAC moderns
MACs hmac-sha2-512,hmac-sha2-256,[e-mail]

# Disable weak algorithms
PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-256,rsa-sha2-512
HostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512

Then restart the SSHD service by entering either /etc/init.d/sshd restart or service sshd restart.

Use a non-standard port

The vast majority of hackers looking for any open SSH servers will look for port 22, since by default, SSH listens for incoming connections on that port. To run SSH on a different port, open the /etc/ssh/sshd_config file and add the following lines:

#Run SSH on a non standard port
Port 2025 #Change me

Then restart the SSHD service by entering either /etc/init.d/sshd restart or service sshd restart.

Make sure to change the port forwarding in your router and any necessary firewall rules. It is recommended to inform clients of any port changes so they know which port to connect to since SSH will no longer be listening for connections on the standard port.

Limit SSH exposure with network controls

If changing the SSH port is not feasible, deploying a jump server provides a strong Zero-Trust control point between clients and internal systems. It centralizes authentication, enforces uniform access policies, and prevents direct exposure of critical assets. See Remote Desktop Manager Jump (feature) for configuration steps.

Enable multifactor authentication

Multifactor authentication is one of the main protections to add to SSH servers to protect them from unauthorized access since each user login must tie back to a configured MFA user. Even if a hacker manages to get a hold of a password or breaks into the SSH server, they will still get blocked by the MFA.