Fix SSH host key verification failed error

SSH stops with WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! and ends with Host key verification failed when the server sends a different host key from the one your computer saved.

On a LumaDock VPS this is expected after a few actions in the client area: changing the server password, changing the hostname, restoring a backup or reinstalling the server. When the server starts after one of these changes, it creates new SSH host keys. A new host key on its own doesn't mean the server was reinstalled or that your files were deleted.

If you or someone on your account made one of these changes just before the warning appeared, run ssh-keygen -R YOUR.VPS.IP on your computer, with your server's IP address in place of YOUR.VPS.IP, and connect again. In PuTTY, click Accept in the security alert instead, as shown in Fix the warning in PuTTY. If nobody made a change, follow Check the new host key first, because the same warning appears when someone intercepts the connection.

This fix works in PowerShell or Command Prompt on Windows and in Terminal on macOS and Linux. Use it only if you can explain the change, as described above. You run both commands on your own computer, not on the server.

Step 1: Remove the old host key.
Run this on your computer:

SSH removes the old key from known_hosts, the file where it remembers servers, and prints the line number it found. It keeps a copy of the previous file as known_hosts.old. If you connect with a domain name instead of an IP address, run the command with the domain name.

Step 2: Connect to the server again.
Run this on your computer:

SSH now treats the server as new and asks Are you sure you want to continue connecting. Type yes and press Enter. SSH saves the new key, and you log in with your root password or SSH key as usual. If you changed the password, use the new one.

After one of these changes, PuTTY shows a security alert with WARNING - POTENTIAL SECURITY BREACH! when you connect. PuTTY keeps its own list of host keys, so ssh-keygen -R doesn't change anything in PuTTY.

If you or someone on your account made the change, click Accept. PuTTY saves the new key and connects. Older versions of PuTTY show Yes instead of Accept. If nobody made a change, click Cancel and check the server first as shown in Check the new host key.

If nobody on your account changed the password or hostname, restored a backup or reinstalled the server, check the server before you accept the new key. The checks use the LumaDock client area.

Step 1: Look for a recent change in Task History.
In the client area, go to My servers and click Manage next to the server with the IP address you connect to. In the Service Management menu, open Task History. A reinstall shows up as four entries close together: Stop, Destroy, Resize and Start, as in the picture below. The other changes are applied when the server starts, so look for stop and start entries from around the time the warning began.

Step 2: Open the server console.
In the same Service Management menu, open noVNC Console, the server's own screen in your browser. It works even when SSH doesn't, but you still log in with the server's own username and password, for example root.

Step 3: Compare the host key fingerprint.
Find the key type in the warning line The fingerprint for the ... key sent by the remote host is. For an ED25519 key, run this in the console:

For an ECDSA key, use /etc/ssh/ssh_host_ecdsa_key.pub. For an RSA key, use /etc/ssh/ssh_host_rsa_key.pub. Compare the full SHA256 value the command prints with the one in the warning. The PuTTY alert shows the same SHA256 value.

The new key is safe to accept when the two values match and you can explain the change: Task History shows one of the changes above, or you used this IP address before for a different server. Then remove the old key as shown in Fix the warning in PowerShell or Terminal.

In every other case, don't log in over SSH. Open a support ticket and include the server's name and the full warning. Never send your password or private SSH key in a ticket.

Accepting the new host key only lets SSH continue to the login. It doesn't change your password or your SSH key.

If SSH says Permission denied or the noVNC console says Login incorrect, check that you use the right username, root on a Linux VPS, and the current Server Password from the Information block on the server's page. A password change in the client area doesn't turn on password login over SSH if it was turned off inside the server, so in that case log in with your SSH key.

If the new password doesn't work in the noVNC console either, open a support ticket. Say which change you made in the client area and include both error messages. Don't reinstall the server to fix this: a reinstall erases everything on it and doesn't stop the host key warning.

SSH shows WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! when the server's host key doesn't match the key saved on your computer. The host key works like an ID for the server. SSH saves it in known_hosts the first time you connect and checks it on every connection after that. On Windows, the file is C:\Users\YOUR-USER\.ssh\known_hosts; on macOS and Linux it is ~/.ssh/known_hosts.

New host keys after a password change, hostname change, backup restore or reinstall make the check fail. A changed key can also mean that someone is intercepting the connection (a man-in-the-middle attack). SSH can't tell which of the two happened, so it stops and leaves the decision to you.

You also see this warning when you connect to an IP address you used before for a different server.

Two lines of the warning tell you what changed:

The two lines can name different key types, as in this example. The fix is the same.

Don't set StrictHostKeyChecking no to make the warning go away. SSH would then connect to a server whose key changed without stopping you, and it still blocks password login to that server, so the setting doesn't fix the problem.

ssh-keygen -R YOUR.VPS.IP reports that the host was not found when the old key is saved under a different name. The Offending ... key in line of the warning shows the file and the line that hold the old key.

Custom SSH port.
If SSH on your server listens on a port other than 22, known_hosts saves the server together with its port. Put the IP address and the port in brackets inside quotes. Replace 2222 with your port:

Domain name.
If you connect with a domain name, run the command with that name instead of the IP address:

If neither case applies, delete the line yourself as shown in Remove the old host key by hand.

Remove the old host key by hand only if ssh-keygen -R isn't available or keeps reporting that the host was not found, and only after a change you can explain or a fingerprint check. Open the file named in the Offending ... key in line of the warning and delete only the line with the number at the end of that line, for example 9.

Windows.
Open the file in Notepad from PowerShell, delete line 9 (it starts with your server's IP address or name) and save the file:

Linux.
This command deletes line 9. Replace 9 with your line number:

If your computer runs Ubuntu or Debian, the lines in known_hosts start with |1| instead of an IP address because the file is hashed, so the line number is the only way to find the right one.

macOS.
macOS needs an empty pair of quotes after -i. Replace 9 with your line number: