Question Reagrding open SSH

[Ron Frederick]

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