Free tools Windows power users keep installed
One-click scans. No signup required.
Do not type yes automatically. SSH is warning that it cannot match the server’s presented host key with a trusted entry in your known-hosts database. On a genuinely new server, verify the displayed fingerprint through an independent trusted channel, then accept it. If a server you have used before presents a different key, stop and investigate before removing anything: the change may be legitimate, but it can also indicate DNS tampering or a man-in-the-middle attack.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
This guide explains how to identify which case you have, verify a key, inspect and repair known_hosts, and configure automation without disabling SSH’s protection against changed keys.
As an Amazon Associate I earn from qualifying purchases.
What the SSH authenticity warning means
SSH authenticates a server with a host key. The server proves possession of its private host-key component during the connection, while your SSH client compares the corresponding public key with entries it has previously trusted. Those entries are normally stored in your user known-hosts files, including ~/.ssh/known_hosts and, on systems that still use it, ~/.ssh/known_hosts2. System-wide files and any paths specified by your SSH configuration can also participate.
The warning appears when the client cannot establish that match. That happens in two fundamentally different situations:
#1 Best Overall
- POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
- PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts
- New host: there is no trusted entry for this hostname and port. SSH shows the server’s key fingerprint and asks whether you want to add it.
- Changed host: an entry exists, but the key now presented by the server is different. SSH treats this as a security event and normally refuses the connection.
A hostname is not the complete identity used for this check. The port matters too. For example, server.example on port 22 and the same name on port 2222 can have separate known-hosts entries. An IP address, an alias, and a bracketed host-and-port form may likewise be recorded separately.
Accepting a key tells SSH to store it in the active user known-hosts file. On later connections, the client can compare the server’s key automatically and warn if it changes. Acceptance is therefore a trust decision, not a harmless acknowledgement.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsFirst connection: how to decide whether “yes” is safe
For a first connection, the warning is expected only if you can confirm that the fingerprint belongs to the server you intended to reach. The fingerprint printed by SSH is specific to the host key, hostname and port you are connecting to; a generic fingerprint found in an unrelated example is not useful.
- Record the connection details. Note the exact hostname or IP address, the port (including a non-default port), the account, and the complete fingerprint shown in the warning. Do not rely on a truncated screenshot or a fingerprint copied from an untrusted chat.
- Obtain an expected fingerprint independently. Ask the server administrator, check a trusted cloud or hosting console, consult the provisioning record, or use another channel whose security does not depend on the SSH connection you are about to make. For a machine managed by your organization, the person or system that generated the host keys should be able to provide the expected value.
- Compare the values character for character. Confirm that the expected key type, fingerprint and target port correspond to the connection. A match for one server, address or port does not automatically authorize another.
- Accept only an exact match. At the SSH prompt, type
yesonly after the independent comparison succeeds. SSH then writes the accepted key to the configured user known-hosts file. - Abort on any discrepancy. Type
noor end the connection, and resolve the identity question with the administrator. Do not “try yes just to see whether it works.”
The default interactive behavior is designed for this process. OpenBSD’s ssh_config(5) documentation describes the default StrictHostKeyChecking ask mode as adding new keys only after the user confirms, while refusing hosts whose key has changed.
What a successful first connection changes
After confirmation, the key is recorded in the active known-hosts database. The next connection should proceed without a first-use question as long as the same host-and-port identity presents the same key. If the entry is hashed, you may not see the hostname in plain text when opening the file; hashing does not weaken the comparison and is one reason to use ssh-keygen for searches and removals.
Rank #2
- POWERFUL SECURITY KEY: The Security Key NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key NFC secures 100 of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your Security Key NFC via USB-A and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
- TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
A changed-key warning is a different problem
If SSH says the remote host identification has changed, treat the message as a failed identity check. Possible benign explanations include a server rebuild that generated new host keys, an intentional host-key rotation, a hostname or IP address being reassigned to another machine, or an old local entry that no longer describes the intended endpoint. The same symptom can also result from DNS spoofing, traffic redirection or a man-in-the-middle attack.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Do not delete the entry or weaken checking until you know which explanation applies. First verify the new fingerprint through an independent administrator, console or provisioning channel. If the operator confirms a rebuild or rotation, obtain the new key for the exact hostname and port you use and compare it with the value SSH displayed.
| Situation | What SSH is telling you | Correct next action |
|---|---|---|
| No entry for this host and port | The client has never trusted a key for this identity. | Verify the displayed fingerprint independently, then accept it if it matches. |
| Existing entry, same key | The remembered identity still matches. | Connect normally; no repair is needed. |
| Existing entry, different key | The endpoint’s identity changed or the connection is being intercepted. | Stop, verify the replacement key independently, then replace the stale entry only if the change is legitimate. |
| Several entries for aliases, addresses or ports | One name may refer to multiple recorded identities. | Inspect every matching record and confirm which name and port your command actually uses. |
Find the entry SSH is using
Use the OpenSSH key-management utility instead of searching the file by eye. The -F operation searches known-hosts files and can locate hashed hostnames or addresses.
Search a default-port connection
Run:
ssh-keygen -F server.exampleThis reports matching entries for server.example in the known-hosts locations that ssh-keygen searches. Replace the name with the exact hostname or address used in your SSH command.
Search a non-default port
OpenSSH records a host with a non-default port in bracketed form. Search it the same way:
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallssh-keygen -F '[server.example]:2222'Searching only for server.example can miss this entry. If you connected by IP address, search the IP address; if you used an alias, search the alias as well.
Check the effective configuration
The file you expect may not be the file SSH actually uses. A user or system configuration can set UserKnownHostsFile to another path, and a command-line option can override it for one connection. Review the effective settings for the target host:
ssh -G server.example | grep -i -E 'userknownhostsfile|globalknownhostsfile|stricthostkeychecking|verifyhostkeydns|updatehostkeys'The -G output is configuration data, not a connection attempt. If your platform does not provide grep, inspect the output manually or use the equivalent text-search utility. When a custom UserKnownHostsFile is configured, use that path when inspecting or backing up entries.
Remove or replace a stale entry after verification
Only perform this procedure after an administrator or another trusted source has confirmed that the newly presented fingerprint is correct. Removing an entry without that confirmation merely hides the warning; it does not prove that the new server is genuine.
- Save a backup. Copy the active known-hosts file before editing it. For the usual file, a shell command is
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.backup. Use the actual path reported by your configuration if it differs. - Remove the exact identity. For the default port, run
ssh-keygen -R server.example. For a non-default port, include the brackets:ssh-keygen -R '[server.example]:2222'. If you used an IP address or alias, remove the corresponding identity too, but do not erase unrelated hosts. - Confirm the result. Repeat the appropriate
ssh-keygen -Fsearch. It should no longer find the stale record in the file you changed. If another configured known-hosts file still contains a record, identify it before editing. - Reconnect and verify again. Start a new SSH connection. Compare the newly displayed fingerprint with the value you obtained independently, then accept it only if they match.
ssh-keygen -R is preferable to manually deleting a line because it handles the known-hosts format, including hashed hostnames, and targets the specified host. Do not delete the entire known_hosts file as a general remedy: doing so discards trust records for every server and causes avoidable first-connection prompts.
Choosing a StrictHostKeyChecking mode
StrictHostKeyChecking controls how SSH handles new and changed host keys. The setting should reflect whether you can provision keys ahead of time and whether an unattended job must fail closed.
| Mode | New key | Changed key | Security and operational use |
|---|---|---|---|
ask (default) |
Prompts for confirmation before adding it. | Refuses the connection. | Appropriate for interactive use when you can verify fingerprints at first connection. |
accept-new |
Automatically adds a previously unseen key. | Does not permit the connection. | Useful for controlled automation where new hosts are expected but an unexpected change must stop the job. You still need a process for validating newly created hosts. |
yes |
Requires a key to be already trusted; it does not silently enroll unknown hosts. | Refuses the connection. | Strong fail-closed behavior when keys are pre-provisioned. |
no or off |
Relaxes confirmation for new keys. | Can allow changed keys under documented restrictions. | Weaker protection; not a universal fix for this warning and unsuitable as a blanket security setting. |
For an unattended deployment, a safer pattern is to distribute the expected host key or fingerprint through a trusted provisioning system and use a mode that refuses changes. If a job uses accept-new, monitor failures and investigate every changed-key event rather than retrying with no. Keep the setting scoped to the required host or command instead of changing a global configuration for convenience.
Using DNS SSHFP records as an additional check
OpenSSH can consult SSHFP records in DNS with VerifyHostKeyDNS. With yes, a key can be implicitly trusted when it matches a secure SSHFP fingerprint. With ask, SSH displays a matching result but still follows the normal confirmation behavior.
DNS is an independent verification source only when the SSHFP records are correctly published and protected with DNSSEC. An unsigned or incorrectly maintained record should not be treated as proof of identity: an attacker who can alter the DNS response could alter the fingerprint presented to the client as well. Confirm that the record belongs to the exact hostname and that the DNSSEC validation path is working before relying on this option.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Planning host-key rotation with UpdateHostKeys
UpdateHostKeys allows a server to advertise additional host keys after a connection has already been trusted. A client can learn those keys in advance, making a planned rotation less disruptive than replacing the only key and surprising every user at once.
Best Value
- POWERFUL SECURITY KEY: The YubiKey 5 is a versatile physical passkey that protects your digital life from phishing attacks. It ensures only you can access your accounts.
- WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 secures 100+ of your favorite accounts, including email, password managers, and more.
- FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 via USB and tap it to authenticate. No batteries, no internet connection, and no extra fees required.
- MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it.
- BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.
This feature does not make an untrusted first connection safe. The initial host key must already be trusted or explicitly accepted, and OpenSSH applies known-hosts conditions before it accepts replacement keys. In practice, establish a verified trust path first, enable the option where appropriate, and retain the existing key until clients have learned the replacement. Coordinate the server and client configuration so that the new key is published before the old one is retired.
Troubleshooting branches
“I verified the key, but SSH still warns”
- Check that you verified the key for the same hostname and port used by the command. A console fingerprint for an IP address may not correspond to a DNS alias.
- Search both the hostname form and the bracketed non-default-port form with
ssh-keygen -F. - Inspect
UserKnownHostsFileand any global known-hosts file fromssh -G; the stale record may be in a different path. - Look for multiple entries created by aliases, load-balancer names or address changes. Remove only the confirmed stale identity.
“The warning appears on every connection”
- Confirm that your account can write to the active known-hosts file and that the file’s directory exists with appropriate permissions.
- Check whether a wrapper, container, temporary home directory or automation runner uses a different
HOMEorUserKnownHostsFileeach time. - Ensure the command is not using a disposable known-hosts file through
-o UserKnownHostsFile=/path. - If the server regenerates host keys on every boot, fix that server-side persistence problem rather than accepting a new key repeatedly.
“The server was rebuilt and I need access urgently”
Urgency does not change the identity question. Ask the rebuild operator to provide the new fingerprint through a trusted channel, compare it with SSH’s warning, and then use ssh-keygen -R for the exact host-and-port identity. If no trusted party can confirm the replacement, preserve the warning and investigate DNS, routing and the rebuild record before connecting.
“Several people see different fingerprints”
Stop treating the endpoint as a single known identity. Check whether a load balancer, failover pool, split DNS configuration or hostname reassignment is intentional. Each legitimate backend key must be documented and distributed appropriately. If the variation is unexplained, test DNS resolution and network paths from a trusted environment and involve the system owner; do not make the clients accept whichever key they happen to receive.
A practical decision checklist
- Is this genuinely the first connection to this hostname-and-port identity?
- Did you obtain the expected fingerprint outside the SSH session?
- Does the fingerprint match exactly, including the key type and target port?
- If the key changed, has an authorized operator confirmed a rebuild, reassignment or rotation?
- Did you search with the right hostname form, IP address and bracketed port syntax?
- Did you identify the effective
UserKnownHostsFilebefore editing? - Are you removing only the verified stale entry rather than deleting all trust records?
- Does automation preserve refusal of changed keys?
- If using DNS SSHFP, are the records correct and DNSSEC-protected?
- If rotating keys, was the original key trusted before enabling
UpdateHostKeys?
Bottom line
The authenticity warning is SSH doing its job. For a new host, independently verify the displayed fingerprint before accepting it. For a changed host, assume the connection may be unsafe until the replacement key is confirmed; only then locate and remove the specific stale entry and reconnect. Keep strict checking enabled, use pre-provisioned keys or accept-new carefully in automation, and never make StrictHostKeyChecking=no or wholesale deletion of known_hosts your default repair.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
