Changing the SSH port proved to be most successful. Yes, of course you can find the port with a port scan. But it keeps the logs clean. And I don't want to waste CPU cycles on some brute-forcing idiots.
Is using non standard ports a reasonable approach? On one hand, it's kind of a security-by-obscurity measure, and it's also a (very minor) inconvenience to real users. However if it's not being used in place of other reasonable security measures, I'm not really sure what's bad about it, but it does feel a bit janky to me.
Same goes for other non-public services such as VPN.
What ports should be used? I think clearly you don't want to use other well known services (eg, running ssh on port 25 is just going to fill your logs with failed connection errors). Should you use ports >1024? >10000?
I see it as a way to reduce the number of attacks, which is helpful, and may end up being more secure, but I wouldn't count on that alone. Against botnet attacks it will likely help, but against someone specifically targeting you, it likely will only slow them down.
Basically it boils down to 'why not?' for me.
It's a game of percentages.
Again, percentages. With enough attempts, some will succeed.
I can only speak for myself, if other people are ignoring warnings, it's their problem.
I believe that's been adequately addressed.
Restricting the remote IP range is another option.
This comes up as a point of confusion often, so allow me to clarify:
A non-standard port as the only security mechanism (e.g., an unauthenticated HTTP admin-interface) would indeed be 'security through obscurity', but a non-standard port as an extra mitigation layer on top of existing security mechanisms (e.g., SSH authentication) is 'defense in depth'.
A user can keep running a program to check if your non privileged port can be bound and if it could, it can start any behaving daemon that could be pretending to be a valid SSH daemon but could have anything like key loggers. Even a single restart of sshd could make it happen.
You say it yourself:
> also a (very minor) inconvenience to real users
I would disagree with the “very minor” part. To paraphrase myself (https://news.ycombinator.com/item?id=6617312):
As I understand the argument, it’s “Changing port number add security, therefore it’s a good idea.” I think nobody argues that it adds security. The problem is that:
1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits.
2. The security it adds is itself bad (sent in cleartext, easily brute-forced)
3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.).
And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems.
Technical protection is likely limited, but then, admin attention is also a limited resource.
An entirely different effect has been brought up by others already; a non-standard port is enough to evade ~99 % of all automated attacks, therefore you can run at higher log levels and might notice actual attackers earlier.
Like I said, nobody argues that it adds zero security, but that, for all the hassle it introduces, it adds way too little security to be worth it. 16 bits is nothing, and can be brute forced quickly.
Regarding port knocking: I’m assuming that most people don’t write their own port knocking software, but use something standard. The configuration of any port knocking scheme is equivalent to an additional separate key of length log2(number_of_possible_port_knocking_configurations). What is the effective “key length” of port knocking schemes?
Also remember that the “key” of port knocking, just like a non-standard port number, is transmitted in the clear, so anybody listening to the traffic can see it. (And if you assume that the attacker can’t listen to the traffic, why are you even using SSH instead of something simpler like telnet?)
Besides, running a service on a non-standard port offers pretty good protection against a fairly common threat scenario in which a new vulnerability is discovered in a well-known service and attackers start sweeping the internet for open ports in order to exploit it.
Not that you should automatically run your services on non-standard ports; there are tradeoffs as others have mentioned. But if you've got to expose something dangerous to the internet at large (and that's an assumption that you should question frequently), then avoiding the standard ports can be a useful tool.
It's a big quiet void out there in sixspace.
Since I disabled password logging on all accounts and my key is stored on an HSM I'm not too worried about it though.
Somebody that added nmap to their bot script.