Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > General

Reply
 
Thread Tools Display Modes
  #1  
Old 08-05-2004, 02:21 PM
aLTeReGo's Avatar
aLTeReGo aLTeReGo is offline
Registered User
 
Join Date: Jun 2004
Posts: 8
SecureCRT

Whenever I attempt to connect to my AireSpace equipment that requires SSH2 I get to type in my username but when I press "ok" I get disconnected immediately. This is not the case with Putty. I haven't yet seen another piece of equipment that behaves like this but if anyone has any idea might be going on with SSH in SecureCRT with AireSpace please let me know. Thanks!
Reply With Quote
  #2  
Old 08-06-2004, 10:00 AM
jpv jpv is offline
Weekend Programmer and CEO
 
Join Date: Nov 2003
Location: VanDyke Software
Posts: 54
Quote:
Originally Posted by aLTeReGo
Whenever I attempt to connect to my AireSpace equipment that requires SSH2 I get to type in my username but when I press "ok" I get disconnected immediately. This is not the case with Putty. I haven't yet seen another piece of equipment that behaves like this but if anyone has any idea might be going on with SSH in SecureCRT with AireSpace please let me know. Thanks!
Prior to connecting with SecureCRT, can you toggle on "File / Trace Options".

When you connect, what is displayed?

--Jeff
Reply With Quote
  #3  
Old 08-06-2004, 11:04 AM
aLTeReGo's Avatar
aLTeReGo aLTeReGo is offline
Registered User
 
Join Date: Jun 2004
Posts: 8
I hope this is what you were looking for...

SecureCRT - Version 4.1.7 (build 257)
[LOCAL] : RECV : Remote Identifier = "SSH-2.0-OpenSSH_3.6p2-aes"
[LOCAL] : CAP : Remote can re-key
[LOCAL] : CAP : Remote sends language in password change requests
[LOCAL] : CAP : Remote sends algorithm name in PK_OK packets
[LOCAL] : CAP : Remote sends algorithm name in public key packets
[LOCAL] : CAP : Remote sends algorithm name in signatures
[LOCAL] : CAP : Remote sends error text in open failure packets
[LOCAL] : CAP : Remote sends name in service accept packets
[LOCAL] : CAP : Remote includes port number in x11 open packets
[LOCAL] : CAP : Remote uses 160 bit keys for SHA1 MAC
[LOCAL] : CAP : Remote supports new diffie-hellman group exchange messages
[LOCAL] : CAP : Remote correctly handles unknown SFTP extensions
[LOCAL] : CAP : Remote correctly sends UTF8 where UTF8 is specified
[LOCAL] : CAP : Remote correctly encodes OID for gssapi
[LOCAL] : CAP : Remote correctly uses connected addresses in forwarded-tcpip rs
[LOCAL] : CAP : Remote is IETF-DRAFT compliant
[LOCAL] : SEND : KEXINIT
[LOCAL] : RECV : Read kexinit
[LOCAL] : Available Remote Kex Methods = diffie-hellman-group-exchange-sha1,dif1
[LOCAL] : Selected Kex Method = diffie-hellman-group-exchange-sha1
[LOCAL] : Available Remote Host Key Algos = ssh-rsa,ssh-dss
[LOCAL] : Selected Host Key Algo = ssh-dss
[LOCAL] : Available Remote Send Ciphers = aes128-cbc,3des-cbc,blowfish-cbc,caste
[LOCAL] : Selected Send Cipher = aes128-cbc
[LOCAL] : Available Remote Recv Ciphers = aes128-cbc,3des-cbc,blowfish-cbc,caste
[LOCAL] : Selected Recv Cipher = aes128-cbc
[LOCAL] : Available Remote Send Macs = hmac-md5,hmac-sha1,hmac-ripemd160,hmac-r6
[LOCAL] : Selected Send Mac = hmac-md5
[LOCAL] : Available Remote Recv Macs = hmac-md5,hmac-sha1,hmac-ripemd160,hmac-r6
[LOCAL] : Selected Recv Mac = hmac-md5
[LOCAL] : Available Remote Compressors = none,zlib
[LOCAL] : Selected Compressor = none
[LOCAL] : Available Remote Decompressors = none,zlib
[LOCAL] : Selected Decompressor = none
[LOCAL] : SEND : KEXDH_GEX_REQUEST
[LOCAL] : RECV : KEXDH_GEX_GROUP
[LOCAL] : RECV : DH Prime is 1024 bits
[LOCAL] : SEND : KEXDH_INIT
[LOCAL] : RECV : KEXDH_REPLY
[LOCAL] : SEND : NEWKEYS
[LOCAL] : RECV : NEWKEYS
[LOCAL] : SEND: SERVICE_REQUEST[ssh-userauth]
[LOCAL] : RECV: SERVICE_ACCEPT[ssh-userauth] -- OK
[LOCAL] : SENT : USERAUTH_REQUEST [none]
[LOCAL] : RECV : AUTH_SUCCESS
[LOCAL] : SEND: agent forwarding request
[LOCAL] : RECV: TCP/IP close
[LOCAL] : Connected for 5 seconds, 863 bytes sent, 1586 bytes received
Reply With Quote
  #4  
Old 08-06-2004, 11:53 AM
jcj's Avatar
jcj jcj is offline
VanDyke Quality Assurance
 
Join Date: Nov 2003
Posts: 65
aLTeReGo -

In your Session Optiions, under the Connection category, do you have a username filled-in in the username field ? If not, if you put the appropriate username there, and then try to connect, do you see better behavior ?

