Bug 2945

Summary: refuse to connect to wrong agent
Product: ThinLinc Reporter: Pierre Ossman <ossman@cendio.se>
Component: ClientAssignee: Pierre Ossman <ossman@cendio.se>
Status: CLOSED FIXED QA Contact: Bugzilla mail exporter <bugzilla-qa@cendio.se>
Severity: Normal    
Priority: P2 Keywords: derfian_tester
Version: pre-1.0   
Target Milestone: 4.1.0   
Hardware: PC   
OS: All   
Acceptance Criteria:
Bug Depends on: 4557    
Bug Blocks:    

Description From cendio 2008-10-15 11:21:42
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 From cendio 2013-03-11 13:23:36 -------
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 From cendio 2013-03-28 12:30:53 -------
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 From cendio 2013-03-28 12:32:28 -------
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 From cendio 2013-04-12 16:23:04 -------
Fixed in r27063 by limiting the requested host key types to those we can
------- Comment #5 From cendio 2013-04-15 09:34:46 -------
Meh. ssh barfs on unknown algorithms. I think we need better future proofing
than that.
------- Comment #6 From cendio 2013-04-15 10:55:16 -------
(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 From cendio 2013-05-21 12:33:34 -------
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.