Defense in depth. We can't ever prove that something is "secure", we can only take precautions. Is your SSH server secure? You can't tell, by definition, in a

Defense in depth. We can't ever prove that something is "secure", we can only take precautions. Is your SSH server secure? You can't tell, by definition, in a world where 0 day exploits exist. If you know where your requests are coming from, you can restrict to those IP addresses. It doesn't mean you think your server is insecure - but it's making the lives of people trying to get to it that much harder. If you don't know, then maybe fail2ban is a worthwhile alternative. It doesn't even necessarily mean you are trying to prevent brute forcing (password logins should always be disabled anyway) - but some exploits require multiple attempts. In the past I was against measures like changing the default port (although it should still be <1024). But these measures are helpful the moment some new exploit is in the wild that could twart naive scanning scripts. Same thing goes for hiding the banner. The best thing is still to automate things so that SSH access becomes a 'break the glass' moment. If you are always logging in via SSH(and it's a server, not a workstation that you work on), it means that there's something missing in the automation (or observability) that needs to be fixed.