Please let us know.


~JcJ
Reply With Quote
  #5  
Old 08-06-2004, 12:22 PM
aLTeReGo's Avatar
aLTeReGo aLTeReGo is offline
Registered User
 
Join Date: Jun 2004
Posts: 8
I have tried putting my username in the connection properties and without. The result is the same. The only difference when I have my username in the connection properties is it just connects and disconnects. When I don't put my username in the field I get prompted to put my username in and then I get disconnected. That is what you would expect given the problem.

It's strange that Putty has no problems. I would be happy to test any other windows SSH client you can think of that has a free demo/trial download if you think that would help.
Reply With Quote
  #6  
Old 08-06-2004, 02:28 PM
jcj's Avatar
jcj jcj is offline
VanDyke Quality Assurance
 
Join Date: Nov 2003
Posts: 65
Thanks for the quick feedback.

From the SecureCRT perspective, what looks like is going on here is that the "none" authentication request that is sent to query the SSH2 server for its available authentication methods is succeeding. Just about every SSH2 client out there does the same thing (PuTTY included), as it is prescribed in the protocol drafts. Normally, the none request would be expected to fail for most server configurations. The expected response is a failure and a list of the available authentication methods supported by the server. If you look at the trace options output you posted above, it's pretty clear that SecureCRT receives a message from the server that the authentication was successful. When the none authentication request is sent, a username is also sent, and this is going to be whatever is entered in the username field of your Session Options. In all likelyhood, after you get authenticated as whatever username is sent during the "none" phase of authentication, the server doesn't know what to do, so you get booted almost immediately.

One other thing appears in the log which *could* be causing problems. Just in case, I'd be curious to see if disabling "Enable OpenSSH Agent Forwarding" in your Global Options, under the SSH2 category helps at all.

Any of the following may also help us get to the bottom of this:

- a log file from PuTTY - (Session / Logging) turn on all the options, but beware that your password will appear in plain-text in the file with "Log SSH Packet Data", so you might want to edit that out before you post it
- sshd logs from the server-side, if available, ideally with details from connection attempts from each cleint

Please keep us informed.


~JcJ
Reply With Quote
  #7  
Old 08-06-2004, 04:50 PM
aLTeReGo's Avatar
aLTeReGo aLTeReGo is offline
Registered User
 
Join Date: Jun 2004
Posts: 8
My Putty log is available here


This box I'm running is a demo unit only. I'm not to worried about the username/password.... for anyone who can't decrypt it, the username is "admin" and the password is "admin".
Reply With Quote
  #8  
Old 08-06-2004, 06:04 PM
jcj's Avatar
jcj jcj is offline
VanDyke Quality Assurance
 
Join Date: Nov 2003
Posts: 65
Thanks again for the information.

I believe I see what may be happening here. With enough information, this may be something we can submit to our developers as a bug.

Using PuTTY, the none authentication request succeeds as well. If you look at the PuTTY log, after the none authentication is accepted, and the shell request succeeds, you are presented with a username and password prompt from the server. This is a litttle unusual, since typically at this point you'd already be authenticated. Nonetheless, this shouldn't be a problem, since it looks like this is all just coming down the main ssh channel.

Did you try turning off agent forwarding ? It's possible that the agent forwarding request is being sent by SecureCRT and is being interpreted as login data by the remote, which would probably cause it to fail and could explain the disconnect.

Out of curioisity, SecurCRT ships with a command-line executable called VSH.EXE - if you try connecting to this same device with it, do you see similar behavior as you do with SecureCRT ?

Please let us know.


~JcJ
Reply With Quote
  #9  
Old 08-06-2004, 06:17 PM
aLTeReGo's Avatar
aLTeReGo aLTeReGo is offline
Registered User
 
Join Date: Jun 2004
Posts: 8
Wow!

Turning off Agent forwarding resolved the issue! I can now connect to my AireSpace unit using SSH... NICE CALL!

Now what did turning that off do? Can I no longer use port forwarding on my other SSH connections?

Thanks!
Reply With Quote
  #10  
Old 08-18-2004, 02:42 PM
jcj's Avatar
jcj jcj is offline
VanDyke Quality Assurance
 
Join Date: Nov 2003
Posts: 65
Quote:
Originally Posted by aLTeReGo
Wow!

Turning off Agent forwarding resolved the issue! I can now connect to my AireSpace unit using SSH... NICE CALL!

Now what did turning that off do? Can I no longer use port forwarding on my other SSH connections?

Thanks!
Sorry for not posting for a bit.

I'm glad this helped - thanks for letting us know.

Agent forwarding allows the client to forward off a cached set of credentials to the ssh-server, so, for instance, if you've already authenticated once using public-key authentication, you don't have to enter your passphrase again. In order for this to function, both the client and the server have to support the agent mechanism. In your case, SecureCRT was sending the agent forwarding request, and the server was dropping the connection at that point, presumably because it was expecting the client to start sending a username and password instead of an agent forwarding request. Essentially, instead of your typed username, the agent request data was getting "entered" as your username, and clearly this wasn't meaningful to the server so it dropped the connection.

Agent forwarding doesn't really have much effect on port-forwarding beyond helping ease the pain of having to enter your passphrase more than once for multiple public-key authentications using the same key, so you should continue to be able to use port-forwarding just fine.

Please let us know if you need additional information or assistance.


Cheers~

~JcJ

Last edited by jcj; 08-18-2004 at 03:02 PM.
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 -6. The time now is 02:34 AM.