VanDyke Software Forums

VanDyke Software Forums (
-   General (
-   -   Error connecting to SSH-2.0-Sun_SSH_1.1.2 (

mdella 12-04-2009 11:29 AM

Error connecting to SSH-2.0-Sun_SSH_1.1.2
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] : RECV: TCP/IP close
[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:

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.


miked 12-04-2009 12:23 PM

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).

All times are GMT -6. The time now is 06:39 PM.