Bug 7639 - Host key fingerprints not shown in common sha-256 format
Summary: Host key fingerprints not shown in common sha-256 format
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.14.0
Assignee: William Sjöblom
URL:
Keywords: ossman_tester, relnotes
Depends on:
Blocks: 7657
  Show dependency treegraph
 
Reported: 2021-02-09 13:01 CET by Pierre Ossman
Modified: 2021-09-02 09:22 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:
- Host key fingerprints use the same format as in SSH - In the GUI - In the logs - The change should not require users to re-accept host keys that were accepted before the change


Attachments

Description Pierre Ossman cendio 2021-02-09 13:01:30 CET
OpenSSH used to show host key fingerprints using MD5, so we did the same when showing them in ThinLinc. However OpenSSH 6.8 changed this to SHA-256 instead.

In order to show something familiar to users we should follow upstream's change and also switch algorithm.
Comment 8 William Sjöblom cendio 2021-08-30 14:08:26 CEST
Tested the client on Fedora 34 and the host key fingerprint shown when connecting to a new, unknown, host is now identical to what is shown by OpenSSH.

Ideally, this bug is to be tested along with bug 7756 on both Windows and macOS. We want to make sure the correct SHA256 fingerprint is shown in the following scenarios:

- When connecting to a host for the first time
- When connecting to a known host, but the hosts public key has changed since last time
  - With the client configured to allow connecting if the key has changed
  - With the client configured to disallow connecting if the key has changed
Comment 9 Pierre Ossman cendio 2021-09-02 09:22:33 CEST
Tested on Fedora 34 against Ubuntu 20.04.

> - Host key fingerprints use the same format as in SSH
>   - In the GUI

Yup. Checked:

 * New host key
 * Changed host key
 * Changed host key, and not allowed to continue

>   - In the logs

Yup.

 * Logged received host key
 * Logged known host keys
 * Logged acceptable host keys
 * Logged new keys via hostkeys-00 extension

> - The change should not require users to re-accept host keys that were accepted before the change

Works fine.

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