Bug 7618 - Host key handling on non-standard port broken
Summary: Host key handling on non-standard port broken
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.13.0
Assignee: Pierre Ossman
URL:
Keywords: frifl_tester, relnotes
Depends on:
Blocks:
 
Reported: 2020-12-29 13:32 CET by Pierre Ossman
Modified: 2021-01-08 10:58 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2020-12-29 13:32:06 CET
Or logic for handling SSH host keys when the port isn't 22 is currently broken and has been since bug 4557.

The logic for OpenSSH is as follows:

 1. If there are *any* keys for host:port, then use only those (including complaining if they don't match)

 2. If there is a matching key for host:22, then silently proceed

 3. Handle as a new host, prompting the user

The idea here probably being that any non-standard port is probably the standard SSH server with a different port for firewall reasons.


However our logic ended up being:

 1. If there are *no* keys for host:port, handle as a new host, prompting the user

 2. If there is a matching key for host:22, then silently proceed

 3. Handle as a changed host, prompting the user


This causes two problems:

 a. We get extra warnings for the user for the scenario of the standard SSH server on non-standard port

 b. A mild security issue as the owner of the :22 server can silently MITM servers on other ports. I say "mild" because the attacker would need to be able to control port 22, which means they are root and can likely do other attacks anyway. The proper behaviour also suffers from MITM issues on the initial connection instead.
Comment 1 Pierre Ossman cendio 2020-12-29 14:01:47 CET
It's actually even more broken than that. We just do the same check again (i.e. with the non-standard port, not port 22).

So this has obviously never worked and was never actually tested.
Comment 3 Pierre Ossman cendio 2020-12-29 16:24:55 CET
Works better now. Tester should make sure our logic now follows the one in OpenSSH.
Comment 4 Frida Flodin cendio 2021-01-08 10:58:05 CET
This works better now, I tested the following cases

    Case 1: No known hosts, connecting to port 22
    Case 2: Known host:22, connecting to port 22
    Case 3: Known host:22, connecting to non-standard port e.g. port 33333
    Case 4: Known host:22 *CORRECT* key saved, and known host:33333 with 
            *WRONG* key saved, connecting to host:33333
    Case 5: Known host:33333, connecting to port 22
    Case 6: Known host:33333, connecting to port 44444


And the results are show in the table bellow.

|                   | Case 1 | Case 2 | Case 3 | Case 4 | Case 5 | Case 6 |
|-------------------+--------+--------+--------+--------+--------+--------|
| tl-4.12           | o      | ✓      | o      | x      | o      | o      |
| Nigtly build 6711 | o      | ✓      | ✓*     | x      | o      | o      |
| OpenSSH 8.2       | o      | ✓      | ✓      | x      | o      | o      |


   Legend:
     ✓ Silently moves on
     o Promt user, handle as new host
     x Wrong key, WARNING!

 * Adds [host]:33333 to known_hosts (As noted on bug 7536)

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