[Info-vax] ssh client connection issue to VMS

[pcoviello at gmail.com]

On Thursday, February 3, 2022 at 9:40:32 AM UTC-5, rvwh... at gmail.com wrote:
> On Friday, January 28, 2022 at 10:47:25 AM UTC-5, pcov... at gmail.com wrote: 
> > On Wednesday, January 26, 2022 at 6:47:52 PM UTC-5, Stephen Hoffman wrote: 
> > > On 2022-01-26 18:01:08 +0000, pcov... at gmail.com said: 
> > > 
> > > > ...yes I've downloaded the latest kits, though there is some 
> > > > discrepancies between the document and what is in the zip file for SSH, 
> > > Noticed that, eh? Whoever packaged that clearly didn't. 
> > > -- 
> > > Pure Personal Opinion | HoffmanLabs LLC 
> > yup pretty much, though then I was told to ignore the doc. sigh! 
> > even updating the ciphers and creating a new public key I'm still getting unsupported cipher, and I'm at a loss as to why. Putty works fine. 
> > 
> > it appears to agree on the info or at least the way I'm seeing it. I guess I'll try to load all of the ciphers and macs back in and see what happens. 
> > 
> > debug(27-JAN-2022 13:44:57.89): Remote version: SSH-2.0-TN3270Plus_4.0.7 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:1954: Using Client order for common key exchange algorithms. 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:2073: Constructing the first key exchange packet. 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:3631: local kexinit: kex algs = diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:3658: local kexinit: host key algs = ssh-rsa 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:3666: local kexinit: ciphers c to s = aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:3674: local kexinit: ciphers s to c = aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:3680: local kexinit: macs c to s = hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:3686: local kexinit: macs s to c = hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:3692: local kexinit: compressions c to s = none,zlib 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:3698: local kexinit: compressions s to c = none,zlib 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:3708: local kexinit: first_packet_follows = FALSE 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:1261: Outgoing empty, sending empty ignore packet. 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 2 to connection 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:895: Keying padding pool generator. 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 20 to connection 
> > debug(27-JAN-2022 13:44:57.89): SshUnixFdStream/SSHUNIXFDSTREAM.C:1035: Calling write() to write 368 bytes to FD 1 
> > debug(27-JAN-2022 13:44:57.89): SshUnixFdStream/SSHUNIXFDSTREAM.C:1104: ssh_stream_fd_write wrote 368 bytes 
> > debug(27-JAN-2022 13:44:57.89): Ssh2Transport/TRCOMMON.C:2961: Getting a SSH_MSG_KEXINIT packet from connection. 
> > debug(27-JAN-2022 13:44:57.89): SshUnixFdStream/SSHUNIXFDSTREAM.C:887: read -1 bytes from FD 0 
> > debug(27-JAN-2022 13:44:57.89): SshUnixFdStream/SSHUNIXFDSTREAM.C:900: ssh_stream_fd_read read returned errno=35,vaxc$errno=%SYSTEM-F-SUSPENDED, process is suspended 
> > debug(27-JAN-2022 13:45:01.24): Ssh2Transport/TRCOMMON.C:2961: Getting a SSH_MSG_KEXINIT packet from connection. 
> > debug(27-JAN-2022 13:45:01.24): SshUnixFdStream/SSHUNIXFDSTREAM.C:887: read 8 bytes from FD 0 
> > debug(27-JAN-2022 13:45:01.24): SshUnixFdStream/SSHUNIXFDSTREAM.C:887: read 32 bytes from FD 0 
> > debug(27-JAN-2022 13:45:01.24): Ssh2Transport/TRCOMMON.C:2854: >TR packet_type=1 
> > debug(27-JAN-2022 13:45:01.24): Ssh2Transport/TRCOMMON.C:2558: Processing received SSH_MSG_DISCONNECT 
> > debug(27-JAN-2022 13:45:01.24): Ssh2Transport/TRCOMMON.C:1300: Disconnecting: reason code: 11 message: 'Unsupported cipher' 
> > debug(27-JAN-2022 13:45:01.24): Ssh2AuthServer/SSHAUTHS.C:1257: received_packet: DISCONNECT from transport code. 
> > debug(27-JAN-2022 13:45:01.24): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: Unsupported cipher 
> > Thu 27 13:45:01 INFORMATIONAL: Remote host disconnected: Unsupported cipher
> This is a guess, but is it possible that the key that is being exchanged is encrypted with a cipher that the server doesn't support (for key encryption)? 
> I'm not sure how the key encoding would be controlled if it is a dynamically created key (which is typical). If the client is using its host key, then the encryption on that could be causing a problem.

I actually created a new hostkey using RSA 2048 and changed the ciphers and macs and it got connected the problem now though which started this whole issue is the ciphers and macs wont pass a Qualys scan. and it thinks I have a 1024 hostkey.... sigh!