Trying to connect to another machine using ssh but failing with error of:

debug(24-MAY-2023 12:20:30.82): Remote version: SSH-2.0-OpenSSH_8.0
debug(24-MAY-2023 12:20:30.84): OpenSSH: Major: 8 Minor: 0 Revision: 0
debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1825: All versions of OpenSSH handle kex guesses incorrectly.
debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 20 to connection
debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2756: >TR packet_type=20
debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2318: lang s to c: `', lang c to s: `'
debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2334: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
_key = ssh-rsa)
debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
debug(24-MAY-2023 12:20:30.85): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 1 to connection
debug(24-MAY-2023 12:20:30.85): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: Algorithm negotiation failed.
debug(24-MAY-2023 12:20:30.85): SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
warning: Authentication failed.
debug(24-MAY-2023 12:20:30.85): Ssh2/SSH2.C:327: locally_generated = TRUE
Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).

ssh username@hostname -v

what are the correct format for options in OpenVMS for the image tcpip$ssh_ssh-keygen2.exe??

the equivalent of unix command:
ssh -o "KexAlgorithms diffie-hellman-group1-sha1" -o "HostKeyAlgorithms ssh-dss" -o "Ciphers aes256-cbc" -i chaveprivada username@hostname

also tried to change in the unix server to change sshd_config and added:
ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com,aes256-cbc
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1

as well hostkeyalgorithms ssh-dss

but still fails with the error:
All versions of OpenSSH handle kex guesses incorrectly
Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
_key = ssh-rsa

here its confusing for me since if its been added "KexAlgorithms diffie-hellman-group1-sha1" in sshd_config of the unix system so OpenVMS should have stoped complaining about the KexAlgorithm...

this attemp of changing sshd_config isn't a good option for security reasons but was to test if at least would fix in short term solution...

Thanks

On 5/24/2023 10:39 AM, HCorte wrote:
> Trying to connect to another machine using ssh but failing with error of:
>
> debug(24-MAY-2023 12:20:30.82): Remote version: SSH-2.0-OpenSSH_8.0
> debug(24-MAY-2023 12:20:30.84): OpenSSH: Major: 8 Minor: 0 Revision: 0
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1825: All versions of OpenSSH handle kex guesses incorrectly.
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 20 to connection
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2756: >TR packet_type=20
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2318: lang s to c: `', lang c to s: `'
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2334: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
> _key = ssh-rsa)
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
> debug(24-MAY-2023 12:20:30.85): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 1 to connection
> debug(24-MAY-2023 12:20:30.85): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: Algorithm negotiation failed.
> debug(24-MAY-2023 12:20:30.85): SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
> warning: Authentication failed.
> debug(24-MAY-2023 12:20:30.85): Ssh2/SSH2.C:327: locally_generated = TRUE
> Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).
>
>
> ssh username@hostname -v
>
> what are the correct format for options in OpenVMS for the image tcpip$ssh_ssh-keygen2.exe??
>
> the equivalent of unix command:
> ssh -o "KexAlgorithms diffie-hellman-group1-sha1" -o "HostKeyAlgorithms ssh-dss" -o "Ciphers aes256-cbc" -i chaveprivada username@hostname
>
> also tried to change in the unix server to change sshd_config and added:
> ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com,aes256-cbc
> KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1
>
> as well hostkeyalgorithms ssh-dss
>
> but still fails with the error:
> All versions of OpenSSH handle kex guesses incorrectly
> Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
> _key = ssh-rsa
>
> here its confusing for me since if its been added "KexAlgorithms diffie-hellman-group1-sha1" in sshd_config of the unix system so OpenVMS should have stoped complaining about the KexAlgorithm...
>
> this attemp of changing sshd_config isn't a good option for security reasons but was to test if at least would fix in short term solution...
>
> Thanks
>

You might want to try enabling ssh-rsa for the HostkeyAlgorithms.

Recently went thru something similar trying to get a OpenVMS HPE 8.4 (with TCPIP v5.7-13ECO5)
talking to a TrueNAS server via ssh. Wanted to use sftp to push files over to the NAS storage device.

Normally I just have to downgrade the server to allow diffie-hellman-group1-sha1 & ssh-dss, but
until I also allowed ssh-rsa it just would not work. It appears that the TrueNAS side "accepts" the
ssh-dss argument it just totally ignores it. The TrueNAS side still supports ssh-rsa and that is
also supported on the VMS side.

I ended up with the following on my TrueNAS side

HostKeyAlgorithms=+ssh-dss,ssh-rsa
KexAlgorithms=+diffie-hellman-group1-sha1

Now I can't say if its secure or not, but then, its probably better than FTP which is the
alternative to push a file (backup save set) over to the TrueNAS for storage.

Rod

On Wednesday, May 24, 2023 at 10:39:08 AM UTC-4, HCorte wrote:
> Trying to connect to another machine using ssh but failing with error of:
>
> debug(24-MAY-2023 12:20:30.82): Remote version: SSH-2.0-OpenSSH_8.0
> debug(24-MAY-2023 12:20:30.84): OpenSSH: Major: 8 Minor: 0 Revision: 0
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1825: All versions of OpenSSH handle kex guesses incorrectly.
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 20 to connection
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2756: >TR packet_type=20
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2318: lang s to c: `', lang c to s: `'
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2334: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
> _key = ssh-rsa)
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
> debug(24-MAY-2023 12:20:30.85): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 1 to connection
> debug(24-MAY-2023 12:20:30.85): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: Algorithm negotiation failed.
> debug(24-MAY-2023 12:20:30.85): SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
> warning: Authentication failed.
> debug(24-MAY-2023 12:20:30.85): Ssh2/SSH2.C:327: locally_generated = TRUE
> Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).
>
>
> ssh username@hostname -v
>
> what are the correct format for options in OpenVMS for the image tcpip$ssh_ssh-keygen2.exe??
>
> the equivalent of unix command:
> ssh -o "KexAlgorithms diffie-hellman-group1-sha1" -o "HostKeyAlgorithms ssh-dss" -o "Ciphers aes256-cbc" -i chaveprivada username@hostname
>
> also tried to change in the unix server to change sshd_config and added:
> ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20...@openssh.com,aes256-cbc
> KexAlgorithms curve255...@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1
>
> as well hostkeyalgorithms ssh-dss
>
> but still fails with the error:
> All versions of OpenSSH handle kex guesses incorrectly
> Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
> _key = ssh-rsa
>
> here its confusing for me since if its been added "KexAlgorithms diffie-hellman-group1-sha1" in sshd_config of the unix system so OpenVMS should have stoped complaining about the KexAlgorithm...
>
> this attemp of changing sshd_config isn't a good option for security reasons but was to test if at least would fix in short term solution...
>
> Thanks

