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 workaround is simply to add "Protocol 1,2" to ssh_config and force it to wait for banner. I'm just not quite sure that this is a good idea to add such config option, cause everywhere you can see advises never to use ssh version 1, and probably it would be a security loss to allow one's client to connect to v.1 servers. 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? Alex. Thank you!
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