How to Secure Your SSH Server

Below are some practical ways to protect your SSH server from unauthorized access. The suggestions in this post are not exhaustive because, as you know, nothing connected to the internet is ever completely secure. Still, they are fundamental best practices for securing your SSH server.

Use the SSH Keys

We never want to use a password to access the server through SSH. We want to use a key rather than a password to access the remote server. To do so, use the ssh-keygen command to generate a key on your local system that looks like this.

ssh-keygen -t ed25519

Then, using the ssh-copy-id command, copy that key to the server.

ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

Finally, test it, and you should be able to log in to your remote server without a password.

Disable SSH Passwords

Disable password-based authentication for SSH. To do this, open the ssh config file at /etc/ssh/sshd_config, uncomment the PasswordAuthentication line and change the value to no. Also, uncomment the PermitEmptyPasswords line, change this value to no, and set UsePAM to no.

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes 
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no

Restart the SSH daemon to apply changes.

systemctl restart sshd

When someone attempts to connect to your server via SSH without a valid public key, they will receive a permission denied error.

Remember. Do not lose access to the public key; otherwise, you will lose access to your server because password logins have been disabled.

Disallow Root Login

Allow only the root user to log in via SSH. Open the sshd_config file again and change PermitRootLogin to no.

#LoginGraceTime 2m
PermitRootLogin no
#StrictModes yes

To make the changes take effect, restart the ssh daemon with systemctl restart sshd. The root user will no longer be able to connect to the server via SSH.

Change Default SSH Port

Changing the SSH port is another SSH security technique. Every hacker is aware that the default SSH port is 22. Reopen the ssh_config file, uncomment the port line, and replace 22 with a random number.

Include /etc/ssh/sshd_config.d/*.conf
Port 5823
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

Look through this Wikipedia page https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers of port numbers to find one that isn’t already used by another application.

As always, restart the SSH daemon to apply the changes, and anyone attempting to connect to your server using the default port will receive a connection refused error.

You can specify your port with the -p flag and connect to your server.

ssh -p 5823 user@server

Do an SSH Audit

Go to ssh-audit.com to perform an SSH audit on your system.

You will be assigned a score and a letter grade based on the strength of your keys, algorithms, and encryption.

You can also perform a Policy Audit for your specific operating system. This is a pass/fail grade based on how hardened your ssh server is to standards.

To resolve the issue, use the SSH Hardening Guide https://www.ssh-audit.com/hardening_guides.html for your specific operating system, which will provide you with a series of commands to run as root to harden your ssh server.

After you’ve fixed everything, you can re-run the audit scans, and you should now have an A for the standard audit and a green passing check mark for the policy audit.