You might try doubling that v argument ( -vv ) or maybe even tripling
it on the SSH command line to get a more verbose output and insure
that the client and server can be in agreement on the cipher and MAC
that will be used during the key exchange.

On Wednesday, May 24, 2023 at 10:39:08 AM UTC-4, HCorte wrote:
> Trying to connect to another machine using ssh but failing with error of:
>
> debug(24-MAY-2023 12:20:30.82): Remote version: SSH-2.0-OpenSSH_8.0
> debug(24-MAY-2023 12:20:30.84): OpenSSH: Major: 8 Minor: 0 Revision: 0
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1825: All versions of OpenSSH handle kex guesses incorrectly.
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 20 to connection
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2756: >TR packet_type=20
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2318: lang s to c: `', lang c to s: `'
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2334: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
> _key = ssh-rsa)
> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
> debug(24-MAY-2023 12:20:30.85): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 1 to connection
> debug(24-MAY-2023 12:20:30.85): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: Algorithm negotiation failed.
> debug(24-MAY-2023 12:20:30.85): SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
> warning: Authentication failed.
> debug(24-MAY-2023 12:20:30.85): Ssh2/SSH2.C:327: locally_generated = TRUE
> Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).
>
>
> ssh username@hostname -v
>
> what are the correct format for options in OpenVMS for the image tcpip$ssh_ssh-keygen2.exe??
>
> the equivalent of unix command:
> ssh -o "KexAlgorithms diffie-hellman-group1-sha1" -o "HostKeyAlgorithms ssh-dss" -o "Ciphers aes256-cbc" -i chaveprivada username@hostname
>
> also tried to change in the unix server to change sshd_config and added:
> ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20...@openssh.com,aes256-cbc
> KexAlgorithms curve255...@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1
>
> as well hostkeyalgorithms ssh-dss
>
> but still fails with the error:
> All versions of OpenSSH handle kex guesses incorrectly
> Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
> _key = ssh-rsa
>
> here its confusing for me since if its been added "KexAlgorithms diffie-hellman-group1-sha1" in sshd_config of the unix system so OpenVMS should have stoped complaining about the KexAlgorithm...
>
> this attemp of changing sshd_config isn't a good option for security reasons but was to test if at least would fix in short term solution...
>
> Thanks
HCorte,

Been there; dealt with that.

First off, what is the version of OpenVMS and TCPIP?

The problem is most likely not SSH keygen. The "incompatibility" is that many linux and other platforms have had key exchange and cipher updates in the interim, and TCPIP services has been a tad lagging.

Enabling more detailed tracing will reveal which methods are acceptable to each system. If connecting from a more current host to an OpenVMS system, one can either specify older, and often deprecated, methods, either on the command line or in the hosts file. If connecting from the OpenVMS system, one probably has to modify the settings on the target system to accept the older methods.

- Bob Gezelter, http://www.rlgsc.com

A quarta-feira, 24 de maio de 2023 à(s) 21:43:58 UTC+1, Bob Gezelter escreveu:
> On Wednesday, May 24, 2023 at 10:39:08 AM UTC-4, HCorte wrote:
> > Trying to connect to another machine using ssh but failing with error of:
> >
> > debug(24-MAY-2023 12:20:30.82): Remote version: SSH-2.0-OpenSSH_8.0
> > debug(24-MAY-2023 12:20:30.84): OpenSSH: Major: 8 Minor: 0 Revision: 0
> > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1825: All versions of OpenSSH handle kex guesses incorrectly.
> > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
> > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 20 to connection
> > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2756: >TR packet_type=20
> > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2318: lang s to c: `', lang c to s: `'
> > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2334: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
> > _key = ssh-rsa)
> > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
> > debug(24-MAY-2023 12:20:30.85): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 1 to connection
> > debug(24-MAY-2023 12:20:30.85): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: Algorithm negotiation failed.
> > debug(24-MAY-2023 12:20:30.85): SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
> > warning: Authentication failed.
> > debug(24-MAY-2023 12:20:30.85): Ssh2/SSH2.C:327: locally_generated = TRUE
> > Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).
> >
> >
> > ssh username@hostname -v
> >
> > what are the correct format for options in OpenVMS for the image tcpip$ssh_ssh-keygen2.exe??
> >
> > the equivalent of unix command:
> > ssh -o "KexAlgorithms diffie-hellman-group1-sha1" -o "HostKeyAlgorithms ssh-dss" -o "Ciphers aes256-cbc" -i chaveprivada username@hostname
> >
> > also tried to change in the unix server to change sshd_config and added:
> > ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20...@openssh.com,aes256-cbc
> > KexAlgorithms curve255...@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> > macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1
> >
> > as well hostkeyalgorithms ssh-dss
> >
> > but still fails with the error:
> > All versions of OpenSSH handle kex guesses incorrectly
> > Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
> > _key = ssh-rsa
> >
> > here its confusing for me since if its been added "KexAlgorithms diffie-hellman-group1-sha1" in sshd_config of the unix system so OpenVMS should have stoped complaining about the KexAlgorithm...
> >
> > this attemp of changing sshd_config isn't a good option for security reasons but was to test if at least would fix in short term solution...
> >
> > Thanks
> HCorte,
>
> Been there; dealt with that.
>
> First off, what is the version of OpenVMS and TCPIP?
>
> The problem is most likely not SSH keygen. The "incompatibility" is that many linux and other platforms have had key exchange and cipher updates in the interim, and TCPIP services has been a tad lagging.
>
> Enabling more detailed tracing will reveal which methods are acceptable to each system. If connecting from a more current host to an OpenVMS system, one can either specify older, and often deprecated, methods, either on the command line or in the hosts file. If connecting from the OpenVMS system, one probably has to modify the settings on the target system to accept the older methods.
>
> - Bob Gezelter, http://www.rlgsc.com

