Welcome to the VanDyke Software Forums

Join the discussion today!


Go Back   VanDyke Software Forums > General

Reply
 
Thread Tools Display Modes
  #1  
Old 12-18-2018, 04:38 AM
Linda's Avatar
Linda Linda is offline
Registered User
 
Join Date: Sep 2004
Location: SF-Bay Area/CA
Posts: 24
Unhappy problem: seccrt cannot connect to my sys after openssl update

I recently updated openssl libraries to build a linux prog with latest binaries -- unfortunately, it seems to have had the side effect of locking out logins via secureCRT.

All I get in login window is 'connection closed'.

Fortunately, I have seccrt configured to login to my local win system where I can use it in tty mode as a local console (of sorts) via rsh which needs no password or encryption, so that still worked. From there, I was able to use cygwin's ssh client to login to my linux system w/no problem.

So...guess main question is why does ssh work so easily but not seccrt. Originally I had them using the same login key, but don't know if that was still the case.

I was using seccrt 7.2 at the time, and d/l'ed 8.5 to see if maybe a version refresh would solve the problem. Nope...same symptom. Turned on trace and local log, to look for problems, but nothing jumped out. Also opened up log window on remote system to see if it indicated anything -- but nothing that I could understand as the problem.

Any ideas would be appreciated! Will attach local and server logs below. Thanks!


Local log:




