Bug 2945 - refuse to connect to wrong agent
Summary: refuse to connect to wrong agent
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: pre-1.0
Hardware: PC All
: P2 Normal
Target Milestone: 4.1.0
Assignee: Pierre Ossman
Keywords: derfian_tester
Depends on: 4557
  Show dependency treegraph
Reported: 2008-10-15 11:21 CEST by Pierre Ossman
Modified: 2013-05-21 12:33 CEST (History)
0 users

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2008-10-15 11:21:42 CEST
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!".
Comment 1 Pierre Ossman cendio 2013-03-11 13:23:36 CET
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.
Comment 2 Pierre Ossman cendio 2013-03-28 12:30:53 CET
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.
Comment 3 Pierre Ossman cendio 2013-03-28 12:32:28 CET
Example log output:

2013-03-28T09:50:06: ssh[E]: CONFIRM HOST KEY: 22 
2013-03-28T09:50:06: Fingerprint from server: 
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.
Comment 4 Pierre Ossman cendio 2013-04-12 16:23:04 CEST
Fixed in r27063 by limiting the requested host key types to those we can accept.
Comment 5 Pierre Ossman cendio 2013-04-15 09:34:46 CEST
Meh. ssh barfs on unknown algorithms. I think we need better future proofing than that.
Comment 6 Pierre Ossman cendio 2013-04-15 10:55:16 CEST
(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:

Comment 7 Karl Mikaelsson cendio 2013-05-21 12:33:34 CEST
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.

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