Comments on How to bypass SSH destination host key fingerprint check?
Parent
How to bypass SSH destination host key fingerprint check?
When you first connect to a host, ssh asks you about saving its fingerprint. If you do, on subsequent connections it will check the fingerprint and refuse to connect if it changed.
I get that this is a security measure in case someone tries to impersonate my server.
However, it is also very annoying when using a VPS. I give my public key to the VPS provider, so that it gets spun up with the key "baked in", and I can do a one click reset. But when I do reset, because the new machine is technically a different machine, ssh predictably pouts and complains. However, obviously it's fine for the fingerprint to not match, because I just re-provisioned the server myself a minute ago! But, ssh doesn't know that.
Right now I have to open ~/.ssh/known_hosts, find the line for me host among the many in there, delete it, try again, press yes again... Not the end of the world but a bit tedious.
Isn't there some CLI switch or something that tells SSH to stop whining about fingerprints just this time, and just automatically update known_hosts for me?
Post
The following users marked this post as Works for me:
| User | Comment | Date |
|---|---|---|
| matthewsnyder |
Thread: Works for me Thanks for the great answer! This addresses everything I was confused about. |
Oct 11, 2023 at 17:53 |
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.
0 comment threads