There are strong opinions on whether to run your SSH daemon on ports other than the default 22. On the pro side, the argument is that most automated tools only check port 22, so you reduce your exposure to random script kiddies by not running it there.
That’s just security by obscurity say the anti side. If your sshd is locked down properly then it shouldn’t matter how many people come knocking. What is important is that you don’t let them in.
Why a non-standard port?
The principle that comes into play here is, perhaps best illustrated by an oft-quoted aphorism
You don’t have to run faster than the bear to get away. You just have to run faster than the other guy.
Having ssh run somewhere where automated tools can’t see it reduces your attack surface. In an experiment run by Major Hayden the amount of casual scans dropped by 98%. That is a non-trivial amount of network traffic and server resources.
Running on a different port doesn’t stop you from taking the normal security measures:
- Running DenyHosts or Fail2Ban
- Disallowing root logins
- Locking logins down to named users
In fact it means that you could set up a rule to ban any IP that hit port 22, because you would know that it was illegitimate traffic.
Why not?
[Security] should not require secrecy, and it should not be a problem if it falls into enemy hands
So runs what has become known as Kerkhoff’s principle. Advocates of keeping sshd on port 22 observe that changing port is just security by obscurity. Of course this is something of a straw man argument, very few sysadmins advocate only changing the port to secure ssh.
A stronger argument is that non-root users can start processes on ports higher than 1023. Someone who had access to the system could start a bogus login on your non-standard ssh port and grab your password as you logged in. This would be even worse if you allowed root logins. It would allow a privilige escalation.
Next: running on a different port is inconvenient. You have to remember to type -p222 when you ssh to a box (or, more sensibly change the port in your ssh config. I have some sympathy with this argument, though it is not really a security argument. Unless we argue from another of Kerkhoffs priciples for military ciphers.
Lastly, given the circumstances in which it is to be used, the system must be easy to use and should not be stressful to use or require its users to know and comply with a long list of rules
Lastly a better solution to the mitigating attacks than changing ports is to use port-knocking. This is a pretty strong alternative way to stop automated attacks. But it is also a bit inconvenient, perhaps more so.
My take
I generally favour running on a non-standard port. Reducing the attack surface of boxes does not mitigate the risk of a targetted attack, but it does help preserve server resources for their intended use. I am in no way arguing that just changing the port is a good idea. But in combination with other measures it can help.
Security through obscurity is effective if it’s one layer in a multi-layer security solution
If you were concerned about the fact than non-root users could run something malicious on that port, then running on a port less than 1024 would mitigate the problem. Using keys rather than passwords as your login mechanism is a good practice anyway and also helps to protect against that attack.
I cannot argue that running on another port is not less convenient. One big thing that irritates me about using a different port is that ssh, scp and sftp all have different ways of specifying the port (-p222, -P222, -oPort=222). That is a right pain. However, as so often in security, changing port is a trade-off and the amount of extra overhead it imposes is small. Similarly with port-knocking, if you are against running on a non-standard port.
One thing that I hope everyone will agree with is that changing (or not changing) the port is just part of the work you need to do to protect your ssh. If your threat model involves mostly targetted attacks or if you aren’t too concerned about using server resources to respond to automated scanning tools, then it’s no biggie to run on port 22.