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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
