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.
This is now implemented in OpenSSH and tlclient. What's left is to update the documentation and the installer.
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.
- 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
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.
(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.
(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.
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).
(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.
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.
(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.
(In reply to comment #7) > [...] Bug 4716.
Apart from hitting bug 2622 multiple times, I've done extensive testning and found no obvious flaws.
