SSH host key fingerprints do not match


tl;dr: I copied the text in the Host Keys section of the panel into my .ssh/known_hosts file, but the server identifies itself by a different key. Email support doesn’t seem to understand.

Long version: I’m an experienced Linux user and I use SSH every day at work. I’m by no means a security or administration expert, but I know my way around.

I bought a DreamHost VPS the other day and added a user to it in the panel (seems kind of odd how user names aren’t unique per instance – I’m not missing anything, right?) Ran ‘ssh’ and got the usual “The authenticity of host … can’t be established”. Oh yeah, I should add the server’s public key to .ssh/known_hosts.

So I go visit the panel and I see that there’s an “SSH Keys” option under Users. Great! And it even has the known_hosts file syntax there so I don’t have to bother comparing fingerprints.

Except it doesn’t work. Text copied into known_hosts, tried again, got the REMOTE HOST IDENTIFICATION HAS CHANGED message.

Okay… I’m pretty sure this is a configuration error, so I turn off host key checking (-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no) and confirm that I can, actually, log in to the server. But I’d rather, you know, check the fingerprint. Even if I’m 99.8% sure I’m not being MITM’d, it’s just good sense.

I contacted support and got an email back pointing me to All the proposed “solutions” on that page just deal with removing the wrong key(s) from .ssh/known_hosts; they don’t address verifying the correct key. (The page even has a dramatic message about this making you vulnerable to MITM attacks.) So I responded to clarify my issue and got another email back saying to run ssh-keygen -R $hostname, which is the same thing the first guy proposed.

So I’m operating on the assumption that email support is, let’s put this nicely, not completely understanding my issue. But, for now, I’m willing to keep trying. How do I get in touch with someone who can tell me what to put in .ssh/known_hosts?


I had the same question a while back. Here was the response:

Thanks for writing back in. I’d be happy to shed some light on this. The
fingerprint you see in the error is actually valid. What’s happening is
that because you are using OpenSSH_6.9p, it displays the fingerprint in a
base64’d SHA256 hash as opposed to an MD5 hash as displayed in the panel.
This started with OpenSSH 6.8. I’ve verified the hash directly on the
server, and it does match up with what you’re seeing in the verification

root@psXXXXX:/etc/ssh# awk ‘{print $2}’ | base64 -d
| sha256sum -b | awk ‘{print $1}’ | xxd -r -p | base64

You can also force the fingerprint verification to use an MD5 so you can
verify it against what’s in the panel by using the following flag when

-o FingerprintHash=md5

If you have any additional questions or concerns, please feel free to let
us know.


Ah! Excellent. I set the FingerprintHash to md5 and was able to compare it with the fingerprint in the panel.

To elaborate, for posterity, in the panel, there are three MD5 fingerprints: RSA, DSA, and ECDSA. But the known_hosts text only contains the DSA and ECDSA fingerprints. Since I’m using RSA for authentication, I got the RSA one from the server, and since I assumed all three keys would be in known_hosts (didn’t check) it didn’t occur to me that the RSA fingerprint might actually match.

Thanks Scott.