SSH Host Key Changed? Verify Your Rented Server First

An “SSH host key changed” warning appears just after your dedicated server was reinstalled or switched into rescue mode. The timing may explain the change, but it does not verify the machine answering your connection. Keep the warning intact until an independent, trusted source confirms the current host key for the intended server and operating environment.

The operational decision is whether to update an obsolete trust record, correct the destination, or escalate an unexplained identity change. Removing a line from your laptop can restore a connection while concealing the reason it was blocked. Use the sequence below to establish identity first and repair the trust record second.

Determine what changed before changing known_hosts

A host key identifies the SSH service endpoint; it is separate from the user key that authorizes your login. A warning can therefore appear even when your private login key is unchanged. Record the hostname or IP, port, key type, displayed fingerprint, known-hosts file, and offending entry reported by the client.

Match that connection to the rental inventory: server ID, assigned addresses, expected OS, and approved reinstall, rescue, or migration event. An old saved connection profile can target the wrong address. A hostname may also now lead to a different destination after a DNS cutover. Verify the connection actually being attempted, including any SSH alias or jump-host configuration.

These are diagnostic possibilities, not conclusions. A matching provider account entry or familiar operating-system banner alone does not establish which host key the SSH service should present.

Investigate an SSH host key changed warning through an independent path

Use a provider portal reached through its known address and normal account authentication, an authenticated support channel, or a previously verified remote console. Tie the fingerprint to the server ID, network endpoint, key algorithm, and current boot environment. Ask for that specific evidence rather than a general assurance that the server is online.

For a documented provider example, Hetzner’s dedicated-server SSH guidance says installation fingerprints are displayed in Robot and rescue fingerprints are shown when rescue is activated. It also identifies reinstalling and rescue boot as reasons for a change. Check your provider’s actual process; another provider may expose different evidence.

If you can reach the correct running OS through a trusted console, a Linux OpenSSH installation using the conventional Ed25519 host-key location can display its public-key fingerprint with:

ssh-keygen -l -E sha256 -f /etc/ssh/ssh_host_ed25519_key.pub

The command reads a public key and does not rotate it. Use the file configured for the SSH daemon serving the connection. The OpenSSH HostKey configuration reference documents configurable key paths. If the file is absent, another algorithm is used, or the daemon has a custom configuration, have the responsible administrator identify the correct key.

Compare the complete fingerprint for the same key algorithm. Reading a key from an installed disk while booted into rescue does not authenticate the rescue SSH daemon. Likewise, a rescue fingerprint does not establish the installed OS’s identity after normal boot. The remote management guide explains the different console and rescue access paths.

Inspect the local record without deleting it

The following examples assume an OpenSSH client on a Unix-like administrator workstation and a user-managed ~/.ssh/known_hosts file. The hostname is illustrative; substitute the actual lookup identity. For host certificates, centrally managed trust, or a different client, use the corresponding administrator-controlled process.

ssh-keygen -F web01.example.com -f ~/.ssh/known_hosts

For a nondefault port, search the bracketed host-and-port identity instead:

ssh-keygen -F '[web01.example.com]:2222' -f ~/.ssh/known_hosts

The ssh-keygen manual documents lookup with -F, including hashed entries, and removal with -R. Use the file and identity involved in the warning rather than deleting a familiar-looking line from an unrelated file.

Also account for configured identity rules. OpenSSH’s client configuration documentation describes HostKeyAlias and UserKnownHostsFile. Those settings can change where the relevant trust record lives and which name identifies it. If the warning refers to an organizational trust file, coordinate its correction with the owner.

Update only the identity you have verified

1. Preserve the evidence. Save the warning and change authorization. Make a separately named backup of the affected known-hosts file using your normal backup method; do not overwrite an earlier incident copy.
2. Confirm scope. Identify whether the verified change applies to the hostname, IP address, nondefault port, or configured alias. Do not remove unrelated records to silence another warning.
3. Remove the obsolete lookup entry. For a verified replacement using the default port and the user-managed example file, use the command below.

ssh-keygen -R web01.example.com -f ~/.ssh/known_hosts

For the verified nondefault-port example, use '[web01.example.com]:2222' instead. Removal affects all keys associated with that lookup identity; it is not a selective rotation of one algorithm.

Reconnect through the approved client configuration. If it presents a new-key prompt, compare that fingerprint again with the trusted evidence before accepting. A strict policy may require the verified public key to be installed through configuration management instead of an interactive prompt. If another mismatch appears, stop and investigate it. Record why the SSH host key changed, which environment was verified, and who approved the trust update.

Keep the pre-change copy for rollback and audit. Restoring an old file restores old trust records; it does not prove that the endpoint has returned to its previous identity. Do not regenerate server host keys, restart SSH, reboot the host, or reinstall the OS merely to clear a workstation-side warning.

Keep rescue access separate from normal server identity

A temporary recovery environment can legitimately answer on the same public address with different host keys. Preserve the normal OS record before any approved temporary change, and record which key belongs to each environment. On return to normal boot, verify the production key again instead of repeatedly deleting whichever entry blocks access.

For recurring rescue operations, an administrator can design separate lookup identities or known-hosts files with OpenSSH’s supported client settings. Both identities still require verification. Keep temporary rescue configuration out of production automation unless its use is explicitly intended.

Hypothetical example: an operator boots an authorized rescue environment to inspect a rented server. SSH reports a changed key. The operator confirms the rescue fingerprint in the authenticated provider portal and uses an approved rescue-specific trust record. After returning to the installed OS, the original production fingerprint matches the retained record. The useful outcome is two verified identities, not a permanently weakened client configuration.

A key scan collects evidence; it does not establish trust

A key obtained over the same questionable network path cannot independently prove who supplied it. The ssh-keyscan documentation explicitly warns about constructing a known-hosts file from unverified scanned keys. Scanning may help collect candidate keys for comparison; automatically appending them would skip the identity decision.

Keep host-key checking enabled. OpenSSH’s accept-new policy distinguishes new hosts from changed keys; it is not authorization to accept an unexplained replacement. Do not treat a successful password or public-key login as retrospective proof that accepting the endpoint was justified.

Escalate an unexplained identity change with a precise request

Send the provider the server ID, endpoint and port, current boot mode, expected and observed fingerprints with algorithms, first-observed time and timezone, and relevant authorized changes. Ask the provider to confirm the address assignment, current boot environment, and expected host identity through its authenticated process. Never send private SSH keys or passwords as diagnostic evidence.

If provider evidence conflicts with the console or client observation, retain the block and involve the responsible security or infrastructure owner. Use the dedicated-server incident support workflow to preserve one timeline and avoid parallel changes that erase useful evidence.