@Bob its a very old version of VMS (from what I was told in this forum in another post)
$ SHOW SYSTEM
OpenVMS V8.4

$ tcpip SHOW VERSION
HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 2
on an HP rx3600 (1.67GHz/9.0MB) running OpenVMS V8.4

@Jim had already tried but the gives the same information and in the help (ssh -h)
SSH Secure Shell OpenVMS (V5.5) 3.2.0 on HP rx3600 (1.67GHz/9.0MB) - VMS V8.4

Options:

-l login_name Log in using this user name.

+x Enable X11 connection forwarding (treat X11 clients as
UNTRUSTED).

+X Enable X11 connection forwarding (treat X11 clients as
TRUSTED).

-x Disable X11 connection forwarding.

-i file Identity file for public key authentication

-F file Read an alternative configuration file.

-t Tty; allocate a tty even if command is given.

-v Verbose; display verbose debugging messages. Equal to '-d 2'

-d level Set debug level.

-V Display version string.

-q Quiet; don't display any warning messages.

-p port Connect to this port. Server must be on the same port.

-S Don't request a session channel.

-L listen-port:host:port Forward local port to remote address

-R listen-port:host:port Forward remote port to local address

These cause ssh to listen for connections on a port, and
forward them to the other side by connecting to host:port.

-4 Use IPv4 to connect.

-6 Use IPv6 to connect.

-o 'option' Process the option as if it was read from a configuration
file.

-h Display this help.

Command can be either:

remote_command [arguments] ... Run command in remote host.

-s service Enable a service in remote server.

Supported ciphers:

3des-cbc,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,twofish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,des-cbc@ssh.com,ca
st128-cbc,rc2-cbc@ssh.com,arcfour,none

Supported MAC algorithms:

hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96,hmac-sha256@ssh.com,hmac-sha256-96@ssh.com,hmac-ripemd160@ssh.com,hmac-ripemd160-96@ss
h.com,hmac-tiger128@ssh.com,hmac-tiger128-96@ssh.com,hmac-tiger160@ssh.com,hmac-tiger160-96@ssh.com,hmac-tiger192@ssh.com,hmac-tiger
192-96@ssh.com,none

How do I get a list of the Kex supported (Key Enchange Algorithm)??

On 5/25/23 5:08 AM, HCorte wrote:
> A quarta-feira, 24 de maio de 2023 à(s) 21:43:58 UTC+1, Bob Gezelter escreveu:
>> On Wednesday, May 24, 2023 at 10:39:08 AM UTC-4, HCorte wrote:
>>> Trying to connect to another machine using ssh but failing with error of:
>>>
>>> debug(24-MAY-2023 12:20:30.82): Remote version: SSH-2.0-OpenSSH_8.0
>>> debug(24-MAY-2023 12:20:30.84): OpenSSH: Major: 8 Minor: 0 Revision: 0
>>> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1825: All versions of OpenSSH handle kex guesses incorrectly.
>>> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
>>> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 20 to connection
>>> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2756: >TR packet_type=20
>>> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2318: lang s to c: `', lang c to s: `'
>>> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2334: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
>>> _key = ssh-rsa)
>>> debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
>>> debug(24-MAY-2023 12:20:30.85): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 1 to connection
>>> debug(24-MAY-2023 12:20:30.85): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: Algorithm negotiation failed.
>>> debug(24-MAY-2023 12:20:30.85): SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
>>> warning: Authentication failed.
>>> debug(24-MAY-2023 12:20:30.85): Ssh2/SSH2.C:327: locally_generated = TRUE
>>> Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).
>>>
>>>
>>> ssh username@hostname -v
>>>
>>> what are the correct format for options in OpenVMS for the image tcpip$ssh_ssh-keygen2.exe??
>>>
>>> the equivalent of unix command:
>>> ssh -o "KexAlgorithms diffie-hellman-group1-sha1" -o "HostKeyAlgorithms ssh-dss" -o "Ciphers aes256-cbc" -i chaveprivada username@hostname
>>>
>>> also tried to change in the unix server to change sshd_config and added:
>>> ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20...@openssh.com,aes256-cbc
>>> KexAlgorithms curve255...@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>>> macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1
>>>
>>> as well hostkeyalgorithms ssh-dss
>>>
>>> but still fails with the error:
>>> All versions of OpenSSH handle kex guesses incorrectly
>>> Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
>>> _key = ssh-rsa
>>>
>>> here its confusing for me since if its been added "KexAlgorithms diffie-hellman-group1-sha1" in sshd_config of the unix system so OpenVMS should have stoped complaining about the KexAlgorithm...
>>>
>>> this attemp of changing sshd_config isn't a good option for security reasons but was to test if at least would fix in short term solution...
>>>
>>> Thanks
>> HCorte,
>>
>> Been there; dealt with that.
>>
>> First off, what is the version of OpenVMS and TCPIP?
>>
>> The problem is most likely not SSH keygen. The "incompatibility" is that many linux and other platforms have had key exchange and cipher updates in the interim, and TCPIP services has been a tad lagging.
>>
>> Enabling more detailed tracing will reveal which methods are acceptable to each system. If connecting from a more current host to an OpenVMS system, one can either specify older, and often deprecated, methods, either on the command line or in the hosts file. If connecting from the OpenVMS system, one probably has to modify the settings on the target system to accept the older methods.
>>
>> - Bob Gezelter, http://www.rlgsc.com
>
> @Bob its a very old version of VMS (from what I was told in this forum in another post)
> $ SHOW SYSTEM
> OpenVMS V8.4
>
> $ tcpip SHOW VERSION
> HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 2
> on an HP rx3600 (1.67GHz/9.0MB) running OpenVMS V8.4
>
> @Jim had already tried but the gives the same information and in the help (ssh -h)
> SSH Secure Shell OpenVMS (V5.5) 3.2.0 on HP rx3600 (1.67GHz/9.0MB) - VMS V8.4
>
> Options:
>
> -l login_name Log in using this user name.
>
> +x Enable X11 connection forwarding (treat X11 clients as
> UNTRUSTED).
>
> +X Enable X11 connection forwarding (treat X11 clients as
> TRUSTED).
>
> -x Disable X11 connection forwarding.
>
> -i file Identity file for public key authentication
>
> -F file Read an alternative configuration file.
>
> -t Tty; allocate a tty even if command is given.
>
> -v Verbose; display verbose debugging messages. Equal to '-d 2'
>
> -d level Set debug level.
>
> -V Display version string.
>
> -q Quiet; don't display any warning messages.
>
> -p port Connect to this port. Server must be on the same port.
>
> -S Don't request a session channel.
>
> -L listen-port:host:port Forward local port to remote address
>
> -R listen-port:host:port Forward remote port to local address
>
> These cause ssh to listen for connections on a port, and
> forward them to the other side by connecting to host:port.
>
> -4 Use IPv4 to connect.
>
> -6 Use IPv6 to connect.
>
> -o 'option' Process the option as if it was read from a configuration
> file.
>
> -h Display this help.
>
>
>
> Command can be either:
>
> remote_command [arguments] ... Run command in remote host.
>
> -s service Enable a service in remote server.
>
>
>
> Supported ciphers:
>
> 3des-cbc,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,twofish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,des-cbc@ssh.com,ca
> st128-cbc,rc2-cbc@ssh.com,arcfour,none
>
> Supported MAC algorithms:
>
> hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96,hmac-sha256@ssh.com,hmac-sha256-96@ssh.com,hmac-ripemd160@ssh.com,hmac-ripemd160-96@ss
> h.com,hmac-tiger128@ssh.com,hmac-tiger128-96@ssh.com,hmac-tiger160@ssh.com,hmac-tiger160-96@ssh.com,hmac-tiger192@ssh.com,hmac-tiger
> 192-96@ssh.com,none
>
> How do I get a list of the Kex supported (Key Enchange Algorithm)??

