[Info-vax] ssh client connection issue to VMS

[Grant Taylor]

On 1/25/22 12:03 PM, pcoviello 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