In discussing whether or not it helps security to change what port sshd* listens on, the author of the link writes a wonderful study in the pitfalls of security through obscurity.
* (the server program that lets you login to a computer via ssh, for the uninitiated)
sshd traditionally runs on port 22. This means anyone who wants can have a go at logging in, and so there are loads of bots kicking around that try logging in with random username/password combinations to any server they come across.
If you run a server, the easy solution would seem to be just changing the port — tell it to listen on port 10800, and now the only people that can try logging in are those who know.
Unfortunately, security that limits access to ‘those who know about this obscure entry point’ is at best short-term.
For the case of sshd, making this change carries some security disadvantages… while any advantages can be achieved via other ways as well, ways that provide actual security. Things like installing programs that ban IP addresses who try to login unsuccessfully an inhuman number of times. Stuff like that works no matter what port the program is listening on — and works regardless of whether the adversary has figured it out.
“All of the reasons to change the port disguise an actual underlying problem that has a more appropriate fix:
It reduces the likelihood of successful compromise: if this is the case, and there’s a serious risk that your SSH credentials could be compromised as part of a brute-force attack, then you may not be enforcing a strong password policy.
An easy way to mitigate this is to disable password authentication entirely, and use only public key authentication, with passphrases on all applicable keys. Alternatively, you can use some one-time token system for two-factor authentication. 2.
It stops your SSH process getting DDoSed or even crashing your server: if this is a serious issue, then you need to protect your server or its subnet with a firewall capable of detecting such abuse, shutting it down, and most importantly, logging it so it can’t happen again.
If you haven’t got a hardware or at least a simple software firewall running on your server capable of arranging this, then you have far more serious problems than SSH script kiddies crashing your machine with spurious login attempts.
Do you really need to have sshd open to the world at all? Could you use a backnet, or tunnel it over a VPN? Is there a block of IPs to which you could reasonably limit it? 3.
It fills up your authorization logs: are you rotating your logs properly? Have you installed fail2ban, or denyhosts, or added connection-limiting rules to your software or hardware firewall to quietly shut down repeated failed connections?
Again, this masks a fundamental problem that needs an actual fix, and not a mere workaround.
In summary: don’t change sshd‘s port. There are better ways to use security infrastructure to deal with the problem of automated attacks.”