Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > SecureCRT on the Mac

Reply
 
Thread Tools Rate Thread Display Modes
  #1  
Old 04-23-2014, 11:23 AM
epee63 epee63 is offline
Registered User
 
Join Date: Apr 2014
Posts: 2
Unable to connect to the Linux server

While connecting to the Linux server (probably Debian) I see the following messages in negotiation (connection suppose to use pub key for authentication):
[LOCAL] : SSH2Core version 7.2.0.500
[LOCAL] : Connecting to admin1-atl.clearleap.com:22 ...
SecureCRT - Version 7.2.3 (build 500)
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT
[LOCAL] : Using protocol SSH2
[LOCAL] : RECV : Remote Identifier = 'SSH-2.0-OpenSSH_5.8p1-hpn13v10lpk'
[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 encodes OID for gssapi
[LOCAL] : CAP : Remote correctly uses connected addresses in forwarded-tcpip requests
[LOCAL] : CAP : Remote can do SFTP version 4
[LOCAL] : CAP : Remote x.509v3 uses ASN.1 encoding for DSA signatures
[LOCAL] : CAP : Remote correctly handles zlib@openssh.com
[LOCAL] : SEND : KEXINIT
[LOCAL] : RECV : Read kexinit
[LOCAL] : Available Remote Kex Methods = diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
[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-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
[LOCAL] : Selected Send Cipher = aes256-ctr
[LOCAL] : Available Remote Recv Ciphers = aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
[LOCAL] : Selected Recv Cipher = aes256-ctr
[LOCAL] : Available Remote Send Macs = hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
[LOCAL] : Selected Send Mac = hmac-sha1
[LOCAL] : Available Remote Recv Macs = hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
[LOCAL] : Selected Recv Mac = hmac-sha1
[LOCAL] : Available Remote Compressors = none,zlib@openssh.com
[LOCAL] : Selected Compressor = none
[LOCAL] : Available Remote Decompressors = none,zlib@openssh.com
[LOCAL] : Selected Decompressor = none
[LOCAL] : Changing state from STATE_EXPECT_KEX_INIT to STATE_KEY_EXCHANGE
[LOCAL] : SEND : KEXDH_GEX_REQUEST
[LOCAL] : RECV : KEXDH_GEX_GROUP
[LOCAL] : SEND : KEXDH_INIT
[LOCAL] : RECV : KEXDH_REPLY
[LOCAL] : Changing state from STATE_KEY_EXCHANGE to STATE_READY_FOR_NEW_KEYS
[LOCAL] : RECV: Remote Hostkey: 21:94:ff:07:83:15:27:bf:af:9e:f2:c9:77:65:31:9f
[LOCAL] : SEND : NEWKEYS
[LOCAL] : Changing state from STATE_READY_FOR_NEW_KEYS to STATE_EXPECT_NEWKEYS
[LOCAL] : RECV : NEWKEYS
[LOCAL] : Changing state from STATE_EXPECT_NEWKEYS to STATE_CONNECTION
[LOCAL] : SEND: SERVICE_REQUEST[ssh-userauth]
[LOCAL] : RECV: SERVICE_ACCEPT[ssh-userauth] -- OK
[LOCAL] : SENT : USERAUTH_REQUEST [none]
[LOCAL] : RECV : USERAUTH_FAILURE, continuations [publickey,keyboard-interactive]
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ssh-rsa) - unsigned,agent,fingerprint: 03:93:17:9e:95:1a:00:42:63:66:64:ed:a3:a7:66:fa]
[LOCAL] : Changing state from STATE_CONNECTION to STATE_CLOSING
[LOCAL] : RECV: Disconnect packet (reason: 2: A protocol error occurred. Too many authentication failures for dulberg )
[LOCAL] : Changing state from STATE_CLOSING to STATE_CLOSED
[LOCAL] : Connected for 0 seconds, 1425 bytes sent, 2103 bytes received
[LOCAL] : Stream has closed [CLOSE_TYPE_NONSPECIFIC] : The server has disconnected with an error. Server message reads: A protocol error occurred. Too many authentication failures for dulberg

