I have to partially disagree with the other answers because changing the port does not necessarily protect you against an actual targeted attack (in case which someone would be able to just scan all the ports and find the SSH one), but it does protect you against botnets that do bruteforce over random or selected hosts with dictionaries. And even in this case, I assume that every decent technical person will know to make sure that the passwords are strong enough, not to mention that newer installations of software actually do require you to have strong passwords. What I think that it protects you against are distributed denial of service attacks that could really get your server slow, fill the logs with crap and so on. While fail2ban & co. could do a nice job against a single host doing this, they are pretty ineffective against a really big botnet.
On the other side, I see no reason why you would leave your SSH port open to the Internet, unless you run something like a web host that provides SSH access or something. Otherwise, you should only allow very specific IPs that you trust to connect to SSH, this is THE BEST practice. Not port knocking, not changing the port, not fail2ban.
So, if you ask me, there are 2 options:
- You have a specific need to let SSH open for the Internet. In this case you would change the SSH port AND install fail2ban (maybe even set accounts to lock after X failed password attempts).
- You close SSH and whitelist only certain IPs.
EDIT:
Forgot about the over 1024 and under 1024 thing. Many firewalls indeed have specific rules that could make using a port under 1024 to have more sense. For example there are firewalls that deny connections incoming on ports higher than 1024 (so that you really need to have a service started with root or the required Kernel capabilities that listens to a port and not some exploit), other firewalls are giving more priorities to lower ports so that the system services can benefit of this etc.