0

I have opensshd listening on the non-standard tcp port of 2222. In sshd_config I have ...

Banner none
VersionAddendum none

If from a client host I do a telnet ip.of.server 2222 then I see the service displaying a message introducing itself like so ...

SSH-2.0-OpenSSH_7.8

Is there a way to prevent this happening and instruct the openssh daemon not to reveal itself? I would prefer if "wandering" connections could not learn what is listening here.

Keve
  • 115
  • 5

1 Answers1

2

The minimal identification string for the ssh protocol is:

SSH-2.0-

however OpenSSH will always send at least OpenSSH_*.*. If you want a more stealth behaviour you have several options:

  1. You can patch and recompile openssh so that the server waits for the client's identification string before sending its own (cf. the sshd_exchange_identification function). If the client's identification string does not start with SSH, it's a bogus client and you can close the connection. It might break some clients (if they wait for the server's identification), but it should not break the OpenSSH client. A portscanner will not be able to deduce the server's protocol, unless he sends a valid client authentication string.
  2. Install and configure nginx. Normally it is a HTTP/HTTPS (proxy) server) and it has an ssl preread module, which is used to apply different configurations to different TLS clients (based on their version and other parameters). However if you connect to nginx using a protocol it does not understand, it will set $ssl_preread_protocol to the empty string and you can redirect the connection to an SSH server. If a portscanner tries to use TLS, nginx will serve him a web page. If he tries any other protocol, he'll receive OpenSSH's identification string.
  3. There is a small protocol multiplexer (sslh), which guessed a client's protocol and redirects it to the correct server.

These options should answer your question, but it do not believe the security through obscurity is the way to go (besides port 2222 is not very original). You'd be better off:

  1. disabling password logins,
  2. using something like fail2ban to limit the amount of brute force attacks.
Piotr P. Karwasz
  • 5,748
  • 2
  • 11
  • 21
  • Your insights are much appreciated, Piotr! I did consider 1), but I did not know about 3) and I certainly would not have thought of 2) while these are both sensible options. I very much agree with your perspective. The service allows pubkey auth only, and it is not on tcp 2222 -for the purposes of this post here it was a self-explanatory example and obviously worked well. – Keve Jan 01 '20 at 23:26