ssh client connection issue to VMS

[pcov...@gmail.com]

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.

the problem

TN3270 doesn't connect and I get a error code 7 cipher is unsupported.
Putty works fine, SSH from my pc works.
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,aes2
56-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,aes2
56-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.

SDI has had no suggestions as to what to do,
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?
and yes I have created a new config file also and generated new keys.

thanks
Paul

[Grant Taylor]

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

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

[pcov...@gmail.com]

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

[Grant Taylor]

On 1/25/22 12:45 PM, pcov...@gmail.com wrote:
> thanks Grant,

You're welcome.

> 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 understand and appreciate the (lack of) scalability problem.

I might suggest that you try it on one or two clients to see if you can
narrow down or hopefully identify if that is in fact the problem.

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

Having some information from a test or two might make the conversation
more productive.

Good luck!

[pcov...@gmail.com]

well I added this into the config file

Host PO10IT002 / IP> 10.128.52.10

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

and what resides in the log file.

debug(25-JAN-2022 15:39:18.65): Remote version: SSH-2.0-TN3270Plus_4.0.7
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:1954: Using Client order for common key exchange algorithms.
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:2073: Constructing the first key exchange packet.
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:3631: local kexinit: kex algs = diffie-hellman-group14-sha1,diffie-hellman-
group1-sha1
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:3658: local kexinit: host key algs = ssh-dss
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:3666: local kexinit: ciphers c to s = aes256-ctr,aes192-ctr,aes128-ctr,aes2
56-cbc
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:3674: local kexinit: ciphers s to c = aes256-ctr,aes192-ctr,aes128-ctr,aes2
56-cbc
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:3680: local kexinit: macs c to s = hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1
-96
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:3686: local kexinit: macs s to c = hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1
-96
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:3692: local kexinit: compressions c to s = none,zlib
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:3698: local kexinit: compressions s to c = none,zlib
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:3708: local kexinit: first_packet_follows = FALSE
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:1261: Outgoing empty, sending empty ignore packet.
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 2 to connection
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:1154: Sending packet with type 20 to connection
debug(25-JAN-2022 15:39:18.65): Ssh2Transport/TRCOMMON.C:2961: Getting a SSH_MSG_KEXINIT packet from connection.
Tue 25 15:39:48 WARNING: LoginGraceTime exceeded.
debug(25-JAN-2022 15:39:48.59): SshServer/SSHSERVER.C:317: Destroying server.

I don't think that TN3270 uses or sees it? at least if I'm reading this right...

[Dave Froble]

On 1/25/2022 2:03 PM, pcov...@gmail.com wrote:
> 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?
> and yes I have created a new config file also and generated new keys.

I think TCPIP V5.7-13ECO5O is the latest version, and there is also a patch
from VSI to add newer cyphers.


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[pcov...@gmail.com]

yes I've added the new ciphers.

I'll look at the new IP patch, thanks

[pcov...@gmail.com]

interesting that it has nothing newer than 2017... I'll have to make a call.

This patch kit supersedes the following previously released VSI kits:

VSI I64VMS TCPIP_NFS_PAT V5.7-ECO5C
VSI I64VMS TCPIP_SSH_PAT V5.7-ECO5D

This patch kit contains a roll up of many ECO corrections that were
previously provided to selected customers in backup saveset format.
Below is a list of the backup saveset fixes released by HPE that are
included in this kit.

Kits from 2017-2014

[Grant Taylor]

On 1/25/22 1:37 PM, pcov...@gmail.com wrote:
> well I added this into the config file
>
> Host PO10IT002 / IP> 10.128.52.10

Hum.

I don't know if it's a message / Usenet / other formatting issue or if
you have the forward slash and / or greater than symbol on the line. I
would expect neither of those characters to be there in a standard SSH
client configuration file.

> I don't think that TN3270 uses or sees it? at least if I'm reading
> this right...

Try having the standard ssh client connect to the name or IP address.
Add the "-v" command line option to see if the config entries are being
applied or not.

I see something like:

debug1: /path/to/client/config/file line ##: Applying options for
$ServerName

If you see that, then you know that the config is being applied.

[Stephen Hoffman]

On 2022-01-25 21:27:50 +0000, pcov...@gmail.com said:

> interesting that it has nothing newer than 2017... I'll have to make a call.
>
> This patch kit supersedes the following previously released VSI kits:
>
> VSI I64VMS TCPIP_NFS_PAT V5.7-ECO5C
> VSI I64VMS TCPIP_SSH_PAT V5.7-ECO5D

ECO5o was current last I checked, and that check was long enough ago
that ECO5o has quite possibly been superseded.

You have to ask VSI for some patches, and this was one.

ECO5o added less-old ssh support, and fixed ssh connection issues I'd
encountered.

The wholesale-replacement OpenSSH kit was also in test, and that should
greatly improve compatibility with current ssh implementations.



--
Pure Personal Opinion | HoffmanLabs LLC

[Craig A. Berry]

On 1/25/22 4:26 PM, Stephen Hoffman wrote:

> The wholesale-replacement OpenSSH kit was also in test, and that should
> greatly improve compatibility with current ssh implementations.

According to the roadmap, this was to be in beta for Alpha and Itanium
in Q4 of last year, but I can't find any relevant kits on the service
platform portal and don't remember any announcements. There is a kit
available for X86VMS, and the OP could consider spinning up one of those
and checking whether it solves the problem. That could be a nice
factoid to have in hand when chatting with VSI support and/or sales.

[Robert A. Brooks]

On 1/25/2022 6:44 PM, Craig A. Berry wrote:
>
> On 1/25/22 4:26 PM, Stephen Hoffman wrote:
>
>> The wholesale-replacement OpenSSH kit was also in test, and that should
>> greatly improve compatibility with current ssh implementations.
>
> According to the roadmap, this was to be in beta for Alpha and Itanium
> in Q4 of last year, but I can't find any relevant kits on the service
> platform portal and don't remember any announcements.

From what I understand, the OpenSSH kit will be ready for testing
"soon".

--
-- Rob

[Chris Townley]

You could always look at Process Software - their TCPWare package has up
to date ciphers. They also have an SSH package

--
Chris

[kemain...@gmail.com]

As Chris correctly stated, Process Software does have a very current SSH kit
that can also be used with the standard TCPIP Services stack.

<https://www.process.com/products/ssh/>

< https://www.process.com/products/ssh/ssh_datasheet.pdf>


Regards,

Kerry Main
Kerry dot main at starkgaming dot com







--
This email has been checked for viruses by AVG.
https://www.avg.com

[pcov...@gmail.com]

yes I've downloaded the latest kits, though there is some discrepancies between the document and what is in the zip file for SSH,

as far as the Process Software stack, unfortunately Intersystems has some notes only to use the HPE/VSI stack...

[Stephen Hoffman]

On 2022-01-26 18:01:08 +0000, pcov...@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.

[pcov...@gmail.com]

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

[Richard Whalen]

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.

[Stephen Hoffman]

On 2022-01-28 15:47:24 +0000, pcov...@gmail.com said:

> 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

Check whether the ssh server process has crashed.

[pcov...@gmail.com]

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!

[pcov...@gmail.com]

yes it is