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: NEW
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: LowPrio
Assignee: Peter Åstrand
Depends on:
Reported: 2013-06-19 16:40 CEST by Karl Mikaelsson
Modified: 2013-06-25 11:09 CEST (History)
0 users

See Also:
Acceptance Criteria:


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.

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