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
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