Bugzilla – Bug 2945
refuse to connect to wrong agent
Last modified: 2013-05-21 12:33:34
You need to
before you can comment on or make changes to this bug.
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
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
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
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
2013-03-28T09:50:06: Fingerprint from server:
2013-03-28T09:50:07: Known host key fingerprints:
2013-03-28T09:50:07: Acceptable host key fingerprints:
2013-03-28T09:50:07: No acceptable host key found.
Fixed in r27063 by limiting the requested host key types to those we can
Meh. ssh barfs on unknown algorithms. I think we need better future proofing
(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:
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.