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, the new key most likely belongs to your server. We still recommend comparing its fingerprint first, as shown in Check the new host key. Then 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, don't accept the new key until you have compared the fingerprint, 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. You run both commands on your own computer, not on the server.

Before you start, compare the new key's fingerprint as shown in Check the new host key. If nobody on your account made one of the changes above, don't skip this check.

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.

Before you click Accept, we recommend comparing the SHA256 value in the alert with the server's fingerprint, as shown in Check the new host key. 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 don't connect until you have compared the values.

Compare the fingerprint before you accept a new key. We recommend it after any of the changes above, and you need it when nobody on your account made one of them. 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. Other entries, such as a stop and a start, only show when the server restarted. They don't show that the password was changed and they don't confirm the new key.

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.

If the two values match, the new key belongs to your server. Remove the old key as shown in Fix the warning in PowerShell or Terminal.

If they don't match, or you can't compare them and nobody on your account made a change, 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. Reinstalling erases the existing server contents. It isn't required to update the saved host key 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.

You also see the 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. As with the other fixes, compare the fingerprint first as shown in Check the new host key. 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: