Fix 'Host key verification failed' on a relaunched GPU

The warning below usually means a new launch landed on an IP address that an earlier machine used, and SSH is doing its job by refusing to talk to a host whose key no longer matches the one it remembers.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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:...
Please contact your system administrator.
Add correct host key in /home/you/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/you/.ssh/known_hosts:12
Host key for 203.0.113.7 has changed and you have requested strict checking.
Host key verification failed.

The line that starts with Offending names the file and line number of the stale entry. The text comes from the OpenSSH source, sshconnect.c and sshconnect2.c, checked on 1 October 2026.

A relaunch reused an IP address you connected to before

Every launch is a new machine with a new IP address, and providers reuse addresses. A new machine has its own SSH host key, while your known_hosts file still holds the old machine's key for that address, so SSH sees a mismatch. After a relaunch that is expected. Ask one question first: did you launch a new deployment since you last connected to this address? If yes, remove the old entry:

ssh-keygen -R YOUR_VM_IP

It prints which line it removed and keeps a backup of the file, per the ssh-keygen manual and its source:

# Host YOUR_VM_IP found: line 12
/home/you/.ssh/known_hosts updated.
Original contents retained as /home/you/.ssh/known_hosts.old

Connect again and answer yes to the prompt about the new key. On Windows, run it in PowerShell, where the file is in C:\Users\YOU\.ssh. The command also finds entries that SSH stored in hashed form, which the manual calls out as a use for -R. scp and rsync run over ssh, and VS Code Remote-SSH needs an OpenSSH client, so one ssh-keygen -R clears the error for all of them.

The entry is stored under a different name or port

If ssh-keygen -R prints Host YOUR_VM_IP not found, the stale key is stored under another name. Entries for a non-standard port are written as the host in square brackets followed by the port, as the sshd manual describes. Vast.ai, which is dashboard only and labelled Testing Only, uses a proxy port shown on the deployment, and the VM providers use 22:

ssh-keygen -R "[YOUR_VM_IP]:PORT"

If you connect through an alias such as gpu, SSH records the real address from HostName, unless the config sets HostKeyAlias, per the ssh_config manual. If the Offending line points at a file other than ~/.ssh/known_hosts, add -f with that path. ssh-keygen -F YOUR_VM_IP looks an entry up first.

Only the last line appears, with no warning above it

A script or retry loop that connects with BatchMode cannot answer the question SSH asks about a new host, because that option disables host key confirmation requests. With StrictHostKeyChecking yes, an unknown host fails outright. Both end in Host key verification failed. with no mismatch banner above it. Connect once by hand, or accept new hosts and still refuse changed ones:

ssh -o StrictHostKeyChecking=accept-new ubuntu@YOUR_VM_IP

Why I do not turn host key checking off

The shortcut people reach for is StrictHostKeyChecking no, and it is a bad habit on a rented GPU for two reasons. The ssh_config manual says no lets SSH add new keys and carry on with hosts whose keys changed, subject to some restrictions. Those restrictions are in the source. When a key has changed and checking is off, OpenSSH disables password and keyboard-interactive login, agent forwarding, X11 forwarding and port forwarding for that connection, with the message Port forwarding is disabled to avoid man-in-the-middle attacks. So the shortcut breaks the ssh -N -L tunnels that most GPU work depends on, and it silences the one check that would catch a real impostor.

accept-new is the setting I recommend. The manual says it adds new host keys automatically but does not permit connections to hosts with changed keys. Connecting to a machine you launched minutes ago is a leap of trust either way, so skipping the prompt costs little, and a changed key on a known address still stops you. It does not clear a reused address, so ssh-keygen -R is still the fix. A separate file keeps short-lived machines out of your main one:

Host gpu
    HostName YOUR_VM_IP
    User ubuntu
    StrictHostKeyChecking accept-new
    UserKnownHostsFile ~/.ssh/known_hosts_deploygpu

Every entry in that file goes stale when you Stop, so you can delete the whole file between sessions, or run ssh-keygen -R YOUR_VM_IP -f ~/.ssh/known_hosts_deploygpu for one address.

The key changed and you did not relaunch

If you have launched nothing new since you last connected to this address, do not clear the entry and do not switch checking off. Check the deployments list in the dashboard. A machine the provider lost disappears from that list without an email, and its old address may now belong to someone else. If the deployment is gone, the connection refused page covers it. If it is listed, the address matches and you did not relaunch, that is the case for support.

When to contact support

Email support@deploygpu.ai when the warning appears on a deployment that is still listed, with an unchanged address and no relaunch. Include the full warning text, the provider, the instance ID from the dashboard and the time you last connected successfully. The contact page is the other way in. The SSH guide covers keys and config files, and permission denied covers the error that can follow this one.