A SSH server can have many possible host keys, but only a single one can actually be used during the connection handshake. If this key isn't already known to the client then we must ask the user to verify it. Therefore it is preferred if we get a key we already know about. OpenSSH's standard ssh command does indeed prefer already known keys (see order_hostkeyalgs()), however the ThinLinc client does not. This is a regression since bug 4557 when we moved host key handling in to tlclient.
Also see related bug 7624.
Works well now: > * Known host keys should be used when connecting, even if better ones are offered by the server Yup. Connected to RHEL 9 where the server had RSA, ECDSA and ED2559 host keys, but the client only knew about the RSA one. Client still used the RSA key without complaining to the user. > * If all known host keys are too insecure to be used, then the client should fall back to using one of the others offered by the server Yup. Connected to CentOS 6 where an RSA key was known, but not usable because of lack of SHA-1 support, but an ECDSA key was also available. The client showed the host key change dialogue and allowed me to proceed with the ECDSA key. > * Known hosts should have no effect on the agent connection, where only keys got from the master should be used Yup. Made sure the agent only knew about the RSA key, even though the server also had ECDSA and ED2559 keys. The master connect allowed all three (and used ED2559), but the agent connection was done with the RSA key. Server was RHEL 9. Client was Fedora 35 in all cases.
Tested with client build 2665 on Windows 10 and server build 2760 on Ubuntu 20.04. > * Known host keys should be used when connecting, even if better ones are offered by the server Yes, a known ECDSA key was preferred over an unknown ED25519 key. > * If all known host keys are too insecure to be used, then the client should fall back to using one of the others offered by the server Yes. Used server on CentOS 6 with both RSA and ECDSA keys, but client only knew about the RSA key. When logging in, the client showed the host key change dialog and I could successfully log in with the ECDSA key. > * Known hosts should have no effect on the agent connection, where only keys got from the master should be used Yes, the client log shows that the master connection was made with an ECDSA key, and the agent connection was made with an ED25519 key. I also checked with client on SLES 12 what happened when several (but not all) host keys were known to the client. This scenario does not cause any prompt, and it seems that the strongest key is preferred (likely related to bug 7624).
(In reply to Linn from comment #4) > ... > > * Known hosts should have no effect on the agent connection, where only keys got from the master should be used > Yes, the client log shows that the master connection was made with an ECDSA > key, and the agent connection was made with an ED25519 key. To clarify, the client only knew about the ECDSA key, which the master connection was made with. For the agent connection, the ED25519 key was used, despite not being previously known.
