Hardening SSH can be a challenge, but it’s critical to get done.
OpenSSH is the administrative tool of choice for any good Unix/Linux sysadmin, and every bad guy in the world knows it. There’s a lot of scanning constantly looking for low-hanging fruit like misconfigured SSH services.
Be sure to test each one of these sets of changes before you log out every session to prevent locking yourself out. A late night drive to the data center certainly isn’t any fun.
Hardening SSH: Keep everything up to date
As of writing, 7.5 is the latest release, and keeping software updated is always an easy way to avoid a lot of pain.
Hardening SSH: Use public key authentication
Add your public user key to your user’s ~/.ssh/authorized_keys file, and then make the following changes to your /etc/ssh/sshd_config file:
PubkeyAuthentication yes PasswordAuthentication no
Hardening SSH: Limit the users that can authenticate
PermitRootLogin no AllowUsers user1 user2 user3 .
Allowing remote root is a bad idea, and you should keep track of users allowed to ssh into your server. Additionally, scheduling a regular audit of this list is a smart idea.
Hardening SSH: Use a monitoring and blocking tool
There are a number of good tools covered previously in Configuring Fail2Ban To Protect Services.
Hardening SSH: Adjust the accepted crypto types
Ciphers cipher1,cipher2,.. KexAlgorithms algo1,algo2,.. HostbasedAcceptedKeyTypes algo1,algo2,.. MACs hmac1,hmac2,.. HostKeyAlgorithms algo1,algo2,..
These are tough to advise on generically, as every organization has different needs. I stick to AES256 and SHA-2 based algorithms and ciphers; recent clients should support them. Mozilla keeps a pretty great recommended list going.
Also: these options vary by OpenSSH version.
Hardening SSH: Adjust your firewall
You should limit connections to your ssh service to known whitelisted IP ranges. Most commercial firewalls will let even let you block countries and continents using the MaxMind GeoIP database, which can make it straightforward to shut down a lot of bad actors.
Hardening SSH: Change the port from 22 to something else [optional]
I don’t agree that changing the port protects the service. Further, if you change the port? It will prevent generic scanners from picking up your service, but it won’t protect against dedicated scanning. And, if you’ve hardened your service correctly, we don’t much care about generic scanners.