Added option to manually specify key exchange banner for sshd

[UFeindschiff]

The Problem

SSH key exchange identification works in such a way that as soon as a TCP connection is established, the SSH server writes its key exchange banner in the TCP connection. This (according to RFC 4253) always follows the following pattern SSH-protoversion-softwareversion SP comments CR LF. In the case of OpenSSH this translates to SSH-2.0-OpenSSH_<version><CR><LF>. This however makes it trivial to enumerate the SSH server being OpenSSH as well as its exact version. This makes servers which are running older versions and therefore may be lacking security fixes easy to detect and these servers may be targeted by automated attack scripts as a result. In addition, it may allow others to build a profile on your updating habits.
As a result, some users may want to specify a custom key exchange banner in order to not propagate the server software in its exact version.

The Solution

This patch proposes the addition of a new BannerOverride config key in the sshd_config. If this key is set, the key exchange identification banner will be replaced by whatever value BannerOverride holds. (e.g. SSH-2.0-Foobar<CR><LF>). There is no change to the current behavior if the key is unset.

[djmdjm]

Sorry but we do not want this.

[djmdjm]

Just to expand on why:

1. Hiding the name does not make the vulnerability go way. Attacks can be made ignoring or in spite of the version string. Many attack tools will attempt exploitation without even looking at the version string.
2. The version string is a load-bearing part of the protocol, see compat.c. Falsifying it may break things.
3. It's fairly trivial to fingerprint a SSH version, based on available protocol features, default ciphers, etc.

So we're not interested in adding an obscurity feature that has no positive security benefit. If anything, implementing this would have a negative effect, as it would remove an incentive for operators to upgrade old/vulnerable servers.

[UFeindschiff]

I think you slightly misunderstood my motivation. This patch wasn't meant to fool exploiting tools, just as a possibility to not propagate the server version (as is already best practice when it comes to other commonly used protocols).

1. Hiding the name does not make the vulnerability go way. Attacks can be made ignoring or in spite of the version string. Many attack tools will attempt exploitation without even looking at the version string.

This is all obviously true. My point wasn't that changing the version string will fool some attack tool, but that you can for example just do a scan of TCP port 22 in the IPv4-Internet and that way easily identify all reachable OpenSSH servers listening on the default port in their exact version.
Additionally, as many downstream packagings of OpenSSH stick to a certain version they backport security fixes to, this often leads to false positives when it comes to security scans.

2. The version string is a load-bearing part of the protocol, see compat.c. Falsifying it may break things.

Yes, using a custom version banner comes at the cost of decreased compatibility.

3. It's fairly trivial to fingerprint a SSH version, based on available protocol features, default ciphers, etc.

True, but it requires more work than just opening a TCP connection and reading a string that the server sends.

Nonetheless, thank you for your time and for explaining your reasoning why you don't want the version string to be settable by the user. I respect your decision and understand your reasoning even though I can't say I agree with it.

I guess I may approach package maintainers of popular distributions with such a patch.

Again, thank you for your time and have a great day.