Dunno about kex, but you can look at what's in the config at
SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG for ciphers and MAC
algorithms. Sometimes it is possible to reorder or modify the limited
options available to avoid obsolete algorithms.

On Thursday, May 25, 2023 at 7:38:59 AM UTC-4, Craig A. Berry wrote:
> On 5/25/23 5:08 AM, HCorte wrote:
> >
> > How do I get a list of the Kex supported (Key Enchange Algorithm)??
> Dunno about kex, but you can look at what's in the config at
> SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG for ciphers and MAC
> algorithms. Sometimes it is possible to reorder or modify the limited
> options available to avoid obsolete algorithms.

If this version of TCP supports it, the method for affecting which KEXs are
to be supported if the defaults are not desired would be with a KEXs
directive in the SSHD2_CONFIG. file. Something like this:

KEXs ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256

I suspect that the only way to see which KEXs are currently being offered
by client and server would be to use TCPDUMP or equivalent. The KEX
algorithm list (along with cipher and MAC) are exchange in plain text
early on in the SSH handshake. The KEX are first in each end's option
bundle. The algorithm list is comma separated. KEXs end and ciphers
begin where you see a small break in the comma separated list. There
will be a null byte or two... you'll find an algorithm list being offered from
both the client and the server prior to their agreement.

A quinta-feira, 25 de maio de 2023 à(s) 13:09:51 UTC+1, Jim escreveu:
> On Thursday, May 25, 2023 at 7:38:59 AM UTC-4, Craig A. Berry wrote:
> > On 5/25/23 5:08 AM, HCorte wrote:
> > >
> > > How do I get a list of the Kex supported (Key Enchange Algorithm)??
> > Dunno about kex, but you can look at what's in the config at
> > SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG for ciphers and MAC
> > algorithms. Sometimes it is possible to reorder or modify the limited
> > options available to avoid obsolete algorithms.
> If this version of TCP supports it, the method for affecting which KEXs are
> to be supported if the defaults are not desired would be with a KEXs
> directive in the SSHD2_CONFIG. file. Something like this:
>
> KEXs ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521
> ,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256
>
> I suspect that the only way to see which KEXs are currently being offered
> by client and server would be to use TCPDUMP or equivalent. The KEX
> algorithm list (along with cipher and MAC) are exchange in plain text
> early on in the SSH handshake. The KEX are first in each end's option
> bundle. The algorithm list is comma separated. KEXs end and ciphers
> begin where you see a small break in the comma separated list. There
> will be a null byte or two... you'll find an algorithm list being offered from
> both the client and the server prior to their agreement.

@Jim, was able to get more debug verbosity level

ssh username@hostname -d 4

debug(25-MAY-2023 12:25:28.40): Ssh2Transport/TRCOMMON.C:2165: client: kex = diffie-hellman-group1-sha1, hk_alg
= ssh-dss,ssh-rsa,x509v3-sign-dss,x509v3-sign-rsa

debug(25-MAY-2023 12:25:28.40): Ssh2Transport/TRCOMMON.C:2167: server: kex = curve25519-sha256,curve25519-sha25
6@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diff
ie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exch
ange-sha1,diffie-hellman-group14-sha1, hk_alg = rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed255
19

have to talk to a collegue to insert again diffie-hellman-group1-sha1 into sshd_config in unix system to check what message returns now with this level of verbosity, to see if this kex will also start to appear in the server kex as well.

@Craig

type SSHD2_CONFIG.;3
....
## Crypto

