Hi Müzso,

Absolutely agree! This is just an interesting and quick way to change the banner and not in of itself a way to secure an SSH service.

1. Compiling a different banner from source, and especially tying to automate this for updates would be a lot more difficult.

2. In the example from the article, I have left the protocol version untouched (i.e. still has ‘SSH-2.0-) which should allow most clients to connect without issue. I should have noted above that this part is required. Changes after this will just confuse the client/world about what software version is running – which is part of the point. I am the only consumer of my server and the banner is for my own amusement. In a serious commercial setting, the banner may actually be important for things like inventory management and looking for servers that need to be patched.

3. This article isn’t about how to secure an SSH server. There are many things which I would recommend for that (on my server I have locked down root access, require an SSH key and whitelist inbound IPs amongst others). Just as would come from changing the port you run SSH on, the added obscurity reduces exposure and the likelihood of being on a database of targets when the next vulnerability is discovered. One should always expect and behave as though you are at the top of the list however.

I appreciate the feedback and agree with your points. To be clear, this is not a way to make a SSH server secure from threat; its a ‘quick and dirty’ way to change the banner (that I have done for my own amusement – I use IP whitelisting to prevent my banner being seen outside my trusted networks). There are many services on the internet that obscure the software they are running (not uncommon on web servers) precisely to reduce the likelihood of being targeted, ever if they are no more secure than an equivalent service broadcasting its version information.

1. As you already mentioned: “This change will only be temporary as any time you update OpenSSH, the binary will be replaced.” So unless you want to mess with the sshd binary after every single update of the openssh-server package (either with hex editing or recompiling the latter seems to be easier to automate in a robust manner), you don’t want to go down this road.

2. The SSH specification (RFC) prohibits any comliant implementation from messing with the software version part of the identification string.
https://tools.ietf.org/html/rfc4253#section-4.2

3. Lying about the software version or hiding it is “security through obscurity” which is a possible, although a widely questioned practise. Reference: https://en.wikipedia.org/wiki/Security_through_obscurity
If you know you have an old and vulnerable ssh daemon (i.e. with publicly known vulnerabilities) and for some reason you cannot deploy fixes, you’re in trouble anyway. Hiding software version numbers merely makes it a bit more difficult to identify your service/server as a target. Most vulnerabilities get a proof-of-concept code and a large number of these are integrated into vulnerability scanners, which do not rely on the version string that the service tells about itself.

To summarize: I think you’re better off spending your time on actual security (eg. deploying updates) instead of hiding potential vulnerabilities.