No, it's a security by obscurity tactic.
If your sshd setup is not fit enough to face dumb script kiddies only trying port 22, you have a problem anyway.
A more rational reaction would be:
- make sure that your users are using good passwords which are hard to guess/brute-force
- disable password-authentication (at least for important accounts) and just use public-key-authentication
- watch out for ssh-security issues and upgrades
Some people may also be annoyed by the noise sshd writes into the system log, e.g.:
Jan 02 21:24:24 example.org sshd[28396]: Invalid user guest from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28396]: input_userauth_request: invalid user guest [preauth]
Jan 02 21:24:24 example.org sshd[28396]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth]
Jan 02 21:24:24 example.org sshd[28398]: Invalid user ubnt from 212.129.23.128
Jan 02 21:24:24 example.org sshd[28398]: input_userauth_request: invalid user ubnt [preauth]
Jan 02 21:24:24 example.org sshd[28398]: error: Received disconnect from 212.129.23.128: 3: com.jcraft.jsch.JSchException: Auth fail [preauth
It might be then tempting to obscure the sshd port or to use an automatic blocking solution (like DenyHosts, Fail2ban or BlockHosts) in order to increase the signal-to-noise ratio again.
But better alternatives do exist. For example, you can configure your syslog daemon such that the sshd log noise is only written to - say - /var/log/sshd-attempts.log and the signal (i.e. the remaining sshd log messages) is written to /var/log/messages etc. as before.
The deployment of automatic blocking tools should be considered carefully because adding more complexity to security relevant systems means also increasing the risk of exploitation. And indeed, over the years, there are several DoS vulnerability reports for each DenyHosts, Fail2ban and BlockHosts.