Ciphers AnyCipher
....
MACs AnyMAC
....

But with the command "ssh -h"

add already given me those list:

Supported ciphers:

3des-cbc,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,twofish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,des...@ssh.com,ca
st128-cbc,rc2...@ssh.com,arcfour,none

Supported MAC algorithms:

hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96,hmac-...@ssh.com,hmac-sh...@ssh..com,hmac-ri...@ssh.com,hmac-ripemd160-96@ss
h.com,hmac-t...@ssh.com,hmac-tig...@ssh.com,hmac-t...@ssh.com,hmac-tig...@ssh.com,hmac-t...@ssh.com,hmac-tiger
192...@ssh.com,none

but add already tried with a collegue to added some of this to the unix sshd_config file with no sucess in fixing, but more verbosity in the debbug will try to see if something changes.

> Dunno about kex, but you can look at what's in the config at
> SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG for ciphers and MAC
> algorithms.

Note that in unix SSHs, sshd_config is for the server, and ssh_config
is for the client. Not sure about the VMS stuff.

De

On 5/25/23 9:11 AM, Dennis Boone wrote:
> > Dunno about kex, but you can look at what's in the config at
> > SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG for ciphers and MAC
> > algorithms.
>
> Note that in unix SSHs, sshd_config is for the server, and ssh_config
> is for the client. Not sure about the VMS stuff.

Good point. I don't know whether the VMS client uses a config file or not.

On 25/05/2023 15:33, Craig A. Berry wrote:
>
> On 5/25/23 9:11 AM, Dennis Boone wrote:
>>   > Dunno about kex, but you can look at what's in the config at
>>   > SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG for ciphers and MAC
>>   > algorithms.
>>
>> Note that in unix SSHs, sshd_config is for the server, and ssh_config
>> is for the client.  Not sure about the VMS stuff.
>
> Good point.  I don't know whether the VMS client uses a config file or not.
>

VMS client uses SSH$ROOT:[ETC]SSH_CONFIG.

--
Chris

A quinta-feira, 25 de maio de 2023 à(s) 15:40:54 UTC+1, Chris Townley escreveu:
> On 25/05/2023 15:33, Craig A. Berry wrote:
> >
> > On 5/25/23 9:11 AM, Dennis Boone wrote:
> >> > Dunno about kex, but you can look at what's in the config at
> >> > SYS$SYSDEVICE:[TCPIP$SSH.SSH2]SSHD2_CONFIG for ciphers and MAC
> >> > algorithms.
> >>
> >> Note that in unix SSHs, sshd_config is for the server, and ssh_config
> >> is for the client. Not sure about the VMS stuff.
> >
> > Good point. I don't know whether the VMS client uses a config file or not.
> >
> VMS client uses SSH$ROOT:[ETC]SSH_CONFIG.
>
> --
> Chris

its weird it still returns the same list of kex in the handshake even after adding the kex (diffie-hellman-group1-sha1) in the unix server.... almost like its reading some other file and not the sshd_config in unix, tomorow will try with changing ssh_config...but don't hope much since its the server side...

debug(25-MAY-2023 12:25:28.40): Ssh2Transport/TRCOMMON.C:2167: server: kex = curve25519-sha256,curve25519-sha25
6...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diff
ie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exch
ange-sha1,diffie-hellman-group14-sha1, hk_alg = rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed255
19

On 2023-05-24 14:39:05 +0000, HCorte said:

> Trying to connect to another machine using ssh but failing with error of:
>
> debug(24-MAY-2023 12:20:30.82): Remote version: SSH-2.0-OpenSSH_8.0
> debug(24-MAY-2023 12:20:30.84): OpenSSH: Major: 8 Minor: 0 Revision: 0
> ...

Try OpenSSH 8.9-1D: https://vmssoftware.com/products/openssh/

--
Pure Personal Opinion | HoffmanLabs LLC

