www.cendio.com
Bug 4557 - let tlclient.bin handle storage of ssh host keys
: let tlclient.bin handle storage of ssh host keys
Status: CLOSED FIXED
: ThinLinc
Client
: trunk
: PC Unknown
: P2 Normal
: 4.1.0
Assigned To:
:
:
:
: 2945 3183
  Show dependency treegraph
 
Reported: 2013-03-07 17:35 by
Modified: 2013-06-20 15:20 (History)


Attachments


Note

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


Description From cendio 2013-03-07 17:35:44
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 From cendio 2013-03-12 13:33:07 -------
This is now implemented in OpenSSH and tlclient. What's left is to update the
documentation and the installer.
------- Comment #2 From cendio 2013-03-13 16:15:38 -------
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 From cendio 2013-06-12 09:55:32 -------
- 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 From cendio 2013-06-13 14:32:19 -------
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 From cendio 2013-06-13 16:33:01 -------
(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 From cendio 2013-06-14 14:39:48 -------
(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 From cendio 2013-06-17 11:48:48 -------
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 From cendio 2013-06-17 13:21:45 -------
(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 From cendio 2013-06-18 10:00:08 -------
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 From cendio 2013-06-18 12:36:52 -------
(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 From cendio 2013-06-19 16:41:38 -------
(In reply to comment #7)
> [...]

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