Bug #118311 MySQL Workbench reports SSH host key fingerprints in SHA1 format, nobody else does
Submitted: 30 May 4:24 Modified: 2 Jun 12:20
Reporter: Kevin Ernst Email Updates:
Status: Verified Impact on me:
None 
Category:MySQL Workbench Severity:S2 (Serious)
Version:8.0.29 OS:Linux (Ubuntu 22.04)
Assigned to: CPU Architecture:x86
Tags: ssh fingerprint

[30 May 4:24] Kevin Ernst
Description:
When attempting to connect to a remote host for the first time using the "Standard TCP/IP over SSH" connection method, the remote host's SSH host key fingerprint is displayed as a 40-character SHA1 hash.

I'm not a super-expert on SSH, but this doesn't appear to be a standard format that SSH host key fingerprints are published. I only *happened* to notice that it matched the SSHFP key format[0], and investigated things from there.

In my experience, SSH host key fingerprints are typically reported -- by SSH clients *and* server administrators -- in the two formats produced by `ssh-keygen -l -E`, which are SHA256 (the default) and MD5 (see [1], [2]).

For example:

    for pk in /etc/ssh/*.pub; do echo; ssh-keygen -l -f $pk; ssh-keygen -E md5 -l -f $pk; done 

What MySQL workbench does, instead, is display a SHA1 hash of the binary public key, making it a challenge for users to verify the fingerprint displayed by MySQL Workbench with their server administrator.

As a consequence, most people are going to just click "OK" without actually performing this check, which is critical to all future SSH connections to that host. Yes, the onus is on server administrators to train their users to verify these fingerprints, but having a fingerprint that can't actually be verified makes security worse, because people begin to ignore *any* such notices.

Please note that I've also reproduced this with MySQL Workbench 8.0.42 on Windows, the latest release as of this writing.

[0]: https://web.cs.wpi.edu/~yliu25/sshfp.html
[1]: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh...
[2]: https://docs.gitlab.com/user/gitlab_com/#ssh-host-keys-fingerprints

How to repeat:
Download MySQL workbench 8.0.42 and set up a new profile to connect to a remote host using the "Standard TCP/IP over SSH" connection method.

Fill out all the database connectiond details, then click "Test Connection."

At this point, if the user has never connected to this host before, they're presented with a SHA1 hash of the server's preferred/best host key format. In my case this was ed25519.

For reasons stated above, this fingerprint is difficult / impossible for a casual user to verify with their server administrator.

Separately, on Windows, at least, at certain font sizes and/or resolutions, this hash is truncated, which makes it even harder to notice that it's too long to be an MD5 hash. This is a UI bug.

Suggested fix:
Report the MD5 and SHA256 fingerprints for the preferred key type for the remote host upon first connection.

As a workaround, users who have already verified the host key fingerprint for the remote host via other means can compute the SHA1 sum for a specific key type as follows:

    # for example, for the Ed25519 key type
    awk '{print $1}' /etc/ssh/ssh_host_ed25519.pub | base64 -d | sha1sum

Or, more straightforwardly:

    ssh-keygen -r $HOSTNAME

Since SSHFP records use SHA1 and SHA256 hashes[1], one of the keys output by `ssh-keygen -r` or `ssh-keyscan -D` on newer OpenSSH versions *should* match the fingerprint currently presented by MySQL Workbench, if you ignore the colons.

[1]: https://en.wikipedia.org/wiki/SSHFP_record#Structure
[30 May 4:29] Kevin Ernst
The "Could not connect the SSH Tunnel" dialog box on Linux, version 8.0.29

Attachment: Could not connect the SSH Tunnel - Linux 8.0.29.png (image/png, text), 21.46 KiB.

[30 May 4:32] Kevin Ernst
The "Could not connect the SSH Tunnel" dialog box on Windows, version 8.0.42. Note how the fingerprint is truncated with "…"

Attachment: Could not connect the SSH Tunnel - Windows 8.0.42.png (image/png, text), 14.38 KiB.

[2 Jun 12:20] MySQL Verification Team
Hello Kevin Ernst,

Thank you for the bug report and feedback.
Verified as described.

Regards,
Ashwini Patil