The server has disconnected with an error. Server message reads:
A protocol error occurred. Too many authentication failures for dulberg

Command line SSH connects with no issue.

Thanks,
Dima
Reply With Quote
  #2  
Old 04-23-2014, 11:41 AM
bgagnon bgagnon is offline
VanDyke Technical Support
 
Join Date: Oct 2008
Posts: 4,207
Hello Dima,

Note that this key being tried is coming from the agent:

Quote:
[LOCAL] : SENT : USERAUTH_REQUEST [publickey (ssh-rsa) - unsigned,agent,fingerprint: 03:93:17:9e:95:1a:00:42:63:66:64:ed:a3:a7:66:fa]
Is the same fingerprint shown in the command-line SSH log?

To clear agent keys (so that the one you have configured in the session is used), use the Tools menu option Manage Agent Keys.

I have added this thread to a feature request in our product enhancement database to allow the user to configure the order the keys for publickey authentication are tried. Should a future release of SecureCRT include this feature, notification will be posted here.

If you prefer direct e-mail notification, contact support@vandyke.com and include "Feature Request - Forum Thread #11476" in the subject line.


There is also a way (via editing an ini file) to configure SecureCRT to not try all agent keys (which is the default). Let me know if you want that info.
__________________
Thanks,
--Brenda

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730
Reply With Quote
  #3  
Old 04-24-2014, 07:55 AM
epee63 epee63 is offline
Registered User
 
Join Date: Apr 2014
Posts: 2
Issue resolved

Thank you very much - after removing all other keys from the agent login works fine.
Since I am using only one key across all hosts this should not be an issue, but the ability to re-order agent keys would be nice.

Regards,
Dima
Reply With Quote
  #4  
Old 05-27-2014, 03:35 PM
Maureen's Avatar
Maureen Maureen is offline
VanDyke Product Director
 
Join Date: Feb 2004
Location: Albuquerque, NM
Posts: 1,567
For those of you who have trouble with the agent keys option because you're hitting the maximum number of authentication retries, we have changed this option so that it tries the key associated with the session first. This has been implemented in a pre-beta version of SecureCRT and SecureFX. If you would like to try it, please send email to me at Maureen.Jett@vandyke.com.

Maureen
Reply With Quote
  #5  
Old 12-17-2014, 11:20 AM
bgagnon bgagnon is offline
VanDyke Technical Support
 
Join Date: Oct 2008
Posts: 4,207
Hello,

I just wanted to post an update for anyone that has experienced an issue where public-key auth in SecureCRT or SecureFX failed due to the fact that agent keys were tried first and sometimes the max number of auth tries would be exceeded.

This change was made as of SecureCRT/SecureFX v7.3 (although excerpts are from SecureCRT history documents, the same is true of SecureFX):

Changes in SecureCRT 7.3 (Beta 1) -- August 7, 2014
---------------------------------------------------

Changes:

  • When connecting a session, if there's an agent key associated with the session, it is tried first. This can help prevent a session from failing to connect because the maximum number of authentication retries was exceeded.

What was a requirement (in v7.3.0), for OpenSSH format keys (generated using ssh-keygen), was that the public-key file had to be found in the same location as
the private-key file. Since some of our customers experienced issues because they did not retain those public-key files after providing to the admins of the remote servers, we added this functionality in v7.3.1:

Changes in SecureCRT 7.3.1 (Official) -- December 4, 2014
---------------------------------------------------------

Changes:
  • SSH2: When using public-key authentication, if the .PUB file is not present, it is created automatically so that agent will work.

You can check if your license is eligible for v7.3.x here:
http://www.vandyke.com/pricing/upgra...urecrt_el.html
http://www.vandyke.com/pricing/upgra...curefx_el.html
I hope this information helps and that the new functionality is useful for anyone who has experienced the prior issue with agent.
__________________
Thanks,
--Brenda

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730
Reply With Quote
Reply


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

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 11:40 PM.