Below, you will find 5 practical ways to harden your SSH server from hackers and bad actors. The tips in this post are not comprehensive because as you know, anything that is connected to the internet is never 100% secure, but these tips are fundamental best practices for securing your SSH server.
1. Use SSH Keys
We don’t ever want to use a password to login to the server via SSH. Instead of a password, we want to use a key to access the remote server.
To set this up, use the ssh-keygen command to generate a key on your local system like this.
ssh-keygen -t ed25519
Next, copy that key to the server with the ssh-copy-id command.
ssh-copy-id -i ~/.ssh/id_ed25519.pub tony@50.116.22.72
Finally, test it out, and you will be able to login to your remote server without a password.
2. 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 and change this value to no, and set UsePAM to no as well.
# 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
Now, when someone tries to access your server via SSH without a valid public key, they’ll see a permission denied error.
Be careful here because if you lose access to your public key, you lose access to your server because you disabled password logins.
3. Disallow Root Login
Forbid the root user to login via SSH. Similar to before, open the sshd_config file and change PermitRootLogin to no.
#LoginGraceTime 2m PermitRootLogin no #StrictModes yes
Restart the ssh daemon with systemctl restart sshd for the changes to take effect, and now the root user will not be able to login to the server via SSH.
4. Change Default SSH Port
Another SSH security technique is to change the SSH port. The default SSH port is 22, and every hacker knows this.
Open the ssh_config file again, uncomment the port line, and change it from 22 to 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 of port numbers to find a port number that is not used by another application.
As always, restart the SSH daemon to apply changes, and now when someone tries to login to your server with the default port, they’ll get a connection refused error.
For this point forward, you can specify your port with the -p flag and access your server that way.
ssh -p 5823 user@server
5. Do an SSH Audit
Conduct an SSH audit for your system by going to ssh-audit.com.
You’ll be given a score and a letter grade that corresponds to the strength of your keys, algorithms, and encryption. In addition to this, you can also do a Policy Audit for your specific operating system. This is a pass/fail grade based on whether or not your ssh server is hardened to standards.
In order to fix things, you can use the SSH Hardening Guide for your specific operating system which will give you a series of commands to execute as root that will harden up your ssh server.
After fixing things, you can re-run the audit scans and at this point you should get an A for the standard audit and green passing check mark for the policy audit.
One Response
Hi Tony,
We are applying for PCI compliance, and they have given us a bunch of things that we need to fix with our SSH on Hostinger. We do not want to mess with and Hostinger cannot! Do you do consulting and provide this type of service? If so, what are your fees and the engagement procedure?
Bob
p.s Picked up you contracts from youtube.