[PRINTER] : Printer initialization succeeded
[LOCAL] : SSH2Core version 8.5.0.1799
[LOCAL] : Connecting to ishtar:22 ...
SecureCRT - Version 8.5.2 (x64 build 1799)
[LOCAL] : Resolved hostname to 192.168.3.1:22
[LOCAL] : Changing state from STATE_NOT_CONNECTED to STATE_EXPECT_KEX_INIT
[LOCAL] : Using protocol SSH2
[LOCAL] : RECV : Remote Identifier = 'SSH-2.0-OpenSSH_6.6.1'
[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 uses SHA1 hash in RSA signatures for x.509v3
[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 = curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,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,ecdsa-sha2-nistp256,ssh-ed25519
[LOCAL] : Selected Host Key Algo = ssh-rsa
[LOCAL] : Available Remote Send Ciphers = aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
[LOCAL] : Selected Send Cipher = arcfour
[LOCAL] : Available Remote Recv Ciphers = aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
[LOCAL] : Selected Recv Cipher = arcfour
[LOCAL] : Available Remote Send Macs = hmac-md5-etm@openssh.com,hmac-sha1-e...60@openssh.com,hmac-sha1-96,hmac-md5-96
[LOCAL] : Selected Send Mac = umac-64@openssh.com
[LOCAL] : Available Remote Recv Macs = hmac-md5-etm@openssh.com,hmac-sha1-e...60@openssh.com,hmac-sha1-96,hmac-md5-96
[LOCAL] : Selected Recv Mac = umac-64@openssh.com
[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] : RECV : DH Prime is 2048 bits
[LOCAL] : SEND : KEXDH_INIT
[LOCAL] : RECV: TCP/IP close
[LOCAL] : Changing state from STATE_KEY_EXCHANGE to STATE_CLOSED
[LOCAL] : Connected for 0 seconds, 626 bytes sent, 1951 bytes received

[LOCAL] : Stream has closed [CLOSE_TYPE_NONSPECIFIC] : Connection closed.

Connection closed.

-----------------------------------------------------------------

Remote log: (sshd)

# /usr/sbin/sshd -e -d -D
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.2o-fips 27 Mar 2018
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: private host key: #3 type 4 ED25519
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-e'
debug1: rexec_argv[2]='-d'
debug1: rexec_argv[3]='-D'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 127.0.0.1.
Server listening on 127.0.0.1 port 22.
debug1: Bind to port 22 on 192.168.3.1.
Server listening on 192.168.3.1 port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.2o-fips 27 Mar 2018
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: private host key: #3 type 4 ED25519
debug1: inetd sockets after dupping: 3, 3
Connection from 192.168.3.12 port 2423 on 192.168.3.1 port 22
debug1: Client protocol version 2.0; client software version SecureCRT_8.5.2 (x64 build 1799)
debug1: no match: SecureCRT_8.5.2 (x64 build 1799)
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: permanently_set_uid: 22/22 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server arcfour umac-64@openssh.com none [preauth]
debug1: kex: server->client arcfour umac-64@openssh.com none [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: Killing privsep child 18849
Reply With Quote
  #2  
Old 12-18-2018, 07:41 AM
bgagnon bgagnon is offline
VanDyke Technical Support
 
Join Date: Oct 2008
Posts: 3,854
Hi Linda,

You will want to be careful jumping to a post 7.3.3 build if your plan is to go back to v7.2 because of this encryption change:

Changes in SecureCRT 7.3.3 (Official) -- March 31, 2015
-------------------------------------------------------
New features:

  • Previous versions of SecureCRT supported saving passwords and other sensitive data. In order to improve the security of this feature, SecureCRT now allows a passphrase to be created the first time version 7.3.3 runs. This passphrase will be used to encrypt and decrypt sensitive data stored in the session database, such as passwords and send/expect logon scripts.
It is only a factor if you save passwords in your sessions, which of course is not recommended.

As to the issue shown in trace options output, in the Connection / SSH2 category of Session Options (in the Key exchange grouping), is diffie-hellman-group-exchange-sha256 enabled? Also, what is the configuration in the Minimum group exchange prime size?

The latter option was added in v8.0 and support for diffie-hellman-group-exchange-sha256 in v7.3 so if that's the solution, an upgrade would be recommended.

Sorry, I do not know OpenSSH logging well enough to determine from the server log files if that's the exact issue.
__________________
Thanks,
--Brenda

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730
Reply With Quote
  #3  
Old 12-18-2018, 08:40 AM
Linda's Avatar
Linda Linda is offline
Registered User
 
Join Date: Sep 2004
Location: SF-Bay Area/CA
Posts: 24
If I had not said:

Quote:
I was using seccrt 7.2 at the time, and d/l'ed 8.5 to see if maybe a version refresh would solve the problem. Nope...same symptom.
Your advice might have been pertinent.

Fortunately, the software warns about this change when upgrading.

In my case, though, it seems to make no difference. I can run both versions side-by-side. My 7.2 copy saves its settings per/user, but when I installed 8.x I saved it to the global location. So if I start an icon associated w/7.2, it uses the 7.2 location (per user) and the 8.x version uses the global location.

I also made a backup of the existing global, just in case.
Reply With Quote
  #4  
Old 12-18-2018, 09:18 AM
bgagnon bgagnon is offline
VanDyke Technical Support
 
Join Date: Oct 2008
Posts: 3,854
Hi Linda,

As a note, when support for new algorithms are added to our products, they are not automatically enabled in an existing config.

The trace options output clearly shows the remote server is closing the connection:

[LOCAL] : RECV: TCP/IP close

You will need to troubleshoot the issue from the server side.

You can add multiple d's to get more detailed debugging info (-ddd).
__________________
Thanks,
--Brenda

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

Last edited by bgagnon; 12-18-2018 at 09:35 AM. Reason: d not v for debug server
Reply With Quote
  #5  
Old 12-18-2018, 10:11 AM
Linda's Avatar
Linda Linda is offline
Registered User
 
Join Date: Sep 2004
Location: SF-Bay Area/CA
Posts: 24
Quote:
Originally Posted by bgagnon View Post
Hi Linda,

As a note, when support for new algorithms are added to our products, they are not automatically enabled in an existing config.
I installed the product as a new product, not as an upgrade, but the connection-.config file didn't list the new algorithms. Checked those and resaved with no change in result.

Quote:
The trace options output clearly shows the remote server is closing the connection.
You will need to troubleshoot the issue from the server side.
That's why I included both logs, since the server log seems a bit vague on reasons the session was closed:

debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server arcfour umac-64@openssh.com none [preauth]
debug1: kex: server->client arcfour umac-64@openssh.com none [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup
debug1: Killing privsep child 18849


Adding '-v' switches created more output, but nothing that pointed at the problem, like a missing or mismatch of protocols message.

If only computers were better at diagnosing themselves.
Reply With Quote
  #6  
Old 12-18-2018, 10:38 AM
bgagnon bgagnon is offline
VanDyke Technical Support
 
Join Date: Oct 2008
Posts: 3,854
Hi Linda,

OpenSSH is not our product. I am not expert in interpreting the debug logs from an OpenSSH server, therefore, you will need to analyze the server side logs on your own (with help of internet?).
__________________
Thanks,
--Brenda

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730
Reply With Quote
  #7  
Old 12-18-2018, 10:45 AM
bgagnon bgagnon is offline
VanDyke Technical Support
 
Join Date: Oct 2008
Posts: 3,854
Hi Linda,

Quote:
So...guess main question is why does ssh work so easily but not seccrt. Originally I had them using the same login key, but don't know if that was still the case.
Can you post a debug log from the ssh client (with -vvv)?
__________________
Thanks,
--Brenda

VanDyke Software
Technical Support
support@vandyke.com
(505) 332-5730
Reply With Quote
  #8  
Old 12-18-2018, 05:08 PM
Linda's Avatar
Linda Linda is offline
Registered User
 
Join Date: Sep 2004
Location: SF-Bay Area/CA
Posts: 24
Sorry for delay...am getting stretched about 8 different ways today...

-vvv output from cygwin ssh is in ssh2.txt attachment.
Attached Files
File Type: txt ssh2.txt (12.0 KB, 42 views)
Reply With Quote
  #9  
Old 12-18-2018, 05:33 PM
jdev's Avatar
jdev jdev is offline
VanDyke Technical Support
 
Join Date: Nov 2003
Location: Albuquerque, NM
Posts: 915
Again, without knowing why the OpenSSH 6.6.x server is shutting things down, all we can do is grasp for possibilities and take guesses.

The openssh (Cygwin) 7.9 client is using chacha20-poly as the cipher.

Code:
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
Your earlier SecureCRT trace log showed SCRT was negotiating RC4...

What if you configure SecureCRT (8.3 or newer) to do the same as your OpenSSH 7.9 client and use chacha20-poly1305?
If that still doesn't work, you'll want to increase the verbosity of your OpenSSH 6.6.1 logging (/usr/sbin/sshd -e -ddd -D) to see if you can coax the server into revealing why it's shutting down the connection on SecureCRT.

--Jake
Attached Images
File Type: png SessOpts_SSH2_Advanced_EnableOnlyChaCha20-Poly1305.png (30.7 KB, 210 views)
__________________
Jake Devenport
VanDyke Software
Technical Support
YouTube Channel: https://www.youtube.com/vandykesoftware
Email: support@vandyke.com
Web: https://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 -6. The time now is 11:32 AM.