This one is a crisp post describing various ways to secure your ssh access and at the same tries to address the fear mongering situation people exploit to make more money.

Use high number ports

Provides security through obscurity — The only use case for it is when the attacker is impatient. Generally speaking, as the number of IPV4 addresses are limited there are 24/7 running port scanners for various IP ranges impatient enough to not scan all the ports for all the IPV4 addresses. If you have ever exposed port 22 publicly, you’d sooner than later observe logs telling you that someone has been trying to break in. And, specifically for these actors, using higher # ports is useful. Just because you change the position of the keyhole in your door, it doesn’t mean that the keyhole is now more secure. Security derived from obscurity is never enough because there are no improvements to actual security to begin with. The only thing it helps with is when script kiddies and the nefarious port scanner actors try their luck against poorly setup machines. But if you follow some good setup practices with your authentication mechanisms, you can still use port 22 securely.

Note: If you think that having your IPV4 address publicly known with an open port for SSH is a deadly insecure setup, you’re wrong. More often than not, our IP address are not the actual IP addresses of our machines. Maybe it’s the IP address assigned to our router. Or, it could be an address NATed and shared across many customers of the ISP. I think countless youtube VPN advertisements have created a fearful environment among regular users who now think that having a publicly known IPV4 address instantly makes for an insecure and hackable setup. This is not true. Although, there are definite benefits of using a VPN for other specific use cases, but, in the context of security not a using a VPN doesn’t equal insecurity by default.

Q. When is having your IPV4 address publicly known with an open port for SSH a deadly insecure setup?

A. When you an improper setup:

• When your router is outdated and has unpatched security flaws with default weak login credentials.
• When you have forwarded ports on the router without knowing the implications
• When your ssh access has weak passwords or weak key setup

Don’t close the default SSH port

Provides security through ambiguity — Again like the point above, it is only applicable for impatient attackers: people who can’t wait long with just one IP address. Although, security through ambiguity is no security at all, it’s just a delay for the attacker. Port scanners usually scan the default ports first. There are tools like endless ssh which sends endless gibberish back over the default ssh port to the person trying to access ssh over the honey trap ssh port. Again, this one provides no additional security against the real attackers rather only marginal security against impatient script kiddies.

Disable ping if not required

Ping is the usual way of knowing whether a server is alive or not. If you are someone who wants to keep the stealth mode on, drop all the incoming ICMP packets. Now this one is debatable, more of a matter of preference in my opinion. If stealth mode is your call, go for it.

Use public key authentication

In my opinion, this one is only useful when you don’t have a strong password with the PasswordAuthentication and PubkeyAuthentication mode. Most people do not use a password manager to create random long passwords and have simple passwords which can be cracked in a trivial bruteforce attack. And, for this reason relying on PasswordAuthentication could be a bad idea. But, if you have a very strong password, use of public-private key pair or not yields no extra benefits from a security perspective.

Q. So when should you prefer public key authentication?

A. Always.

Q. Why?

A. Because it is more convenient. Just setup your keys once, and then you don’t have to worry about bruteforce attack. Additionally, with proper ssh-agent setup, you don’t have to type the passwords again & again.

To be more secure use public key authentication with password protected private keys. This is configurable in /etc/ssh/sshd_config with PasswordAuthentication set to no, and set PubkeyAuthentication to yes And, when it comes to access, add the private keys to the ssh-agent and then you won’t have to type in the passwords for every time you access the machine.

Disable PAM

If you don’t need PAM just disable it. This is configurable in /etc/ssh/sshd_config with UsePAM set to no. Almost, all normal users don’t need to setup PAM. If you know that you need PAM, then in my opinion, you are better served by not reading this page in the first place. To discuss PAM is beyond the scope of this post.

Long passwords for ssh keys

Everyone on this planet should use a highly secure password manager with a very strong password to manage all of their passwords. Otherwise, our brains are incapable of generating multiple different random strong passwords for each of our accounts.

Set max allowed tries & rates for ssh login

This is configurable in /etc/ssh/sshd_config with MaxAuthTries set to one. Additionally, setup services like fail2ban if need be.