[Info-vax] VMS SSH2 - tcpip$ssh_ssh-keygen2.exe (Couldn't agree on kex or hostkey alg)

Thu May 25 16:54:46 EDT 2023

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 at 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 at hostname 
> > > 
> > > also tried to change in the unix server to change sshd_config and added: 
> > > ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20... at openssh.com,aes256-cbc 
> > > KexAlgorithms curve255... at 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... at ssh.com,ca 
> st128-cbc,rc2... at ssh.com,arcfour,none 
> 
> Supported MAC algorithms: 
> 
> hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96,hmac-... at ssh.com,hmac-sh... at ssh.com,hmac-ri... at ssh.com,hmac-ripemd160-96 at ss 
> h.com,hmac-t... at ssh.com,hmac-tig... at ssh.com,hmac-t... at ssh.com,hmac-tig... at ssh.com,hmac-t... at ssh.com,hmac-tiger 
> 192... at 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