[Info-vax] ssh client connection issue to VMS

[pcoviello at gmail.com]

On Tuesday, January 25, 2022 at 2:29:08 PM UTC-5, Grant Taylor wrote:
> On 1/25/22 12:03 PM, pcov... at gmail.com wrote: 
> > we are trying to get TN3270 to work with a small subset of ciphers 
> > and macs since we didn't do well in an audit.
> I'm surprised that you're using TN3270 to connect to an OpenVMS system. 
> I think of EBCDIC when I think of TN3270. I think of ASCII when I think 
> of OpenVMS. I guess I'm wrong.
> > the problem 
> > 
> > TN3270 doesn't connect and I get a error code 7 cipher is unsupported.
> I wasn't even aware that tn3270 supported SSH. 
> 
> I'm wondering if we're talking about the same tn3270.
> > Putty works fine, SSH from my pc works.
> This hints at cipher mismatches between old server and new client (or 
> vice versa). 
> 
> See if the following page gives any clues. 
> 
> Link - OpenSSH Legacy Options 
> - https://www.openssh.com/legacy.html 
> 
> I've used information from that page to have contemporary SSH clients 
> connect to ancient SSH servers.
> > here is the VMS output in the log file pointing to the connection 
> > 
> > debug(25-JAN-2022 13:31:02.07): Remote version: 
> > SSH-2.0-TN3270Plus_4.0.7 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:1954: Using 
> > Client order for common key exchange algorithms. 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:2073: 
> > Constructing the first key exchange packet. 
> > debug(25-JAN-2022 13:31:02.07): 
> > Ssh2Transport/TRCOMMON.C:3631: local kexinit: kex algs = 
> > diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:3658: local 
> > kexinit: host key algs = ssh-dss 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:3666: local 
> > kexinit: ciphers c to s = aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:3674: local 
> > kexinit: ciphers s to c = aes256-ctr,aes192-ctr,aes128-ctr,aes256-cbc 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:3680: local 
> > kexinit: macs c to s = hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:3686: local 
> > kexinit: macs s to c = hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:3692: local 
> > kexinit: compressions c to s = none,zlib 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:3698: local 
> > kexinit: compressions s to c = none,zlib 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:3708: local 
> > kexinit: first_packet_follows = FALSE 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:1261: 
> > Outgoing empty, sending empty ignore packet. 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:1154: 
> > Sending packet with type 2 to connection 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:1154: 
> > Sending packet with type 20 to connection 
> > debug(25-JAN-2022 13:31:02.07): Ssh2Transport/TRCOMMON.C:2961: 
> > Getting a SSH_MSG_KEXINIT packet from connection. 
> > debug(25-JAN-2022 13:31:04.70): Ssh2Transport/TRCOMMON.C:2961: 
> > Getting a SSH_MSG_KEXINIT packet from connection. 
> > debug(25-JAN-2022 13:31:04.70): Ssh2Transport/TRCOMMON.C:2854: 
> > >TR packet_type=1 
> > debug(25-JAN-2022 13:31:04.71): Ssh2Transport/TRCOMMON.C:2558: 
> > Processing received SSH_MSG_DISCONNECT 
> > debug(25-JAN-2022 13:31:04.71): Ssh2Transport/TRCOMMON.C:1300: 
> > Disconnecting: reason code: 11 message: 'Unsupported cipher' 
> > debug(25-JAN-2022 13:31:04.71): Ssh2Common/SSHCOMMON.C:180: DISCONNECT 
> > received: Unsupported cipher 
> > Tue 25 13:31:04 INFORMATIONAL: Remote host disconnected: Unsupported 
> > cipher 
> > debug(25-JAN-2022 13:31:04.71): Sshd2/SSHD2.C:760: locally_generated 
> > = FALSE 
> > Tue 25 13:31:04 INFORMATIONAL: disconnected by application in remote: 
> > 'Unsupported cipher' 
> > debug(25-JAN-2022 13:31:04.71): SshServer/SSHSERVER.C:317: Destroying 
> > server. 
> > debug(25-JAN-2022 13:31:04.71): SshConfig/SSHCONFIG.C:2949: Freeing 
> > pki. (host_pki != NULL, user_pki != NULL) 
> > debug(25-JAN-2022 13:31:04.71): SshCertCMi/CMI.C:454: Free certificate 
> > manager.
> This /seems/ like there is no overlap between the ciphers and / or key 
> exchange methods that between the client and server.
> > SDI has had no suggestions as to what to do,
> /If/ TN3270 is using OpenSSH under the hood, you can probably put 
> configuration entries in the client's OpenSSH config file to allow the 
> OpenSSH client to connect, thus possibly allowing TN3270 to connect. -- 
> This is predicated on TN3270 actually using OpenSSH this way. I have 
> no idea what it's doing. 
> 
> I've had to had various combinations of the following to my 
> ~/.ssh/config file to have my contemporary OpenSSH client connect to 
> some ancient SSH servers. 
> 
> Host <hostname / IP> <alias> 
> Ciphers +aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc 
> HostKeyAlgorithms +ssh-dss 
> KexAlgorithms 
> +diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> > I've also the ciphers to the latest that VSI has put out or at least 
> > at the time. 
> > I'm running 8.4-1H1 VSI I64VMS TCPIP V5.7-13ECO5F 
> > 
> > anyone have any other thoughts?
> I have no idea if the problem that you're running into is related to the 
> problem that I ran into or not. But they do seem to be related to me. 
> 
> Hopefully my reply gets you further down the road.
> > and yes I have created a new config file also and generated new keys.
> If it's the issue that I'm suspecting it is, I don't think the keys will 
> make much difference. 
> 
> 
> 
> -- 
> Grant. . . . 
> unix || die


thanks Grant, I'm not able to add the individual clients to the config, we have about 500 users connecting to our server.  it would be a logistical nightmare!!!

I'll check with SDI on their use and see if there is a way to add it.
thanks