Bug 7643 - OpenSSH certificate host keys incorrectly handled
Summary: OpenSSH certificate host keys incorrectly handled
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: linma_tester, relnotes
Depends on:
Blocks: 7641
  Show dependency treegraph
 
Reported: 2021-02-10 14:14 CET by Pierre Ossman
Modified: 2021-02-11 16:42 CET (History)
1 user (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2021-02-10 14:14:50 CET
We don't currently handle OpenSSH certificates properly (bug 7641). Before bug 7536 this wasn't particularly noticable as we just treated every key type as a blob and simply stored that.

However certificates behave slightly different, and one difference is that they will not be enumerated by the server when getting all host keys. So we get in to this bad sequence:

 1. client connects to server
 2. unknown certificate host key is presented to the user
 3. user approves host key and it is stored to disk
 4. a list of all (normal) host keys is received from the server
 5. the just stored certificate host key is removed from disk since it wasn't in the list

End result is that the users end up having to approve the key over and over again.


Bug 7461 is about handling certificates properly. This bug is about avoiding the above extreme scenario.
Comment 2 Pierre Ossman cendio 2021-02-10 14:20:18 CET
ssh has the argument -HostKeyAlgorithms to control which algorithms to support. We could likely use that and specify "-*-cert-*" to get rid of all certificate based algorithms.

However that likely prevents us from implementing bug 7623, so I'd rather avoid doing that.

We could change ssh and remove these certificate algorithms from the default list, which should be more robust. We could also try to piggyback on ssh's mechanism to downgrade a certificate host key to a plain host key. Will have to experiment to see which is easier.
Comment 3 Pierre Ossman cendio 2021-02-10 14:22:46 CET
To test things simply generate a CA signing key:

> ssh-keygen -N '' -t ed25519 -f /etc/ssh/host_ca_key

Then sign the existing host key:

> ssh-keygen -h -s /etc/ssh/host_ca_key -I test -n lab-189,lab-189.lkpg.cendio.se /etc/ssh/ssh_host_ed25519_key

Then configure sshd to use the new certificate:

> HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub
Comment 6 Pierre Ossman cendio 2021-02-10 14:34:17 CET
Works better now. Tester should verify proper behaviour on systems with plain host keys and those with certificate host keys.
Comment 7 Linn cendio 2021-02-11 16:42:52 CET
Tested on Fedora 32 and can confirm that the user was warned of a "possible security breach" and had to reapprove the key every login when using certificate host keys. There was also this log warning present:
> Unexpected host key received from server. Possible attack in progress.
With the fix, logging in with certificate host keys now only warns the user on the first login, and later logins are allowed without any warnings. The log looks good, and the warning on the first login is logged.

Logging in with plain host keys works as before.

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