On Thursday, May 25, 2023 at 6:08:33 AM UTC-4, HCorte wrote:
> A quarta-feira, 24 de maio de 2023 à(s) 21:43:58 UTC+1, Bob Gezelter escreveu:
> > On Wednesday, May 24, 2023 at 10:39:08 AM UTC-4, HCorte wrote:
> > > Trying to connect to another machine using ssh but failing with error of:
> > >
> > > debug(24-MAY-2023 12:20:30.82): Remote version: SSH-2.0-OpenSSH_8.0
> > > debug(24-MAY-2023 12:20:30.84): OpenSSH: Major: 8 Minor: 0 Revision: 0
> > > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1825: All versions of OpenSSH handle kex guesses incorrectly.
> > > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
> > > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 20 to connection
> > > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2756: >TR packet_type=20
> > > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2318: lang s to c: `', lang c to s: `'
> > > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:2334: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
> > > _key = ssh-rsa)
> > > debug(24-MAY-2023 12:20:30.84): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 2 to connection
> > > debug(24-MAY-2023 12:20:30.85): Ssh2Transport/TRCOMMON.C:1113: Sending packet with type 1 to connection
> > > debug(24-MAY-2023 12:20:30.85): Ssh2Common/SSHCOMMON.C:180: DISCONNECT received: Algorithm negotiation failed.
> > > debug(24-MAY-2023 12:20:30.85): SshReadLine/SSHREADLINE.C:3728: Uninitializing ReadLine...
> > > warning: Authentication failed.
> > > debug(24-MAY-2023 12:20:30.85): Ssh2/SSH2.C:327: locally_generated = TRUE
> > > Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).
> > >
> > >
> > > ssh username@hostname -v
> > >
> > > what are the correct format for options in OpenVMS for the image tcpip$ssh_ssh-keygen2.exe??
> > >
> > > the equivalent of unix command:
> > > ssh -o "KexAlgorithms diffie-hellman-group1-sha1" -o "HostKeyAlgorithms ssh-dss" -o "Ciphers aes256-cbc" -i chaveprivada username@hostname
> > >
> > > also tried to change in the unix server to change sshd_config and added:
> > > ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20...@openssh.com,aes256-cbc
> > > KexAlgorithms curve255...@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
> > > macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1
> > >
> > > as well hostkeyalgorithms ssh-dss
> > >
> > > but still fails with the error:
> > > All versions of OpenSSH handle kex guesses incorrectly
> > > Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host
> > > _key = ssh-rsa
> > >
> > > here its confusing for me since if its been added "KexAlgorithms diffie-hellman-group1-sha1" in sshd_config of the unix system so OpenVMS should have stoped complaining about the KexAlgorithm...
> > >
> > > this attemp of changing sshd_config isn't a good option for security reasons but was to test if at least would fix in short term solution...
> > >
> > > Thanks
> > HCorte,
> >
> > Been there; dealt with that.
> >
> > First off, what is the version of OpenVMS and TCPIP?
> >
> > The problem is most likely not SSH keygen. The "incompatibility" is that many linux and other platforms have had key exchange and cipher updates in the interim, and TCPIP services has been a tad lagging.
> >
> > Enabling more detailed tracing will reveal which methods are acceptable to each system. If connecting from a more current host to an OpenVMS system, one can either specify older, and often deprecated, methods, either on the command line or in the hosts file. If connecting from the OpenVMS system, one probably has to modify the settings on the target system to accept the older methods.
> >
> > - Bob Gezelter, http://www.rlgsc.com
> @Bob its a very old version of VMS (from what I was told in this forum in another post)
> $ SHOW SYSTEM
> OpenVMS V8.4
>
> $ tcpip SHOW VERSION
> HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.7 - ECO 2
> on an HP rx3600 (1.67GHz/9.0MB) running OpenVMS V8.4
>
> @Jim had already tried but the gives the same information and in the help (ssh -h)
> SSH Secure Shell OpenVMS (V5.5) 3.2.0 on HP rx3600 (1.67GHz/9.0MB) - VMS V8.4
>
> Options:
>
> -l login_name Log in using this user name.
>
> +x Enable X11 connection forwarding (treat X11 clients as
> UNTRUSTED).
>
> +X Enable X11 connection forwarding (treat X11 clients as
> TRUSTED).
>
> -x Disable X11 connection forwarding.
>
> -i file Identity file for public key authentication
>
> -F file Read an alternative configuration file.
>
> -t Tty; allocate a tty even if command is given.
>
> -v Verbose; display verbose debugging messages. Equal to '-d 2'
>
> -d level Set debug level.
>
> -V Display version string.
>
> -q Quiet; don't display any warning messages.
>
> -p port Connect to this port. Server must be on the same port.
>
> -S Don't request a session channel.
>
> -L listen-port:host:port Forward local port to remote address
>
> -R listen-port:host:port Forward remote port to local address
>
> These cause ssh to listen for connections on a port, and
> forward them to the other side by connecting to host:port.
>
> -4 Use IPv4 to connect.
>
> -6 Use IPv6 to connect.
>
> -o 'option' Process the option as if it was read from a configuration
> file.
>
> -h Display this help.
>
>
>
> Command can be either:
>
> remote_command [arguments] ... Run command in remote host.
>
> -s service Enable a service in remote server.
>
>
>
> Supported ciphers:
>
> 3des-cbc,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,twofish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,des...@ssh.com,ca
> st128-cbc,rc2...@ssh.com,arcfour,none
>
> Supported MAC algorithms:
>
> hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96,hmac-...@ssh.com,hmac-sh...@ssh.com,hmac-ri...@ssh.com,hmac-ripemd160-96@ss
> h.com,hmac-t...@ssh.com,hmac-tig...@ssh.com,hmac-t...@ssh.com,hmac-tig...@ssh.com,hmac-t...@ssh.com,hmac-tiger
> 192...@ssh.com,none
>
> How do I get a list of the Kex supported (Key Enchange Algorithm)??
HCorte,

Enable full verification messages (look up the -d option for ssh using Google). Full debug will expose the negotiation conversation. The most likely problem is that the server end has deprecated the older methods (generally for security reasons).
The configuration of the ssh server on the remote end will need to be downgraded to accept the older algorithms.
Been there, done that. Generally for me it has been the reverse: connecting from a virtual Linux machine on my workstation to TCPIP 5.7 on a client machine. All I have to do is make the appropriate entries in the ssh config file (.ssh/config). For OVMS 8.4 and the corresponding TCPIP, I use:
KexAlgorithms +diffie-hellman-group1-sha1
HostKeyAlgorithms +ssh-dss
Ciphers +aes128-cbc

Note that the "problem" is on the server side, not the OpenVMS side. That version of OpenVMS TCPIP services simply does not have the currently in use algorithms. The up-to-date linux system has by default deprecated the older algorithms in favor of more secure alternatives. The remote end must be configured to accept the deprecated algorithms.

I can take some time to speak with you offline if you wish.

- Bob Gezelter, http://www.rlgsc.com

On 5/25/23 12:25 PM, Stephen Hoffman wrote:
> On 2023-05-24 14:39:05 +0000, HCorte said:
>
>> Trying to connect to another machine using ssh but failing with error of:
>>
>> debug(24-MAY-2023 12:20:30.82): Remote version: SSH-2.0-OpenSSH_8.0
>> debug(24-MAY-2023 12:20:30.84): OpenSSH: Major: 8 Minor: 0 Revision: 0
>> ...
>
> Try OpenSSH 8.9-1D: https://vmssoftware.com/products/openssh/

Which says:

"VSI OpenSSH can be installed only on VSI versions of OpenVMS. Integrity
and Alpha HPE customers now cannot install the OpenSSH PCSI kits."

Of course the OP should consider getting onto a VSI version of VMS, but
if that were easy it probably would have happened already.

> its weird it still returns the same list of kex in the handshake even
> after adding the kex (diffie-hellman-group1-sha1) in the unix
> server.... almost like its reading some other file and not the
> sshd_config in unix, tomorow will try with changing ssh_config...but
> don't hope much since its the server side...

Unix side sshd restarted after config change?

