When we connect to the agent, we already know the expected host key (because vsmserver gave it to us). If we for some reason get the wrong one (e.g. bad config, network problems or an actual security breach), we just present the user with a dialog to confirm that this is the correct key. This is of course _wrong_ as we already know the expected key. Besides the obvious security problem, the session has no chance of working anyway as we're not connecting to the machine that is running our Xvnc. We should first and foremost make sure we send a "no" back to SSH in this case. We should also present the user with a different error message. Something like "This is the wrong agent. Something is misconfigured or the system is under attack. Talk to your system administrator!".
Odd. The code for this has been around since at least 2005. Something must have been broken... Anyhoo, it's been rewritten as part of bug 4557 and should now work perfectly.
Bug exposed by this work. We only get some host keys from the agent and ssh might pick a completely different one. This makes it impossible to connect to the agent. As a specific example, Ubuntu uses ECDSA but the agent only gives us the RSA and DSA keys (see bug 4568). We should make sure that ssh only asks for the appropriate host keys.
Example log output: 2013-03-28T09:50:06: ssh[E]: CONFIRM HOST KEY: 10.47.254.194 10.47.254.194 22 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBIsLsjIpBvOOYZGFqeWYirHTPQ96VqylwqTsqrPe5Tm8L7sfZm4TXlE4rCPhqbH5YLNE2ivGKrW+krLZr6KwS94= 2013-03-28T09:50:06: Fingerprint from server: |83:44:d5:d8:02:39:d8:44:4f:7a:9b:c2:66:ab:ef:83| 2013-03-28T09:50:07: Known host key fingerprints: 2013-03-28T09:50:07: |68:f1:c4:dd:54:81:f9:c6:ed:de:22:46:86:70:7f:78| 2013-03-28T09:50:07: |83:44:d5:d8:02:39:d8:44:4f:7a:9b:c2:66:ab:ef:83| 2013-03-28T09:50:07: Acceptable host key fingerprints: 2013-03-28T09:50:07: |68:f1:c4:dd:54:81:f9:c6:ed:de:22:46:86:70:7f:78| 2013-03-28T09:50:07: |f8:3c:51:ba:72:aa:e3:a5:81:08:57:1e:ee:26:71:41| 2013-03-28T09:50:07: No acceptable host key found.
Fixed in r27063 by limiting the requested host key types to those we can accept.
Meh. ssh barfs on unknown algorithms. I think we need better future proofing than that.
(In reply to comment #5) > Meh. ssh barfs on unknown algorithms. I think we need better future proofing > than that. Fixed in r27071. Also submitted upstream: https://bugzilla.mindrot.org/show_bug.cgi?id=2089
Tested on Ubuntu 12.04 server and Linux client. - Connecting to a new server will make the client warn about a new unrecognized key fingerprint and allow you to accept it. - Misconfiguring /vsmagent/agent_hostname makes the client refuse to go on to connect to the agent, showing a warning to the user. - ECDSA keys are ignored by the agent, and the second connection (to the agent) is verified using the server RSA key rather than the ECSDA key, which is the expected behavior. All good, closing.
