A “REMOTE HOST IDENTIFICATION HAS CHANGED” warning does not, by itself, prove that two Droplets share SSH host keys. First verify which server answered and compare its host-key fingerprint with the identity you expect; then decide whether to update a stale client record or rotate a genuinely duplicated server key.
SSH host keys identify a server to connecting clients. They are separate from your private login key and from the user public keys in authorized_keys, so a host-key repair should not remove or replace those login credentials.
Understand what the warning tells you
When you connect to a host for the first time, SSH records its presented host public key in your client’s known_hosts file. On a later connection, the client compares the newly presented key with that saved record. If they differ, it warns you because the endpoint’s identity has changed from the client’s point of view.
That change can be expected. For example, a Droplet may have been destroyed and another created with the same IP address. The new server has its own host key, while your computer still has the old server’s key recorded for that address. DigitalOcean describes this IP-reuse situation in its guide to connecting to a Droplet with OpenSSH: the warning can appear after one Droplet is destroyed and a new one is created and contacted.
A different possibility is that two servers have been configured with the same host private keys, so clients see the same host public key from both. That is a server-side identity problem, but the warning alone does not establish that it has happened. Nor does a warning necessarily tell you that the connection is safe to accept: it is a reason to stop, check, and identify the endpoint before proceeding.
The key distinction is where the mismatch exists. A stale record means one client remembers an old identity for a host name or IP. Duplicated server keys mean multiple servers actually present the same identity. Removing an entry from known_hosts changes only your client’s saved record; it does not change the keys on either Droplet.
Identify stale client records first
Start with the exact host name or IP in your SSH command, not just the Droplet’s display name in the control panel. Check the warning text for the address and port involved. If you connect through an alias, proxy, or non-default SSH port, the relevant saved record may use that connection name or a bracketed host-and-port form rather than the plain IP.
Ask what changed recently. Was the Droplet rebuilt, replaced, restored from an image, or assigned an address previously used by another Droplet? Did you change a DNS record or start connecting through a different route? A recent replacement that reused the same address makes a stale client record a reasonable possibility. It does not prove the new endpoint is the intended one, so confirm the IP currently assigned to the Droplet in DigitalOcean’s control panel and verify the offered fingerprint separately.
If one laptop reports the warning but another trusted client does not, that can point towards a local saved record, though it is not conclusive: the clients may be reaching different endpoints or have different DNS and proxy settings. Likewise, if two Droplets appear to return the same fingerprint, compare the public host-key fingerprints through trusted access before deciding that the keys are duplicated.
Keep a short record while diagnosing: the hostname or IP used, the port if it is not the default, the warning’s fingerprint and key type, the Droplet you intend to reach, and any recent rebuild or address change. This makes it less likely that you will remove a record for the wrong host. The same habit of separating client-side and server-side causes is useful in other persistent-stream faults, such as the checks in our guide to a YouTube stream that freezes despite an excellent connection.
Check the presented fingerprint safely
A fingerprint is a short representation of a public key. You can compare it without exposing the corresponding private key. Do not paste, email, or post files such as /etc/ssh/ssh_host_ed25519_key or ssh_host_rsa_key: those are server private keys and must remain secret. The .pub files contain public material suitable for fingerprint comparison, but share them only as needed.
The safest check uses an independent, trusted route to the intended Droplet. If you can reach its DigitalOcean console, inspect the server’s public host-key files and calculate their fingerprints there. DigitalOcean’s SSH troubleshooting guide identifies /etc/ssh as the usual place to check for host-key files when investigating missing keys. The exact key types and configured paths can vary, so inspect the files actually used by that system rather than assuming every installation is identical.
From a trusted console, a public key can be fingerprinted with OpenSSH’s ssh-keygen -lf command followed by the public-key filename, for example sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. Compare the output with the fingerprint shown by the SSH client, ensuring you compare the same key type. A server may offer more than one host-key type, and matching one fingerprint does not mean every offered key is identical.
You can also compare the fingerprints of the public host keys on two Droplets using trusted administrative access to each. If both servers’ corresponding public keys have the same fingerprint, that is evidence of a shared host identity. If the fingerprints differ but one client warns, investigate the client’s saved entry, the endpoint, or the connection path instead of rotating keys automatically.
Do not treat accepting a new key at the prompt as verification. It only tells the client to save the offered identity. If you cannot verify the fingerprint through a trusted console or another independent channel, pause the connection and restore a trustworthy route to the server before accepting it.
Distinguish a rebuild from duplicated identity
A rebuild or replacement commonly changes the server key while leaving a client’s old entry behind. In that case, the new Droplet can have a distinct, legitimate identity even though your client complains. Confirm the current assignment of the address and the new host fingerprint; if both match the intended replacement, the remedy is to remove the stale entry from the affected client and reconnect with verification.
For suspected duplication, compare the same host-key type across the affected Droplets. If each Droplet’s corresponding public host key has the same fingerprint, then the servers are presenting the same key identity. This is materially different from a single client remembering an old key for an address. DigitalOcean’s documentation supports generating host keys when they are missing, but it does not establish how often duplicated keys occur or prove a particular image or provisioning workflow caused them.
If the evidence points to a cloned image or automated provisioning process, review how that image was prepared and what runs on first boot. DigitalOcean explains that cloud-init can consume user data during a Droplet’s first boot to configure the server in its cloud-init documentation. Treat image preparation and first-boot key generation as diagnostic leads, not as a proven cause in your case.
The table summarises what each repair changes and the main caution:
| Question | Client-side known_hosts cleanup |
Server-side host-key rotation |
|---|---|---|
| What is wrong? | A client has a saved key for a previous server at this name or address. | Multiple servers present the same host public key, or an affected server’s identity must be replaced. |
| Where do you act? | On each affected SSH client. | On the affected Droplet through trusted access or a recovery route. |
| What changes? | The client’s stored trust record; server keys stay as they are. | The server identity; clients must verify and learn the new fingerprint. |
| Main caution | Confirm the endpoint before trusting its new key. | Preserve recovery access and change host keys, not user login keys. |
Correct a confirmed stale known_hosts entry
Use this remedy only after confirming that the address now belongs to the intended Droplet and that the fingerprint it presents is the expected one. On the affected client, remove the entry for the IP with:
ssh-keygen -R <droplet-ip>
Replace the placeholder with the actual IP address. DigitalOcean documents this approach for the case where a replacement Droplet inherits an old IP address. If you connect by a hostname, an alias, or a non-default port, use the same host notation that appears in the relevant known_hosts record. DigitalOcean’s Droplet rebuild guidance also shows using ssh-keygen -f <known_hosts-file> -R <droplet-ip> when specifying a particular known-hosts file.
This command removes the matching saved record from the client; it does not repair a server that has a duplicated host key. It may also be necessary to remove or update the entry on other clients that remember the old identity. Do not delete the whole known_hosts file as a shortcut: that discards trust records for unrelated systems and makes it harder to notice unexpected identity changes elsewhere.
Reconnect only after the identity check. SSH should present the new key because the prior entry is gone. Compare the new fingerprint with the one obtained through the trusted route, then accept it if it matches. If it does not match, stop and investigate the endpoint, DNS, port, proxy, or server state rather than repeatedly deleting records.
Regenerate keys only for confirmed duplication
If two Droplets actually share host-key fingerprints, use a trusted administrative route before changing anything. Keep console access available so you can recover if SSH stops accepting connections. Identify the host-key files configured for sshd; common defaults are under /etc/ssh, but distributions and configurations can use different paths. Preserve the configuration needed to restore service, and move aside or remove only the confirmed duplicated server host private/public key pairs.
Do not remove authorized_keys, your own local private login key, or other user authentication material. Those keys serve a different purpose. The repair is to give the server a distinct host identity, not to change who is permitted to log in.
DigitalOcean documents sudo ssh-keygen -A for generating default host keys when they are missing. The OpenSSH manual defines -A as generating default host keys if they do not already exist. Therefore, running that command while the duplicated files remain in place will not, by itself, replace those existing files. After preserving recovery access, removing or moving aside the confirmed duplicate host-key files allows the generator to create replacements:
sudo ssh-keygen -A
Then restart or reload the SSH daemon using the service name and command appropriate for the Droplet’s distribution. There is no single service-management command that should be assumed for every Linux installation. Confirm the daemon is listening and inspect the new public-key fingerprints through trusted access before relying on SSH again.
If SSH or normal network access has failed, DigitalOcean’s Recovery ISO guide describes a recovery console for that situation. Its menu includes an option to clear cloud-init cached data and regenerate host SSH keys. Follow the current console flow carefully, then return the Droplet to booting from its installed system. The recovery environment has its own SSH host keys, which do not identify the installed Droplet; do not trust the recovery system’s presented identity as the server’s normal one.
Verify the corrected identity
After a stale client record is removed, or after server-side keys are rotated, repeat the fingerprint comparison through a trusted route. For rotation, compare the affected Droplet’s new public-key fingerprint with the other affected Droplets: the repaired host should now have a distinct identity from them. Confirm the fingerprint type as well as its value, since different public host keys from one server are not directly interchangeable comparisons.
Only once the intended server has been independently verified should you remove an old client record for the rotated identity, reconnect, and accept the new fingerprint. A changed fingerprint is a security signal; treating it as routine prompts can teach you to ignore the very warning designed to catch unexpected endpoints. Check each client that connects to the host, because each has its own saved record.
If a client continues to report a mismatch, record the exact host notation in the warning and check whether it resolves to the intended IP, whether a different port or alias is in use, and whether the daemon is presenting the key you inspected. If two Droplets still show the same fingerprint after regeneration, do not keep clearing client records: revisit which files sshd is configured to use and whether the replacement keys were generated on the correct Droplet.
A useful rule is to make the smallest change that matches the evidence. A known-hosts cleanup is appropriate for a verified replacement at a reused address. Server rotation is appropriate for confirmed shared host keys. Neither remedy should be used merely to silence a warning.
For a separate always-on YouTube channel, the same distinction between the stream host’s reliability and the client’s playback settings matters; see our guide to reducing CPU use for a 24/7 stream on a VPS and the overview of running an always-on YouTube radio channel.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does the warning prove two Droplets have duplicate host keys?
No. It means the key presented by the endpoint differs from the key saved by that client for the host notation it used. A rebuilt Droplet reusing an old IP can cause that mismatch without any duplicated server identity. Compare fingerprints through trusted access before choosing a repair.
Will ssh-keygen -R fix duplicated keys on a Droplet?
No. It removes a matching saved host record from the client that runs the command, but it does not change a server’s host keys. Use it for a verified stale client record; rotate server keys only after confirming that the server identity itself is duplicated or must be replaced.
Does sudo ssh-keygen -A replace existing host keys?
OpenSSH documents -A as generating default host keys if they do not already exist. If confirmed duplicate files are already present, the command alone will not replace them. Preserve recovery access and remove or move aside only the affected server host-key pairs before generating replacements.
Can I disable host-key checking to get connected?
Do not use that as a fix. Host-key checking helps you notice when a server identity changes unexpectedly. Verify the endpoint and fingerprint first, then correct the stale client record or the confirmed server-side duplication.