De

On Thu, 2023-05-25 at 13:54 -0700, Bob Gezelter wrote:
>    KexAlgorithms +diffie-hellman-group1-sha1
>    HostKeyAlgorithms +ssh-dss
>    Ciphers +aes128-cbc

I'd be delighted if VSI updated OpenSSH to enable ed22519. I live in
hope some day :-D
--
Tactical Nuclear Kittens

A sexta-feira, 26 de maio de 2023 à(s) 10:02:39 UTC+1, Single Stage to Orbit escreveu:
> On Thu, 2023-05-25 at 13:54 -0700, Bob Gezelter wrote:
> > KexAlgorithms +diffie-hellman-group1-sha1
> > HostKeyAlgorithms +ssh-dss
> > Ciphers +aes128-cbc
> I'd be delighted if VSI updated OpenSSH to enable ed22519. I live in
> hope some day :-D
> --
> Tactical Nuclear Kittens

yes @Bob the prolem is in the server side,
We tried to connect in another machine unix that has the version 7 of ssh and it worked well, so now will be installed that version in the final unix machine with a diferent port so the problem will be fixed as was suggested here, thanks for all the feedback.

yes @Craig not gona install a new version of ssh in OpenVMS machine don't know what kind of problems could/would arise from that and have 0 experience in installing any software in VMS...

@Dennis Boone yes it was done the restart of the service.

On 2023-05-26 14:17:03 +0000, HCorte said:

> A sexta-feira, 26 de maio de 2023 à(s) 10:02:39 UTC+1, Single Stage to
> Orbit escreveu:
>> On Thu, 2023-05-25 at 13:54 -0700, Bob Gezelter wrote:> >
>> KexAlgorithms +diffie-hellman-group1-sha1> > HostKeyAlgorithms
>> +ssh-dss> > Ciphers +aes128-cbc
>> I'd be delighted if VSI updated OpenSSH to enable ed22519. I live in>
>> hope some day :-D> --> Tactical Nuclear Kittens

OpenSSH version 6.5 and later offer ed22519, and—per the release
notes—the OpenVMS version does support ed25519.

The OpenVMS OpenSSH port does not support ed25519-sk keys, which is
related to FIDO / U2F authentication. Which would be nice to have, yes.

> yes @Bob the prolem is in the server side,

The problem is with the OpenVMS server and with its administration.

> We tried to connect in another machine unix that has the version 7 of
> ssh and it worked well, so now will be installed that version in the
> final unix machine with a diferent port so the problem will be fixed as
> was suggested here, thanks for all the feedback.

Old systems can and will fall behind, and network connections and
services will fail as peers are kept (more) current. Inevitably.

> yes @Craig not gona install a new version of ssh in OpenVMS machine
> don't know what kind of problems could/would arise from that and have 0
> experience in installing any software in VMS...

SSH connection downgrade scripts have gotten posted here on occasion.
I've posted a template sethost shell script for macOS and other Unix
and Linux platforms. That script allows systems with newer ssh easier
access into outdated OpenVMS ssh configurations, and to outdated iLO
ssh configurations. And easier telnet access, for those here connecting
to the antediluvian stuff.

https://groups.google.com/g/comp.os.vms/c/DhT_TWepPJ8/m/ReiPhF25CAAJ

While previous OpenVMS régimes were sometimes slow to push out patches
for SSH and TLS, VSI has been better about that.

From the HP era, TCP/IP Services V5.7-ECO5 or later will probably work
here, too. That patch became available in 2014.

An OpenVMS Alpha server in production in 2023 should be running
V8.4-2L1 or -2L2, with a plan underway to migrate to OpenVMS x86-64, or
a plan to port the apps to Linux, Windows, or otherwise, or a plan to
retire the server and its apps entirely.

Otherwise, and to paraphrase an aphorism from another context, if you
look around the table and don't know who the designated scapegoat is,
it's probably you.

--
Pure Personal Opinion | HoffmanLabs LLC

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Stephen
> Hoffman via Info-vax
> Sent: Friday, May 26, 2023 4:13 PM
> To: info-vax@rbnsn.com
> Cc: Stephen Hoffman <seaohveh@hoffmanlabs.invalid>
> Subject: Re: [Info-vax] VMS SSH2 - tcpip$ssh_ssh-keygen2.exe (Couldn't agree
> on kex or hostkey alg)
>
> On 2023-05-26 14:17:03 +0000, HCorte said:
>
> > A sexta-feira, 26 de maio de 2023 à(s) 10:02:39 UTC+1, Single Stage to
> > Orbit escreveu:
> >> On Thu, 2023-05-25 at 13:54 -0700, Bob Gezelter wrote:> >
> >> KexAlgorithms +diffie-hellman-group1-sha1> > HostKeyAlgorithms
> >> +ssh-dss> > Ciphers +aes128-cbc
> >> I'd be delighted if VSI updated OpenSSH to enable ed22519. I live in>
> >> hope some day :-D> --> Tactical Nuclear Kittens
>
> OpenSSH version 6.5 and later offer ed22519, and—per the release notes—
> the OpenVMS version does support ed25519.
>
> The OpenVMS OpenSSH port does not support ed25519-sk keys, which is
> related to FIDO / U2F authentication. Which would be nice to have, yes.
>
> > yes @Bob the prolem is in the server side,
>
> The problem is with the OpenVMS server and with its administration.
>
> > We tried to connect in another machine unix that has the version 7 of
> > ssh and it worked well, so now will be installed that version in the
> > final unix machine with a diferent port so the problem will be fixed
> > as was suggested here, thanks for all the feedback.
>
> Old systems can and will fall behind, and network connections and services will
> fail as peers are kept (more) current. Inevitably.
>

One option to address this is to adopt the commercial SSH package from Process Software.
< https://www.process.com/products/ssh/>

Supports
- OpenVMS VAX 5.5-2 or higher
- OpenVMS Alpha 6.2 or higher
- OpenVMS Integrity 8.2 or higher

