Bug 4716 - tlclient handles updated ssh host keys differently with registry/file backends
Summary: tlclient handles updated ssh host keys differently with registry/file backends
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.12.1
Assignee: Pierre Ossman
URL:
Keywords: frifl_tester, prosaic
Depends on:
Blocks: 7536
  Show dependency tree / graph
 
Reported: 2013-06-19 16:40 CEST by Karl Mikaelsson
Modified: 2021-01-21 12:45 CET (History)
1 user (show)

See Also:
Acceptance Criteria:
* The client should add a new host key (after user confirmation) used in the handshake for an existing server * The client should keep all existing host keys for that server, even if they have the same type * Old clients should be able to read the host keys stored by the new client, even if there are multiple of the same type

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Karl Mikaelsson cendio 2013-06-19 16:40:01 CEST 
Consider the following scenario. Our SSH server has two host keys:

Key-A: ssh-rsa
Key-B: ecdsa-sha2-nist256

We connect to the server with tlclient and store the host keys. We'll
thus have a known_hosts file as follows:

> server ssh-rsa key-a
> server ecdsa-sha2-nist256 key-b

or registry entries (on Windows):

> "server,ssh-rsa" = "key-a"
> "server,ecdsa-sha2-nist256" = "key-b"

The server updates their ssh keys to Key-C and Key-D for any reason,
and tlclient connects to the server again, we'll get asked if we want
to update the keys (depending on the ALLOW_HOSTKEY_UPDATE
setting). The user selects "Yes" in this dialog, which will tell
tlclient to add the new host key to the known hosts database.

Here's where the two clients differ in behavour. On Windows, all new
keys are written to the registry, using the key "server,keytype" which
means that old keys are overwritten by the new keys. On other
platform, all news keys are appended to the known_hosts file. This
results in the following known_hosts file on !Windows:

> server ssh-rsa key-a
> server ecdsa-sha2-nist256 key-b
> server ssh-rsa key-c
> server ecdsa-sha2-nist256 key-d

and the following registry entries on Windows:

> "server,ssh-rsa" = "key-c"
> "server,ecdsa-sha2-nist256" = "key-d"

My gut feeling tells me that the registry model is the best because
you get noticed every time the host key changes, but on !Windows we
keep all keys in the file. I'm not fully convinced by either model but
I think having both is confusing, so we should probably stick to one
model for all client platforms.
Comment 1 Pierre Ossman cendio 2020-12-23 13:16:36 CET 
This is needed for bug 7536 if we want to match the behaviour of OpenSSH.
Comment 6 Pierre Ossman cendio 2020-12-28 16:13:38 CET 
Works well now:

> 
> * The client should add a new host key (after user confirmation) used in the handshake for an existing server
> 

Yup.

> 
>  * The client should remove old host keys of the same type for that server in said scenario
> 

Yup.

>
>  * The client should keep other host keys for that server if they have a different type
>

Yup. 


Tester should note that bug 7536 also affects storage of host keys so make sure it is the right
Comment 7 Pierre Ossman cendio 2021-01-07 12:32:33 CET 
Bug 7536 requires us to be able to handle multiple keys of the same type, so the fix here needs to be backed out. We need to get the Windows handling to match the Linux handling instead.
Comment 10 Pierre Ossman cendio 2021-01-07 16:46:07 CET 
Redone and now all platforms support saving as many keys as you'd like.

The format used in the Windows registry was only slightly tweaked in order to maintain backward compatibility. Older clients (or current one) don't care about the details of the name, just as long as the host bit matches. So all client versions should pick up all entries and do the right thing.

(of course, older clients can't write multiple keys of the same type properly though)
Comment 11 Frida Flodin cendio 2021-01-11 09:10:33 CET 
Tested the Windows client and it can now save multiple keys of the same type for
the same host. Also tested that the Linux client still does the same. Had to comment out changes for Bug 7536 in order to verify that the changes for this bug
is working.

Tested the following acceptance criteria on both Linux and Windows client.

> * The client should add a new host key (after user confirmation) used 
>   in the handshake for an existing server
It does

> * The client should keep all existing host keys for that server, 
>   even if they have the same type
Yes

> * Old clients should be able to read the host keys stored by the new client,
>   even if there are multiple of the same type
Linux: yes, Windows: yes
Note You need to log in before you can comment on or make changes to this bug.