Bug 7623 - Client doesn't prefer already known host keys when connecting
Summary: Client doesn't prefer already known host keys when connecting
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.15.0
Assignee: Pierre Ossman
URL:
Keywords: linma_tester, prosaic
Depends on:
Blocks:
 
Reported: 2021-01-07 11:02 CET by Pierre Ossman
Modified: 2022-08-02 15:06 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:
* Known host keys should be used when connecting, even if better ones are offered by the server * 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 * Known hosts should have no effect on the agent connection, where only keys got from the master should be used


Attachments

Description Pierre Ossman cendio 2021-01-07 11:02:45 CET
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.
Comment 1 Pierre Ossman cendio 2021-01-07 11:09:40 CET
Also see related bug 7624.
Comment 3 Pierre Ossman cendio 2022-07-12 09:18:03 CEST
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.
Comment 4 Linn cendio 2022-08-02 13:22:30 CEST
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).
Comment 5 Linn cendio 2022-08-02 15:06:06 CEST
(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.

Note You need to log in before you can comment on or make changes to this bug.