** Runs on any version of TCP/IP Services supported by HPE or VSI

Can also get a free evaluation kit from Process Software.

> > yes @Craig not gona install a new version of ssh in OpenVMS machine
> > don't know what kind of problems could/would arise from that and have
> > 0 experience in installing any software in VMS...
>
> SSH connection downgrade scripts have gotten posted here on occasion.
> I've posted a template sethost shell script for macOS and other Unix and Linux
> platforms. That script allows systems with newer ssh easier access into
> outdated OpenVMS ssh configurations, and to outdated iLO ssh
> configurations. And easier telnet access, for those here connecting to the
> antediluvian stuff.
>
> https://groups.google.com/g/comp.os.vms/c/DhT_TWepPJ8/m/ReiPhF25CA
> AJ
>
> While previous OpenVMS régimes were sometimes slow to push out patches
> for SSH and TLS, VSI has been better about that.
>
> From the HP era, TCP/IP Services V5.7-ECO5 or later will probably work here,
> too. That patch became available in 2014.
>
> An OpenVMS Alpha server in production in 2023 should be running
> V8.4-2L1 or -2L2, with a plan underway to migrate to OpenVMS x86-64, or a
> plan to port the apps to Linux, Windows, or otherwise, or a plan to retire the
> server and its apps entirely.
>
> Otherwise, and to paraphrase an aphorism from another context, if you look
> around the table and don't know who the designated scapegoat is, it's
> probably you.
>

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

--
This email has been checked for viruses by AVG antivirus software.
www.avg.com

A domingo, 28 de maio de 2023 à(s) 02:15:35 UTC+1, kemain...@gmail.com escreveu:
> > -----Original Message-----
> > From: Info-vax <info-vax...@rbnsn.com> On Behalf Of Stephen
> > Hoffman via Info-vax
> > Sent: Friday, May 26, 2023 4:13 PM
> > To: info...@rbnsn.com
> > Cc: Stephen Hoffman <seao...@hoffmanlabs.invalid>
> > Subject: Re: [Info-vax] VMS SSH2 - tcpip$ssh_ssh-keygen2.exe (Couldn't agree
> > on kex or hostkey alg)
> >
> > On 2023-05-26 14:17:03 +0000, HCorte said:
> >
> > > A sexta-feira, 26 de maio de 2023 à(s) 10:02:39 UTC+1, Single Stage to
> > > Orbit escreveu:
> > >> On Thu, 2023-05-25 at 13:54 -0700, Bob Gezelter wrote:> >
> > >> KexAlgorithms +diffie-hellman-group1-sha1> > HostKeyAlgorithms
> > >> +ssh-dss> > Ciphers +aes128-cbc
> > >> I'd be delighted if VSI updated OpenSSH to enable ed22519. I live in>
> > >> hope some day :-D> --> Tactical Nuclear Kittens
> >
> > OpenSSH version 6.5 and later offer ed22519, and—per the release notes—
> > the OpenVMS version does support ed25519.
> >
> > The OpenVMS OpenSSH port does not support ed25519-sk keys, which is
> > related to FIDO / U2F authentication. Which would be nice to have, yes.
> >
> > > yes @Bob the prolem is in the server side,
> >
> > The problem is with the OpenVMS server and with its administration.
> >
> > > We tried to connect in another machine unix that has the version 7 of
> > > ssh and it worked well, so now will be installed that version in the
> > > final unix machine with a diferent port so the problem will be fixed
> > > as was suggested here, thanks for all the feedback.
> >
> > Old systems can and will fall behind, and network connections and services will
> > fail as peers are kept (more) current. Inevitably.
> >
> One option to address this is to adopt the commercial SSH package from Process Software.
> < https://www.process.com/products/ssh/>
>
> Supports
> - OpenVMS VAX 5.5-2 or higher
> - OpenVMS Alpha 6.2 or higher
> - OpenVMS Integrity 8.2 or higher
>
> ** Runs on any version of TCP/IP Services supported by HPE or VSI
>
> Can also get a free evaluation kit from Process Software.
> > > yes @Craig not gona install a new version of ssh in OpenVMS machine
> > > don't know what kind of problems could/would arise from that and have
> > > 0 experience in installing any software in VMS...
> >
> > SSH connection downgrade scripts have gotten posted here on occasion.
> > I've posted a template sethost shell script for macOS and other Unix and Linux
> > platforms. That script allows systems with newer ssh easier access into
> > outdated OpenVMS ssh configurations, and to outdated iLO ssh
> > configurations. And easier telnet access, for those here connecting to the
> > antediluvian stuff.
> >
> > https://groups.google.com/g/comp.os.vms/c/DhT_TWepPJ8/m/ReiPhF25CA
> > AJ
> >
> > While previous OpenVMS régimes were sometimes slow to push out patches
> > for SSH and TLS, VSI has been better about that.
> >
> > From the HP era, TCP/IP Services V5.7-ECO5 or later will probably work here,
> > too. That patch became available in 2014.
> >
> > An OpenVMS Alpha server in production in 2023 should be running
> > V8.4-2L1 or -2L2, with a plan underway to migrate to OpenVMS x86-64, or a
> > plan to port the apps to Linux, Windows, or otherwise, or a plan to retire the
> > server and its apps entirely.
> >
> > Otherwise, and to paraphrase an aphorism from another context, if you look
> > around the table and don't know who the designated scapegoat is, it's
> > probably you.
> >
> Regards,
>
> Kerry Main
> Kerry dot main at starkgaming dot com
>
>
>
>
> --
> This email has been checked for viruses by AVG antivirus software.
> www.avg.com

its seems that beside the changes made to /etc/ssh/sshd_config (kex,ciphers,mac's),
it also need to change the /etc/sysconfig/sshd and uncomment the line
CRYPTO_POLICY
from there is worked even with the ssh v8 in the server, so it was /etc/sysconfig/sshd file that missing that change to fix it.

files changed needed to make it work:
/etc/ssh/sshd_config
/etc/sysconfig/sshd