When you see SFTP host key verification failed, SSH is not being picky, it is stopping a connection because the server’s fingerprint no longer matches what you previously trusted [3][8]. That usually means one of two things, the server really changed its host key after a reinstall or migration, or someone may be intercepting the connection in a man in the middle attack [2][3][10].
You need to treat that warning as a security check, not a nuisance, because the wrong fix can quietly weaken every future transfer. A client like openSFTP shows host key fingerprints visually, making verification easier. In this article, you will learn what the host key check compares, how to tell a first-time connection from a stale known_hosts entry or a real server change, and how to fix the error without disabling verification.
Why is SFTP blocking the connection instead of just retrying?
It is checking trust
SFTP sits on SSH, and SSH does not treat a failed host key verification as a temporary glitch. It treats it as a trust problem, because the server you reached does not match the server you trusted before, or you have no trusted record yet [3][4].
That is why SFTP host key verification failed feels harsh. The client would rather stop than guess, because a guess could send your password or files to an impostor. This is a different layer from permission denied, which happens after the connection succeeds in a man in the middle attack.
Two common triggers
On a first-time connection, there may be no matching entry in your known_hosts file, so SSH has nothing to compare against [1][3][4]. On a later connection, the server may have a new key after a reinstall, migration, or update, and the stored fingerprint no longer matches [2][3].
A concrete example helps. If your server was rebuilt on a new VM (which can also cause connection refused errors) and now presents a different ED25519 host key, SSH will stop even if the hostname and IP look correct, because the identity changed [7].
What retrying would risk
If SSH retried automatically, it could keep accepting whatever key it sees next. That would make spoofing easier, not harder, and it would turn a security alarm into background noise.
In practice, the failure usually means one of three things:
- first connection, no saved host key yet [1][4]
- the server host key changed after a rebuild or migration [2]
- the stored fingerprint no longer matches the current key [3]
You can think of the error as SSH asking, “Is this still the same server?” Next, you need to see what it is actually comparing, and where that trusted record lives.
What does the host key check actually compare against?
The saved identity
SSH keeps a local record of the server’s identity in your $HOME/.ssh/known_hosts file [4]. On each connection, it compares the host key the server presents with that stored record, and it blocks when they do not match [3].
The fingerprint is the short version of that public key, so you can verify it without reading a huge key blob [5]. You will often see it shown as SHA256 on newer OpenSSH versions, while older systems may still show MD5 [6].
What changes trigger failure
A mismatch does not always mean danger, but it always means the trust record changed. The common causes are a first-time connection with no saved entry yet, or a real server change after a migration, reinstall, or key replacement [1][2].
For example, if your SFTP server moved to a new host and now uses an ED25519 key instead of the old RSA key, the fingerprint you stored before will no longer match [7]. In that case, SSH is doing its job: it refuses to assume the new server is the old one.
Why the comparison matters
This check protects you from spoofing and man in the middle attack attempts [3][8]. If SSH accepted any new key silently, an attacker could stand between you and the server and present a fake identity that looks valid enough to steal credentials or files.
That is also why tools like openSFTP display the host key fingerprint visually. They help you compare what you see in the client with what the server owner gave you, so you can confirm identity before you trust the connection.
Once you know the client is comparing a stored fingerprint against the server’s current key, you can match the error to the right fix.
Which fix matches your exact error case?
First connection or known host
If this is the first time you connect, the fix is simple, but not blind. You need to confirm the SSH fingerprint out of band, then accept it so the client can write a trusted entry to known_hosts [1][2]. That is the normal path when the server is new or your local trust store is empty.
For example, openSFTP helps here because it shows the host key fingerprint visually, so you can compare it with the value your server admin gave you before you trust the connection.
Server key changed
If the server was rebuilt, migrated, or had its keys rotated, the old record is the problem [2][3]. This is the case most people hit after maintenance, and it is exactly where ssh-keygen -R helps, because it removes the stale host entry so you can accept the new one [4].
Here is a concrete example. After a server reinstall, a production SFTP endpoint came back with a new RSA host key, the old fingerprint in ~/.ssh/known_hosts no longer matched, so the client refused to connect until the stale entry was removed with ssh-keygen -R and the new fingerprint was confirmed out of band.
Duplicate or corrupt entries
Sometimes the problem is not the server at all, but a messy known_hosts file [3]. If you have multiple entries for the same host, an old IP, or a corrupted line, SSH can compare against the wrong record and fail even when the new fingerprint is valid.
In that case, clean the specific host entry instead of deleting the whole file. You keep your other trusted servers intact, and you avoid creating a wider verification gap.
Policy mismatch
If your config forces StrictHostKeyChecking yes, SSH will stop on any mismatch, which is safe but unforgiving. If someone set StrictHostKeyChecking no, the connection may “work,” but you have weakened protection against a man in the middle attack [13][14].
So treat policy as the last thing to check, not the first thing to disable. Next, you will see how to keep this strict by default while making everyday SFTP use less painful.
How do you keep verification strict without making the workflow painful?
Make trust repeatable
You do not need to weaken host key verification to make SFTP usable. You need a repeatable habit: verify the SSH fingerprint out of band once, then keep the saved key unless the server owner confirms a real change [1][2].
A simple example works well in practice. If your admin sends the fingerprint in Slack and the one in openSFTP matches, you accept it, store it in known_hosts, and move on. That is fast, and it still blocks a man in the middle attack.
Clean up only the right entry
When a server changes, remove only the stale host record with ssh-keygen -R, then reconnect and compare the new fingerprint before you trust it [3][4]. You keep every other saved server intact, which matters if you connect to many hosts from one laptop.
If the server team rotated keys after a rebuild or suspected compromise, they should publish the new fingerprint through a separate channel [5]. You check that value, then accept the update. That keeps the workflow strict without turning every maintenance window into guesswork.
Avoid the easy trap
StrictHostKeyChecking=no and UserKnownHostsFile /dev/null remove friction, but they also remove the protection you wanted in the first place [13][14]. Use those only in throwaway environments where no real secret crosses the link.
For production, keep verification on and make the check quick. The safest workflow is still the fastest one once you have a trustworthy fingerprint source.
That gives you the right default, so the final step is knowing when to trust the change and when to stop and investigate.
Treat the fingerprint mismatch as a trust decision
The core idea stays simple: SFTP host key verification failed is not a nuisance prompt. It is SSH stopping a connection because the server’s presented fingerprint no longer matches what you trusted before, which usually means either a real server change or a potential man in the middle attack [3][8][10].
You now know how to read the error in context, whether you are seeing a first-time connection, a stale known_hosts file, a changed host key after a rebuild, or a host key policy mismatch. The safe fix is always the same in spirit, verify the SSH fingerprint out of band, then update only the exact entry that changed.
Your next step, check the current fingerprint with your server owner or your openSFTP visual host key fingerprint display, then remove only the stale entry with ssh-keygen -R if the change is legitimate.
Sources
- SFTPCloud, "Host key verification can fail on a first-time connection when no known_hosts entry exists" (2025-04-01) [https://sftpcloud.io/learn/sftp/sftp-host-key-verification-failed]
- SFTPCloud, "Host key verification can fail after server changes such as migrations, updates, or replacement of the old key" (2025-04-01) [https://sftpcloud.io/learn/sftp/sftp-host-key-verification-failed]
- KodeKloud, "SSH host key verification fails when the current server key does not match known_hosts and helps prevent spoofing" (2025-04-01) [https://kodekloud.com/blog/how-to-fix-host-key-verification-failed-in-ssh/]
- phcomp, "SSH stores the remote host fingerprint in $HOME/.ssh/known_hosts" (2025-04-01) [https://www.phcomp.co.uk/Tutorials/Unix-And-Linux/ssh-check-server-fingerprint.html]
- phcomp, "A fingerprint is a short version of the server public key" (2025-04-01) [https://www.phcomp.co.uk/Tutorials/Unix-And-Linux/ssh-check-server-fingerprint.html]
- Linode Docs, "SSH fingerprints are commonly shown as SHA256 or MD5 depending on OpenSSH version" (2025-04-01) [https://www.linode.com/docs/guides/verifying-the-authenticity-of-remote-host/]
- Linode Docs, "SSH host keys can be ED25519 or ECDSA, and older servers may use RSA or DSA" (2025-04-01) [https://www.linode.com/docs/guides/verifying-the-authenticity-of-remote-host/]
- KodeKloud, "SSH stores server fingerprints to prevent spoofing and man-in-the-middle attacks" (2025-04-01) [https://kodekloud.com/blog/how-to-fix-host-key-verification-failed-in-ssh/]
- KodeKloud, "The error occurs when the server current key does not match the key stored in known_hosts" (2025-04-01) [https://kodekloud.com/blog/how-to-fix-host-key-verification-failed-in-ssh/]
- KodeKloud, "Common mismatch causes include server reinstall, key rotation, IP or DNS changes, or a corrupted known_hosts file" (2025-04-01) [https://kodekloud.com/blog/how-to-fix-host-key-verification-failed-in-ssh/]
- KodeKloud, "Removing the old key and accepting the new one is a documented fix" (2025-04-01) [https://kodekloud.com/blog/how-to-fix-host-key-verification-failed-in-ssh/]
- KodeKloud, "Regenerating host keys resolves mismatches caused by compromised or outdated keys" (2025-04-01) [https://kodekloud.com/blog/how-to-fix-host-key-verification-failed-in-ssh/]
- KodeKloud, "StrictHostKeyChecking=no bypasses verification but is not secure" (2025-04-01) [https://kodekloud.com/blog/how-to-fix-host-key-verification-failed-in-ssh/]
- UWH Support, "StrictHostKeyChecking no and UserKnownHostsFile /dev/null disable host key checking" (2025-04-01) [https://kb.unlimitedwebhosting.co.uk/vps/how-to-disable-strict-host-key-checking]
Frequently Asked Questions
What should I do first when I see "SFTP host key verification failed"?
Stop and confirm whether the server fingerprint has actually changed before reconnecting. Check the fingerprint through a separate trusted channel, then decide whether the stored key should be updated or the connection should be treated as suspicious.
How can I tell if this is a normal first-time connection or a real security problem?
If the host has never been saved in your known_hosts file, it is usually a first-time trust prompt. If the same server suddenly shows a different fingerprint, treat it as a possible server rebuild or a man in the middle attack until verified.
Can I safely delete the host key warning by turning off verification?
You can, but you should not in production because it removes the protection against spoofed servers. A safer fix is to remove only the stale entry and confirm the new fingerprint before accepting it.
Why does SSH complain after a server migration or reinstall?
Those changes often generate a new host key, so the server no longer matches the fingerprint you previously trusted. The connection fails because SSH assumes the identity may have changed and wants you to verify it again.
What is the difference between a stale known_hosts entry and a bad host key policy?
A stale known_hosts entry means your saved fingerprint is outdated or duplicated, while a policy mismatch means your SSH settings are forcing strict checking or disabling it. The first is fixed by cleaning the specific record, and the second is fixed by reviewing your SSH configuration.
