OpenSSH now uses a SHA-256 fingerprint; we should support it. See also T2075
Description
Details
- Version
- 2.1
Revisions and Commits
Related Objects
Event Timeline
I generalized the ssh key fingerprinting code so that we can select the digest algorithm.
Now I'm a little unsure how to proceed. We can easily include both the MD5 and the SHA256 digest
in the sshcontrol file. But what shall we use for expanding '%F' in key descriptions? If we
transition too soon or too late, users might not recognize their key. Displaying both surely is
too verbose. We could make it configurable, or at least a compile time option.
What do you think?
6.7 still shows MD5 fingerprints thus switching won't be easy. Does the SHA-256
fingerprint use Base32? If that is the case it might be a serious UX problem
because most people are used to look for colon separated hex digits.
It seems to be base64:
% ssh -V
OpenSSH_7.1p1 Debian-3, OpenSSL 1.0.2e 3 Dec 2015
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E md5 -q
playfair.gnupg.org RSA MD5:cc:dd:46:8e:ef:3d:d9:34:97:f8:b8:5a:59:51:80:4a
% ssh-keygen -l -f .ssh/known_hosts -F playfair.gnupg.org -E sha256 -q
playfair.gnupg.org RSA SHA256:KCh034SD0rMKqCkJbdH2wx354s1278tqt9F+xb5cidg
It is base64 trimmed the last '='.
Introducing new specifier, say %f, would be good, while keeping %F as is.
%f includes the hash algorithm string as SSH does.
That fingerprint looks more like gibberish than something which should be
compared by the user. In that regard a SHA-1 fingerprint looks much more
serious and IMHO will be more secure than a base-64 fingerprint where you have
to explain that the users also need to match the case - if they are at all able
to compare that fingerprint.
We should take this to the mailing list.
Adding %f does not help much because it is only used internally. I would be in
favor of adding an ssh-key-mode option so that the user can select the hash algo
and the output format.