MD5 Fingerprint for Host Key verification using SFTP doesn't match OpenSSH MD5 output

[hv15]

Hi guys,

So I'd like to use Cyberduck to copy over some files to a server using SFTP. When I connect I get a request to allow/disallow the connection based upon the validity of the fingerprint of host key certificate. This is given to me as 16:92:5d:84:cb:94:03:3f:c6:5e:36:3b:20:dd:36:b5. This does not match what OpenSSH gives me!

On the remote system, I can see the fingerprint hash is:

$ ssh-keygen -L -E md5 -f /etc/ssh/ssh_host_ed25519_key-cert.pub
/etc/ssh/ssh_host_ed25519_key-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com host certificate
        Public key: ED25519-CERT MD5:7b:85:31:77:83:87:38:c9:72:1c:44:e2:ac:0c:20:55
        Signing CA: ED25519 MD5:b4:c6:ed:f1:95:dc:b0:76:c2:e0:7f:9c:8a:3f:4d:57 (using ssh-ed25519)
        Key ID: "9e73f821e7a680a14611541dd1617693b6e9c10f97732f9794ae62cfa2d9cf55"
        Serial: 10659949471223322586
        Valid: from 2024-04-12T11:58:29 to 2034-04-10T11:58:59
        Principals:
                machine001
                machine001.private.lan
        Critical Options: (none)
        Extensions: (none)

I checked the implementation of SSHj and believe that this should return the same hash of the fingerprint as above. The debug output of Cyberduck seems to also show that it takes this value as SSHj computes it, but already in the logs the hash is different.

I found a previous issue #12944 that has a similar premise but the answer doesn't clear this up for me.

Why is there a difference?

Cheers,
Hans

[ylangisc]

Normally you have multiple keys/certs in /etc/ssh/. Depending on the handshake between client and server the one matching the negotiated algorithms is taken. I guess that ed25519 was not the chosen algorithm and thus another one was taken.

[hv15]

Hi, yes I had thought this could be the case as well, but only one host key is defined in /etc/ssh/sshd_config:

HostCertificate /etc/ssh/ssh_host_ed25519_key-cert.pub

If I check the verbose output of ssh it looks to be reading/sending the same key:

$ ssh -v -o FingerprintHash=md5 machine001
debug1: OpenSSH_10.2p1, OpenSSL 3.6.1 27 Jan 2026
... omitted ...
debug1: Local version string SSH-2.0-OpenSSH_10.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.6
debug1: compat_banner: match: OpenSSH_9.6 pat OpenSSH* compat 0x04000000
... omitted ...
debug1: Server host certificate: ssh-ed25519-cert-v01@openssh.com MD5:7b:85:31:77:83:87:38:c9:72:1c:44:e2:ac:0c:20:55, serial 10659949471223322586 ID "9e73f821e7a680a14611541dd1617693b6e9c10f97732f9794ae62cfa2d9cf55" CA ssh-ed25519 MD5:b4:c6:ed:f1:95:dc:b0:76:c2:e0:7f:9c:8a:3f:4d:57 valid from 2024-04-12T11:58:29 to 2034-04-10T11:58:59

[ylangisc]

I think I can clarify why the fingerprints differ.

Root cause

The discrepancy isn't caused by algorithm negotiation picking a different key. The actual cause probably is that Cyberduck/SSHj and OpenSSH are hashing different data:

• OpenSSH (ssh-keygen -L -E md5, and ssh -v for the "Server host certificate" line) computes the MD5 fingerprint over the entire certificate blob — nonce, embedded public key, serial, key ID, principals, validity period, critical options, extensions, and the CA signature. This is why the type is shown as ED25519-CERT rather than plain ED25519.
• Cyberduck (via SSHj) computes the fingerprint over only the embedded raw Ed25519 public key, stripped of all the certificate-specific fields.

Since a certificate's serialized blob is a superset of the raw public key blob, hashing the two produces completely different MD5 values — even though it's provably the same key/certificate on the wire.

Why this is hard to verify manually

Extracting just the raw public key from a -cert.pub file to hash it separately isn't a one-liner with standard tools. It requires manually parsing the SSH wire format (a sequence of 4-byte length-prefixed fields: cert type, nonce, public key, serial, principals, ...), pulling out the public-key field, and re-wrapping it as a plain ssh-ed25519 key blob before hashing. There's no ssh-keygen/openssl flag that does this directly — it needs a small script (Python, or a handful of chained openssl/dd/xxd commands) to reconstruct the plain-key blob first.

Effect on known_hosts matching

I suspect this also explains a secondary, user-facing symptom: Cyberduck checks the local known_hosts file before displaying the fingerprint prompt. If the correct (certificate-based) fingerprint for this host is already present in known_hosts — e.g. added by a previous OpenSSH connection — Cyberduck likely fails to match it, because it's comparing against a fingerprint computed a different way, and prompts the user again as if the host were unknown/changed.

I don't have a test environment with a host certificate set up right now to confirm this known_hosts behavior directly, but if the fingerprint computation is indeed inconsistent between SSHj and OpenSSH for certificate types, this would need to be fixed on the SSHj/Cyberduck side — i.e. computing the certificate fingerprint the same way OpenSSH does (over the full certificate blob) instead of over the embedded public key alone.

[ylangisc]

I did some testing on a VM configured with a certificate-based host key and have to partially revise my comment above. It's rather Cyberduck calculating the fingerprint from the entire certificate than OpenSSH. That's the reason you see a differing fingerprint in Cyberduck. We need to extract the public key from the certificate before doing the calculation of the fingerprint.

[hv15]

OK, I think I understand and also found how to compute that fingerprint:

$ cut -d' ' -f2 /etc/ssh/ssh_host_ed25519_key-cert.pub | base64 -d | md5sum
16925d84cb94033fc65e363b20dd36b5  -

or if colons are desired:

$ cut -d' ' -f2 /etc/ssh/ssh_host_ed25519_key-cert.pub | base64 -d | openssl md5 -c
MD5(stdin)= 16:92:5d:84:cb:94:03:3f:c6:5e:36:3b:20:dd:36:b5

Thanks for your help!