How to fix an SSH host key error after redeploying your Cloud Server

After redeploying your Cloud Server, your SSH client may warn you that the host key has changed. This applies to all unmanaged Cloud Server (VPS) products running Linux, and covers macOS/Linux Terminal (OpenSSH), Windows PowerShell (built-in OpenSSH), and PuTTY on Windows. Here's how to fix it safely.

This warning can also appear after any action that regenerates your server's SSH host keys, not just a redeploy.

This is expected behavior after a redeploy, not a bug or a security incident on our side.

• Example error

  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  It is also possible that a host key has just been changed.
  The fingerprint for the ED25519 key sent by the remote host is
  SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
  Please contact your system administrator.
  Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
  Remove offending key in /home/user/.ssh/known_hosts:3
  Host key for <ip-or-hostname> has changed and you have requested strict checking.
  Host key verification failed.

• Why this happens

  Every SSH server generates a unique set of host keys the first time it starts. When you connect, your SSH client saves a fingerprint of that key so it can verify on every future connection that it's still talking to the same server, and not an impostor. Terminal and PowerShell's OpenSSH store this in a known_hosts file. PuTTY stores it in the Windows Registry.

  When you redeploy your Cloud Server, the operating system is reinstalled from scratch, including its SSH host keys. Your server keeps the same IP address, but now presents a brand-new fingerprint. Your SSH client compares this against the old, saved fingerprint, sees a mismatch, and correctly assumes this could be a man-in-the-middle attack. That's why you get a warning instead of a silent connection.

Step-by-step fix

• macOS / Linux (Terminal)

  1. Open Terminal.
  2. Remove the old, stale entry from your known_hosts file:

     ssh-keygen -R <your-server-ip>

  If you normally connect using a hostname (for example, via rDNS), also run:

     ssh-keygen -R <your-hostname>

  3. Reconnect to your server:

     ssh <user>@<your-server-ip>

  4. Your client displays the new fingerprint and asks you to confirm it. Type yes to accept and continue.

• Windows (PowerShell / OpenSSH)

  1. Open PowerShell.
  2. Try removing the stale entry directly:

     ssh-keygen -R <your-server-ip>

  3. If your OpenSSH version doesn't support -R, open the file manually instead:

     notepad $env:USERPROFILE\.ssh\known_hosts

  Find the line starting with your server's IP address or hostname, delete that line, then save and close the file. 4. Reconnect to your server:

     ssh <user>@<your-server-ip>

  5. When prompted to confirm the new fingerprint, type yes to accept and continue.

• Windows (PuTTY)

  Option A: accept it directly in PuTTY (simplest)

  1. Connect to your server in PuTTY as usual.
  2. When the "WARNING - POTENTIAL SECURITY BREACH" dialog appears showing the new fingerprint, select Yes to accept it and continue connecting. PuTTY remembers the new fingerprint going forward.

  Option B: remove the old entry manually first

  1. Open the Windows Registry Editor (regedit).
  2. Navigate to:

     HKEY_CURRENT_USER\SOFTWARE\SimonTatham\PuTTY\SshHostKeys

  3. Find the entry matching your server's IP address or hostname, listed under a key like rsa2@22:<ip>, and delete it.
  4. Close the Registry Editor and reconnect in PuTTY. You're prompted to accept the new fingerprint as if connecting for the first time. Select Yes.

Good to know

Only accept a new fingerprint if you know why it changed.
If you redeployed or reinstalled the server yourself, it's safe to accept. If this warning appears unexpectedly, without you having made any changes, treat it as a potential security concern and verify before connecting.

• Important notes

  • Do not disable host key checking entirely, for example with StrictHostKeyChecking=no in Terminal or PowerShell OpenSSH. This removes a real security protection, not just an inconvenience.
     
  • Editing the Windows Registry carries its own risk if done incorrectly outside the SshHostKeys path. Only modify the entry described above.
     
  • This fix only needs to be done once per redeploy. Once you accept the new fingerprint, it's saved, and future connections work normally until the next redeploy.

• Troubleshooting

  If the fix above doesn't work, check these common causes:
   

  • "Permission denied" or "Access denied" after fixing the host key 
    Verify your username and password or SSH key. A redeploy resets your server to its default OS credentials.
     
  • Terminal or PowerShell: still getting a mismatch warning after removing the entry 
    Some setups have more than one relevant file, such as a system-wide known_hosts in addition to your user one, or a different path than $env:USERPROFILE\.ssh\known_hosts. Confirm you edited the file your client actually uses.
     
  • PuTTY: the warning keeps reappearing 
    Confirm you accepted the fingerprint (selected Yes, not No or Cancel), or that you removed the correct registry entry.
     
  • Can't connect at all 
    Confirm the server is powered on and not blocked by a firewall or IP access rule.

Related articles:

• Redeploy your Cloud Server to reinstall from scratch
• IP Access Rules (firewall) on your VPS