Error connecting to SSH-2.0-Sun_SSH_1.1.2

[mdella]

Well since this particular problem took a day of research, packet traces, etc to figure out, I thought others might want to see the results in the event that others have problems connecting with *recent* versions of SecureCRT to a Sun Solaris 10 box (with recent sshd software).

The symptoms are typically that you try connection to a Solaris box and *immediately* it disconnects without offering a host key, etc. On first glance it looks like either a networking problem or firewall problem because of how quickly it disconnects. Turns out there is a bug in the sun sshd service.

During initial negotiation with the server, as a client, you pass all the possible encryption algorithms that you are capable of handling for the session. The server is then supposed to look through those and select one that it likes and the handshake continues.

With SSH-2.0-Sun_SSH_1.1.2 ssh demon, it turns out that if the FIRST item you offer in your CSV list is not supported by the sshd, then it sends a network [RST,FIN] immediately and terminates the connection. From the log point on your side, it would look something like...

...[deleted for space]...
[LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_KEY_EXCHANGE
[LOCAL] : SEND : KEXDH_GEX_REQUEST
[LOCAL] : RECV: TCP/IP close
[LOCAL] : Changing state from STATE_KEY_EXCHANGE to STATE_CLOSED
[LOCAL] : Connected for 0 seconds, 519 bytes sent, 542 bytes received

So as you can see here, you send the GEX request however the other side basically closed the connection.

Turns out that the solaris sshd does NOT support the following:
AES-256-CTR
AES-192-CTR
AES-128-CTR
AES-256
AES-192

These can *either* be deselected in the Session Options -> Connection -> SSH2 -> Advanced tab or they can be moved down the list to the bottom (that is, you can still offer them as long as they aren't at the top of the list).

This was a FRUSTRATING bug as ssh works fine otherwise. So connecting from a solaris box to another solaris box works fine. Using SecureCRT (or even a recent version of PuTTy) does not which leads one to think there is a problem with the *client* software, not the server software.

Marcos

[miked]

Hi Marcos,

Thanks for your informative post!

I can confirm that this solution also worked for a customer we spoke with recently who was experiencing the same problematic behavior with the same server (Sun_SSH_1.1.2).