How do I get Putty to request the remote SHA256 blob as the key fingerprint?

Question

When I ssh from my Mac to a new remote Ubuntu server, it asks me to confirm the key fingerprint as a SHA256 base64 blob.

But when I try to connect with Putty on Windows or Ubuntu to a new remote Ubuntu server, it asks me to confirm the key fingerprint as MD5. I'd much rather confirm using a SHA256 base64 blob.

The Putty documentation for the Key Exchange configuration panel indicates that it is aware of base64 blobs, but the reference is for a setting that assumes I know the fingerprint in advance (manual configuration).

Can I/how do I tell Putty to display the new remote base64 blob key fingerprint instead of the new remote MD5 key fingerprint when connecting to a remote server and the remote fingerprint doesn't match the locally stored previous value?

Answer 1

Be careful to distinguish between blobs and hashes. The public key blob used by OpenSSH, and also PuTTY, is the same for a given key regardless of the hash(es) used. The key blob is stored in base64 by OpenSSH in its xxx_key.pub known_hosts authorized_keys files as applicable, partly because it makes it easier to copy these files and values with techniques like cut-and-paste and (especially older) email that might not handle 'binary' aka '8-bit' data. The 'fingerprint' displayed by OpenSSH (by default, unless you ask for VisualHostKey) used to be MD5(blob) displayed in hex, and now is SHA256(blob) displayed in base64. PuTTY followed OpenSSH's original lead but (as of 0.67) not the update.

You can request an enhancement following the instructions in the manual and duplicated at http://www.chiark.greenend.org.uk/~sgtatham/putty/feedback.html#feedback-features . Or it's open source; you can do the change yourself, and submit it back to them (see B.5 just after B.4). The 'fingerprint' code is currently in one place in sshdsa.c and two in sshrsa.c, but I see on the website the next release will include ecdsa and ed25519 keys, which presumably means at least one and maybe several new place(s) to create a fingerprint. To be consistent als allow base64 of a hash (not just of a blob as now) in validate_manual_key in misc.c. That's easy if you change to SHA256-b64 unconditionally and never do MD5-hex; for a submission or feature usable by other people this probably has to be configurable and/or interactive, either of which looks a good bit harder.

For Windows, I can see one very clunky workaround. Use plink to connect to the host and accept the new key, putting it in the registry. (If there was an old key, save it first.) Get the new key from the registry (in pieces), build the blob, hash and base64 it and display for confirmation. If not confirmed, delete the key from the registry (and restore any prior one).

For Unix, a slightly less clunky way is to use ssh with StrictHostKeyChecking=no to accept the new key and put the base64 blob in known_hosts, or use ssh-keyscan to get the base64 blob directly. Then base64-decode, hash, base64-encode (the hash) and display; if bad after ssh forced accept, delete the bad entry from known_hosts; if good after ssh-keyscan, add the good entry. OpenSSL can conveniently do both bits of the calculation:

awk <.ssh/known_hosts '$1~/thehostname/{print $3}' |openssl base64 -d |openssl sha256 |openssl base64

but if you don't have OpenSSL it should be easy to combine other base64 and sha256 tools.