Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

75%
+4 −0
Q&A How to bypass SSH destination host key fingerprint check?

I'm going to assume that you're using OpenSSH, since that is probably the most common SSH implementation on present-day *nix systems. The easiest is probably to use ssh-keygen -R to delete all kno...

posted 1y ago by Canina‭

Answer
#1: Initial revision by user avatar Canina‭ · 2023-10-11T17:32:31Z (about 1 year ago)
I'm going to assume that you're using OpenSSH, since that is probably the most common SSH implementation on present-day \*nix systems.

**The easiest is probably** to use `ssh-keygen -R` to delete all known host keys for a given host name. So if you have just reprovisioned `vps1.example.com` and it therefore has new host keys that your local SSH client knows nothing about, you can do:

    $ ssh-keygen -R vps1.example.com

which will cause all known host keys for that particular host name to be removed. In contrast to editing `~/.ssh/known_hosts` manually, `ssh-keygen -R` also works with hashed host names.

The next time you `ssh vps1.example.com` it will be treated as an unknown host by `ssh`, and unless you have set `StrictHostKeyChecking yes` the connection will be allowed to proceed (after a prompt if `ask`, and after a warning message if `no`).

**If you want to, after** doing `ssh-keygen -R`, you can use `ssh-keyscan` to obtain all current public key(s) for the host, and add them to `~/.ssh/known_hosts` by for example:

    $ ssh-keyscan vps1.example.com >>~/.ssh/known_hosts

This should *only* be done if you trust the link or are able to otherwise meaningfully verify the thus-obtained host keys; but that's an issue for *any* kind of first connection with SSH due to its trust-on-first-use model.

Take care to use `>>` and not `>` because you probably don't want to overwrite your known hosts file, only add to it.

If your VPS provider offers remote console access (as opposed to SSH access into the VPS' operating system), you can log in that way and compare the output from the two commands below:

    client:~$ ssh-keygen -F vps1.example.com | ssh-keygen -l -f -
    vps1:~$ cat /etc/ssh/ssh_host_*_key.pub | ssh-keygen -l -f -

Because of ordering and key comments the output of the two might not be *identical*, so you can't necessarily just `diff` the output directly; but if they do not show the same key sizes and fingerprints for each respective key type, then someone is doing something fishy somewhere *or* you mistyped the host name.