When we connect to the agent we do so with a list of expected host keys (which we got via the master). So we instruct ssh to only allow these specific host key types. However we don't pay attention to ordering so we may prefer weaker algorithms when we could use something stronger. We already see this happening in practice where ssh-rsa gets priority over ecdsa-sha2-nistp256. This is a regression from bug 4557 where we moved host key handling in to tlclient. Also see related bug 7623.
Also pushed upstream: https://github.com/openssh/openssh-portable/pull/331
Works better now. With this fixed, I can see this when connecting to a RHEL 8 agent: > 2022-07-11T09:27:12: ssh[E]: debug1: kex: host key algorithm: ecdsa-sha2-nistp256 But without the change, and with 4.14.0 I get: > 2022-07-11T09:30:08: ssh[E]: debug1: kex: host key algorithm: ssh-rsa ecdsa is also still preferred with a fix for bug 7935 in place.
Tested with client build 2665 on SLES 12 and Windows 10. The master and agent were both server build 2760, with the master on Ubuntu 20.04 and the agent on Ubuntu 22.04. > * Only host key algorithms that are in OpenSSH's default list are used Yes. The agent had host keys for both RSA and ED25519. With the default sshd_config on the agent, ssh-ed25519 was used by the client to access the agent. When disabling ssh-ed25519, the algorithm used was instead rsa-sha2-512. I disabled ssh-ed25519 by adding this line to sshd_config: > HostKeyAlgorithms -ssh-ed25519 > * OpenSSH's default priority of host key algorithms is always used Yes. I tested the priority host key used for the agent connection, see below: ED25519 > ECDSA > RSA > * All host key algorithms that are reported by the agent are considered, except those not in OpenSSH's default list Yes. Once again, the agent had host keys for RSA and ED25519, with ssh-ed25519 disabled. If I removed the RSA key, no usable key could be found and I was not able to log in. The popup error said "Internal error in SSH" and the content of the client log on SLES 12 is shown below: > 2022-08-03T14:18:28: ssh[E]: debug1: Remote protocol version 2.0, remote software version OpenSSH_8.9p1 Ubuntu-3 > 2022-08-03T14:18:28: ssh[E]: debug1: compat_banner: match: OpenSSH_8.9p1 Ubuntu-3 pat OpenSSH* compat 0x04000000 > 2022-08-03T14:18:28: ssh[E]: debug1: Authenticating to 10.48.2.55:22 as 'cendio' > 2022-08-03T14:18:28: ssh[E]: debug1: SSH2_MSG_KEXINIT sent > 2022-08-03T14:18:28: ssh[E]: SYSTEM ERROR: 104 The logging was the same on Windows, except for the last line: > 2022-08-03T14:18:28: ssh[E]: SYSTEM ERROR: 10054 This is similar to the behaviour of ssh:ing to a machine with no valid host key: > $ ssh a@b > Connection closed by UNKNOWN port 65535
