VanDyke Software Forums

Go Back   VanDyke Software Forums > General
User Name
Password
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply
 
Thread Tools Display Modes
  #1  
Old 12-04-2009, 09:29 AM
mdella's Avatar
mdella mdella is offline
Registered User
 
Join Date: Mar 2004
Location: Scotts Valley, CA
Posts: 33
Send a message via ICQ to mdella Send a message via AIM to mdella Send a message via MSN to mdella Send a message via Yahoo to mdella
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] : 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
__________________
Marcos Della
Distinguished Technologist, Principal System Architect
HP Web Services, Hewlett-Packard Corporation

PGP Fingerprint:
DF8C EBA0 87D0 C115 AC55 DF92 70A4 4896 9CC5 00AA
Key ID: 0x9CC500AA
Reply With Quote
  #2  
Old 12-04-2009, 10:23 AM
miked's Avatar
miked miked is offline
Registered User
 
Join Date: Feb 2004
Posts: 2,040
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).
__________________
Mike
VanDyke Software
Technical Support
[http://www.vandyke.com/support]
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 11:56 AM.


copyright 1995-2014 VanDyke Software, Inc.