default change in 6.2 breaks sslh

mancha mancha1 at hush.com
Wed Jan 29 02:12:15 EST 2014


Rakulenko A. <me <at> rakul.info> writes:
> 
> Hi all!
> 
> I'm using sslh. It's a multiplexer, used to let you have ssh, https,
> stunnel, etc on one port.
> In 6.2 there is a change in default behaviour:
> 
>  * ssh(1): When SSH protocol 2 only is selected (the default), ssh(1)
>    now immediately sends its SSH protocol banner to the server without
>    waiting to receive the server's banner, saving time when connecting.
> 
> which, i suppose, breaks the way sslh detects openssh traffic. I found
> the cause in this discussion:
> http://rutschle.net/pipermail/sslh/2011-January/000045.html
> which is related to similar problem, but with "connectBot" - a mobile
> ssh client.

The ML message you post, aside from being inaccurate (nothing in the
SSH 2.0 specification prevents the client from firing off its banner
immediately), is quite dated.

I built sslh 1.15 (latest point release) and it has no issue handling
an OpenSSH 6.4 client connect in Protocol 2 mode (where the client
sends its banner immediately after the TCP handshake).

Looking at old sslh code, it seems it once relied on client-side
silence to distinguish ssh from ssl traffic (ugh). What version
of sslh are you using?
 
> Maybe, if i'm getting everything right, there may be a way to add an
> option to force ssh to wait for banner, set off by default?

My quick read of current OpenSSH code is the client banner will be
sent immediately when in "Protocol 2" mode and there is no override
for this behavior.

--mancha



More information about the openssh-unix-dev mailing list