Bug 4557 - let tlclient.bin handle storage of ssh host keys
Summary: let tlclient.bin handle storage of ssh host keys
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.1.0
Assignee: Pierre Ossman
URL:
Keywords: derfian_tester
Depends on:
Blocks: 2945 3183
  Show dependency treegraph
 
Reported: 2013-03-07 17:35 CET by Pierre Ossman
Modified: 2013-06-20 15:20 CEST (History)
0 users

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2013-03-07 17:35:44 CET
As a result of bug 3183, it's easier to let tlclient.bin handle storage of ssh host keys. OpenSSH will then consider all host keys to be unknown, and it will be up to tlclient to verify them against what's on disk/in the registry.

For consistency, we'll do this on all platforms even though it is only strictly required on Windows.
Comment 1 Pierre Ossman cendio 2013-03-12 13:33:07 CET
This is now implemented in OpenSSH and tlclient. What's left is to update the documentation and the installer.
Comment 2 Pierre Ossman cendio 2013-03-13 16:15:38 CET
All done.

Tester needs to check the docs and do thorough testing of host key checks. The new client should be backwards compatible with the older putty host keys, so that also needs to be verified.
Comment 3 Karl Mikaelsson cendio 2013-06-12 09:55:32 CEST
- Windows (registry backend)
  - [X] Save host keys to registry
  - [X] Load host keys from registry
  - [X] Update host keys in registry (with/without ALLOW_HOSTKEY_UPDATE)
  - [X] Backwards compatibility with PuTTY keys
  - [X] Survive invalid/undecipherable keys
- Linux (file backend)
  - [X] Save host keys to file
  - [X] Load host keys from file
  - [X] Update host keys in file (with/without ALLOW_HOSTKEY_UPDATE)
  - [X] Survive invalid/undecipherable keys
- Documentation
  - [X] Check for correctness
Comment 4 Aaron Sowry cendio 2013-06-13 14:32:19 CEST
For servers which use ECDSA keys (e.g. Ubuntu), tlclient on Windows will write the ECDSA key to the registry after connecting to the master, and then promptly overwrite it with an RSA key after connecting to the agent.

This results in a "security breach" warning for every connection. We should fix this.
Comment 5 Pierre Ossman cendio 2013-06-13 16:33:01 CEST
(In reply to comment #4)
> For servers which use ECDSA keys (e.g. Ubuntu), tlclient on Windows will write
> the ECDSA key to the registry after connecting to the master, and then promptly
> overwrite it with an RSA key after connecting to the agent.
> 
> This results in a "security breach" warning for every connection. We should fix
> this.

Fixed in r27518 and r27519.


Tester should also make sure to test both ip-addresses and hostnames, as well as testing non-standard ports. This goes for both Windows and Unix.
Comment 6 Aaron Sowry cendio 2013-06-14 14:39:48 CEST
(In reply to comment #5)
> Fixed in r27518 and r27519.

When connecting to a non-standard port, the registry keys look like:

[[[10.47.252.168]:2222]]:2222,ssh-rsa

i.e. the port information is being duplicated.
Comment 7 Karl Mikaelsson cendio 2013-06-17 11:48:48 CEST
When using "host,keytype" as a key (damn you, term overloading!) for the SSH host key stored in Windows registry, we don't validate that the key is of the given keytype, which may lead to keys that are never invalidated by updated SSH host keys.

1. Admin creates custom client with a typo:ed "host,shh-rsa"="key" known hosts entry.
2. Server changes host keys for any reason, and user accepts the new ones.
3. tlclient writes "host,ssh-rsa"="newkey" to the registry, failing to overwrite the old key
4. The old key is still valid.

Other causes for errors in step 1 is mistaking the key algorithms for eachother (ssh-rsa instead of ecdsa-sha2-nistp256, ssh-dsa instead of ssh-rsa etc).
Comment 8 Pierre Ossman cendio 2013-06-17 13:21:45 CEST
(In reply to comment #6)
> (In reply to comment #5)
> > Fixed in r27518 and r27519.
> 
> When connecting to a non-standard port, the registry keys look like:
> 
> [[[10.47.252.168]:2222]]:2222,ssh-rsa
> 
> i.e. the port information is being duplicated.

Fixed in r27527.
Comment 9 Aaron Sowry cendio 2013-06-18 10:00:08 CEST
Found a fun little corner case.

For hosts which support multiple key types, if one of these key types is ECDSA, then the client will receive an ECDSA key when connecting to the master, and an RSA key when connecting to the agent. This is because vsmagent doesn't support ECDSA yet. If:

- agent_hostname isn't set
- the master and agent are on the same machine
- the client is connecting using the master's hostname rather than IP

then tlclient will associate the ECDSA key with the hostname, and the RSA key with the IP address, even though they represent the same host.

If the client then connects using the IP address, tlclient will throw a "security breach" warning, since it has cached an RSA key but is being presented with an ECDSA key. We probably need to take into account the key types when doing lookups, rather than just using them as a way to avoid conflicts.
Comment 10 Pierre Ossman cendio 2013-06-18 12:36:52 CEST
(In reply to comment #9)
> Found a fun little corner case.
> 
> For hosts which support multiple key types, if one of these key types is ECDSA,
> then the client will receive an ECDSA key when connecting to the master, and an
> RSA key when connecting to the agent. This is because vsmagent doesn't support
> ECDSA yet. If:
> 
> - agent_hostname isn't set
> - the master and agent are on the same machine
> - the client is connecting using the master's hostname rather than IP
> 
> then tlclient will associate the ECDSA key with the hostname, and the RSA key
> with the IP address, even though they represent the same host.
> 
> If the client then connects using the IP address, tlclient will throw a
> "security breach" warning, since it has cached an RSA key but is being
> presented with an ECDSA key. We probably need to take into account the key
> types when doing lookups, rather than just using them as a way to avoid
> conflicts.

WONTFIX. ssh behaves the same way, and for good reason. In this scenario, it might as well be an attacker that has intercepted the traffic and that's why you are seeing a different key.
Comment 11 Karl Mikaelsson cendio 2013-06-19 16:41:38 CEST
(In reply to comment #7)
> [...]

Bug 4716.
Comment 12 Karl Mikaelsson cendio 2013-06-20 15:20:52 CEST
Apart from hitting bug 2622 multiple times, I've done extensive testning and found no obvious flaws.

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