On Jan 24, 2014, at 3:31 AM, Darren Tucker <dtucker at zip.com.au> wrote: > On Fri, Jan 24, 2014 at 9:38 PM, Kumar, Yogendra <Yogendra.Kumar at ncr.com> wrote: > [...] >> Connecting to b2bpsftp.dell.com... >> Sun_SSH_1.1.4, SSH protocols 1.5/2.0, OpenSSL 0x0090704f > > This is not OpenSSH, it's a derivative modified work by Sun/Oracle. > We can't help you with this. > > [...] >> debug1: Remote protocol version 2.0, remote software version SecureLink SSH Server (Version 3.2.1.142) > > This is also not OpenSSH, and I've never even heard of it before. We > can't help you with this either. I will say that since your failing > case didn't even get the remote banner, I'd be looking for problems > with your network. > > Can you reproduce the problem with the stock OpenSSH built from the > code from openssh.com? I ran across something like this when writing my own SSH server recently. I don?t know if it applies here but in my case it turned out to be related to the fact that the Sun client sent its version identification with only a ?\n? at the end of the line instead of ?\r\n?. My server was sending ?SSH-2.0? as the version ending with ?\r\n? and the client accepted that just fine, but the client sent its version as ?SSH-2.0? ending with only ?\n?. I had to generalize my server code to accept either ?\r\n? or just ?\n? as a line terminator for the handshake to proceed. I think the client is out of spec here, but it was a simple change to make. From what I can see in the RFC, the only case where ?\n? should be used is on the server when it is in SSHv1-compatibility mode and it sends ?SSH-1.99? as the version. -- Ron Frederick ronf at timeheart.net
