The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The SSH warning means your client cannot match the server’s host key to a trusted key in its known-hosts database. On a first connection, that can be normal—but type yes only after comparing the displayed fingerprint with one obtained from a trusted, independent source. If SSH says the host key has changed, stop: verify the new fingerprint before replacing any entry. Never solve either message by blindly accepting the key, deleting your entire known_hosts file, or setting StrictHostKeyChecking=no globally.
What the SSH authenticity warning means
SSH authenticates a server with a host key pair. The server keeps the private key; your client sees the public key and represents it as a fingerprint, commonly displayed as a SHA-256 value. Your client compares that key with entries in its configured known-hosts sources. If there is no matching entry, it cannot yet establish that the server is the machine you intended to reach, so it displays a warning such as:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors
The authenticity of host 'server.example.com' can't be established.ED25519 key fingerprint is SHA256:…Are you sure you want to continue connecting (yes/no/[fingerprint])?
OpenBSD documents ~/.ssh/known_hosts and ~/.ssh/known_hosts2 as the default user known-hosts files. Your SSH configuration can add or replace these locations with UserKnownHostsFile, and a system-wide file may also be configured. The important point is that SSH is asking whether this exact host key should become trusted for this client, not whether your account password is correct.
#1 Best Overall
A new key and a changed key are different events
| Message situation | What SSH knows | Correct response |
|---|---|---|
| First connection to a host | No trusted key matching the hostname and port is present. | Obtain the expected fingerprint independently, compare it exactly, then accept only a match. |
| Host key changed | A key is already recorded, but the server presented a different one. | Refuse or stop the connection, investigate the change, and replace the old entry only after verification. |
| Key mismatch for an alias, address, or port | The name you used maps to a different known-hosts entry than expected. | Check the exact hostname, IP address, port, and active known-hosts file before editing anything. |
A first-connection prompt is SSH’s normal trust-on-first-use workflow. A changed-key warning is an integrity alarm because an attacker positioned between you and the server could present a substitute key.
Safely approve a first SSH connection
Use this procedure whenever the warning appears without a prior warning that the key changed.
Recommended Free Tools
- Record the connection details. Write down the hostname or IP address, the port, the key algorithm, and the complete fingerprint shown by SSH. A non-default port is part of the identity SSH checks.
- Obtain the expected fingerprint through an independent channel. Ask the server administrator, consult the provider’s management or provisioning console, or use a deployment record that was delivered separately from the SSH connection. Do not use a fingerprint copied from the same potentially intercepted session.
- Compare every character. Confirm that the algorithm and the full fingerprint match. A similar-looking prefix is not sufficient; compare the complete value for the exact host and port.
- Accept only a verified match. At the prompt, enter
yesonly when the independently supplied fingerprint is identical. If it differs, enternoor cancel withCtrl-Cand investigate. - Confirm what acceptance does. SSH writes the accepted public key to the configured user known-hosts database. Future connections can then compare the server’s key automatically instead of asking you to trust an unknown key again.
Acceptance proves only that the key you checked matches the key presented at that moment. It does not prove that the server is well configured, that its account is authorized, or that the remote software is free of vulnerabilities.
When SSH says the host key has changed
Do not answer a changed-key warning with yes and do not disable checking to make it disappear. A legitimate operational event can produce a new key, but so can DNS redirection or a man-in-the-middle attack.
Legitimate explanations
- The server was rebuilt or restored from a new image and generated new host keys.
- An administrator intentionally rotated the host key.
- The hostname or IP address was reassigned to a different machine.
- Your local known-hosts data is stale, damaged, or belongs to a different environment.
Security explanations
- DNS or routing was manipulated so the name reaches an impostor.
- An attacker is intercepting the connection and presenting a key they control.
- You connected through an unexpected proxy, jump host, or network segment.
The warning alone cannot distinguish these cases. The deciding evidence is the expected fingerprint from a trusted administrator, console, or independent provisioning record.
Safe replacement workflow
- Stop the connection and copy the complete warning, including the hostname, port, and new fingerprint.
- Contact the party responsible for the server through a channel that does not depend on the suspect SSH session. Ask whether a rebuild, rotation, or reassignment occurred and request the new fingerprint.
- Compare the supplied fingerprint exactly with the one SSH displayed. If they do not match, treat the connection as hostile and investigate DNS, routing, credentials, and the server itself.
- After a confirmed legitimate change, locate the old entry and remove only the affected host record from the active known-hosts file.
- Reconnect and accept the replacement key only when its fingerprint is the one you verified. Record the change in your administration or deployment log.
Find the entry SSH is using
Search before editing. The ssh-keygen -F option searches known-hosts files and can find hashed hostnames or addresses, so it is useful even when a line is not readable as plain text.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Purpose | Command | Use it when |
|---|---|---|
| Find a default-port host | ssh-keygen -F server.example.com |
You connected with the normal SSH port and used that hostname. |
| Find a non-default-port host | ssh-keygen -F '[server.example.com]:2222' |
The port is part of the stored host identifier. |
| Search a specific known-hosts file | ssh-keygen -F server.example.com -f ~/.ssh/known_hosts |
You need to inspect a file selected by UserKnownHostsFile or another account. |
Use the exact spelling SSH used. Search both a hostname and its IP address if you sometimes connect by address, and search every alias that may resolve to the same machine. A hostname entry does not automatically make an address entry identical for your administrative purposes.
Identify the effective configuration
Different profiles, users, containers, and automation accounts can use different known-hosts files. Inspect the effective settings for the connection rather than assuming your interactive account’s defaults apply. For OpenSSH, ssh -G server.example.com prints the resolved client configuration; review the resulting userknownhostsfile, hostname, and port values. Also check host-specific blocks in ~/.ssh/config and any command-line options supplied by scripts.
Before making a manual edit, create a permission-preserving backup of the file you intend to change, for example:
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.backup
Do not treat a backup as permission to delete unrelated records. The file may contain the only warning that protects other servers.
Rank #3
Remove one stale record after verification
Once the replacement fingerprint has been independently confirmed, use the supported removal operation rather than deleting lines by guesswork. For a default-port host, run:
ssh-keygen -R server.example.com
For a host reached on port 2222, include the bracketed host-and-port form:
ssh-keygen -R '[server.example.com]:2222'
If the relevant file is not the default, specify it explicitly:
ssh-keygen -R server.example.com -f ~/.ssh/known_hosts
Repeat the search and removal for an IP address or alias only when you have verified that those records refer to the same legitimate server and that the changed key should be replaced there as well. If your configuration lists several files in UserKnownHostsFile, process the file that actually contains the stale key; removing an entry from one file will not remove a duplicate in another.
Rank #4
- Made in USA - Proudly produced in Ohio by a Veteran-owned business
- This BookFactory log book is for security guards in any sector or business. You can report location, circumstances and report number.
- There are spaces to log the individual's names address, description and other identifying information. There are also spaces to note others involved, notes, and vehicle information if one was involved
- Wire-O, 100 Pages, Dimensions 3.5" x 5.25"
- Reorder SKU: LOG-100-M3CW-PP(Security-Report)
Reconnect after removal. SSH should present a first-connection prompt for the replacement key. Compare it with the fingerprint you already verified, then accept it. If SSH immediately reports another mismatch, stop again: a second record, a different address, a load-balanced endpoint, or an unresolved security problem may be involved.
Choose a policy for interactive and automated connections
StrictHostKeyChecking controls how SSH handles unknown and changed keys. OpenBSD’s current ssh_config(5) documentation describes the following behavior:
| Setting | Unknown key | Changed key | Security interpretation |
|---|---|---|---|
ask (default) |
Prompts for confirmation before adding it. | Refuses the connection. | Best general interactive default. |
accept-new |
Adds a new key automatically. | Refuses the connection. | Useful for controlled automation when first-use fingerprints are expected and changed keys must still fail. |
yes |
Refuses keys that are not already known. | Refuses the connection. | Appropriate when keys are pre-provisioned and no interactive enrollment is allowed. |
no or off |
Allows new keys without normal confirmation. | Can allow changed keys under documented restrictions. | Weaker behavior; not a safe universal fix. |
The default ask mode is deliberately conservative: new keys are added only after you confirm, and hosts whose keys changed are refused. The accept-new mode removes the interactive prompt for genuinely new hosts but does not turn a changed-key warning into an automatic approval. For unattended jobs, pre-provision fingerprints in a dedicated known-hosts file or use accept-new only when the environment and enrollment process justify it. Never add StrictHostKeyChecking=no globally just to silence a deployment failure; fix the inventory, provisioning, or rotation process instead.
Use DNS SSHFP only as a protected verification source
OpenSSH can consult SSHFP records with VerifyHostKeyDNS. With VerifyHostKeyDNS=yes, a key may be implicitly trusted when it matches a secure SSHFP fingerprint. With ask, SSH displays the DNS match but still follows the normal confirmation rules.
DNS is an independent verification channel only when the SSHFP records are correctly published and protected by DNSSEC. An unsigned or compromised DNS response does not provide the assurance needed to approve a changed key. Confirm the DNSSEC deployment and the record’s ownership before relying on this option, and retain normal host-key checking for failures or mismatches.
Best Value
- Made in USA - Proudly produced in Ohio by a Veteran-owned business
- Comprehensive Coverage: This BookFactory log book includes essential fields such as post/shift, time of change, date, weather conditions, and a designated space for detailed notes. This ensures that all relevant information is captured and easily accessible.
- Sturdy Cover: The trans-lux cover protects the log book from wear and tear, ensuring its longevity and maintaining the integrity of your recorded data.
- Essential Security Tool: This log book is an indispensable tool for any organization that values security and accountability. It helps to prevent misunderstandings, improve communication, and ensure a smooth transition between shifts.
- Wire-O with Trans-lux cover, 100 Pages, Dimensions 8.5" x 11" - (Security-Pass-Down) Reorder SKU: LOG-100-7CW-PP(Security-Pass-Down)
Plan host-key rotation with UpdateHostKeys
UpdateHostKeys lets a server advertise additional host keys after you have already established a trusted connection. A client can learn those keys in advance, allowing a future rotation without a surprise first-contact event. This feature is not a way to trust an unknown server: the initial key must already be trusted or explicitly accepted, and OpenSSH applies its documented known-hosts conditions before accepting replacement keys.
For a planned rotation, verify the current key, enable a suitable update policy on compatible clients, publish the replacement key on the server, and monitor that clients learn it before retiring the old key. Keep an out-of-band fingerprint record so an unexpected key still triggers investigation.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Troubleshoot common cases
The prompt appears every time
Check whether the account can write to the active known-hosts file, whether the file path changes between sessions, and whether a script sets a temporary UserKnownHostsFile. Confirm that the command uses the same hostname and port each time. A container, build runner, or different operating-system user has its own home directory and may not share your interactive file.
The warning started after a rebuild
Do not infer legitimacy from the timing alone. Verify the new fingerprint with the administrator or provisioning console, then remove the old host-and-port record with ssh-keygen -R from the file used by that connection. Reconnect and enroll the verified replacement.
The name resolves to several machines
A load-balanced service, failover address, or recently reassigned IP can expose different host keys. Ask the service owner whether all endpoints should share a key or whether each endpoint has a documented fingerprint. Do not repeatedly delete entries until one happens to work; that can hide a real endpoint mismatch.
The old warning remains after removal
Search the bracketed port form, the IP address, aliases, and every configured known-hosts file. Hashed entries are still discoverable with ssh-keygen -F. If a system-wide file supplies the old key, you may need the administrator who manages that file rather than editing only your home directory.
Automation fails because there is no terminal
Choose a deliberate enrollment design: distribute verified host keys before the job runs and use StrictHostKeyChecking=yes, or use accept-new in a controlled environment where first-use enrollment is expected. A failed job is safer than silently accepting a changed key. Record rotations and update the automation inventory when a legitimate key changes.
The fingerprint from DNS does not match
Stop the connection and check the SSHFP algorithm and digest, DNSSEC validation, hostname, and port. A mismatch means the DNS record, the server key, or the connection target is wrong; it is not a reason to bypass host-key checking.
Quick Recap
Quick decision checklist
- Is this genuinely the first connection, or does SSH report that an existing key changed?
- Did you capture the exact hostname, port, algorithm, and complete fingerprint?
- Did an administrator, protected console, provisioning record, or DNSSEC-backed SSHFP source provide the expected fingerprint independently?
- Are you inspecting the known-hosts file actually selected by the effective SSH configuration?
- For a changed key, did you verify the cause before removing only the affected record?
- Does your automation preserve refusal of changed keys?
- Have you avoided deleting all known hosts and avoided using
StrictHostKeyChecking=noas a blanket workaround?
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.
