By Kedar Salunkhe | Last Updated: March 2026
You were doing something completely routine. Maybe running a git pull, maybe SSHing into a server, maybe deploying through a CI/CD pipeline. And then your terminal stopped cold with this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be intercepting your network communications!
Host key for 'github.com' has changed
and the key for the resolving address
is unknown. Add correct host key in /home/user/.ssh/known_hosts.
Offending RSA key in /home/user/.ssh/known_hosts:5
Host key verification failed.That wall of capital letters is designed to alarm you — and honestly, in some cases, it should. SSH built this warning because a changed host key can sometimes mean a man-in-the-middle attack is happening on your network. But in practice, the vast majority of the time this error appears for completely harmless reasons: a server got rebuilt, GitHub rotated its keys, you’re connecting to a new environment, or you restored a known_hosts file that’s now out of date.
The trick is knowing how to tell the difference between a legitimate security concern and a routine configuration issue — and then applying the right fix.
This guide covers every common cause of the “Host key verification failed” error, walks you through the diagnostic steps to identify your specific situation, and gives you the exact commands to resolve it. Whether you’re seeing this on GitHub, a remote server, a CI/CD pipeline, or a fresh machine, the fix is in here.
Let’s work through it.
Host Key Verification Failed – 7 Quick Fixes (SSH Error Guide)
What Is the Host Key Verification Failed Error?
Before diving into fixes, it’s worth spending a moment on what this error actually means — because unlike most Git and SSH errors, this one has a genuine security dimension you should understand.
When you connect to a remote server or service over SSH for the first time, SSH retrieves the server’s public host key — a unique cryptographic fingerprint that identifies that specific server. SSH stores this fingerprint in a file on your machine called ~/.ssh/known_hosts. Every subsequent time you connect to the same host, SSH checks the fingerprint it receives against the one stored in known_hosts. If they match, the connection proceeds. If they don’t match, SSH throws this error and refuses to connect.
The reason SSH is this strict is legitimate: if a different server (or an attacker intercepting your traffic) presents a different key for the same hostname, you’d be connected to the wrong machine — potentially handing over credentials, code, or sensitive data to someone malicious. The technical name for this kind of attack is a man-in-the-middle attack, and SSH’s known_hosts mechanism is the primary defense against it.
Here’s the important context though: in the overwhelming majority of real-world cases, this error is not caused by an attack. It’s caused by one of these completely routine situations:
The remote server was rebuilt or reinstalled (generating a new host key)
GitHub, GitLab, or another hosting service rotated their host keys
You’re connecting from a new machine or a new user account with no known_hosts entries
A CI/CD environment spun up without any known_hosts configuration
The server’s IP address changed but the hostname stayed the same
You restored a system from backup and the known_hosts file is stale
The full error message you’ll see typically looks like one of these:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be intercepting your network communications!
Host key for 'github.com' has changed
Offending RSA key in /home/user/.ssh/known_hosts:5
Host key verification failed.Or the shorter version, which appears when SSH can’t verify the key at all:
ssh: connect to host github.com port 22: Host key verification failed.Or when it appears during a Git operation:
git@github.com: Permission denied (publickey).
Host key verification failed.
fatal: Could not read from remote repository.The key piece of information in the full error is the line that says “Offending [KEY TYPE] key in /home/user/.ssh/known_hosts:[LINE NUMBER].” That tells you exactly which entry in your known_hosts file is conflicting — and that’s where the fix happens.
Why Does Host Key Verification Fail?
There are seven distinct scenarios that cause this error. Understanding which one applies to your situation determines the right fix.
Reason 1 — GitHub Rotated Its SSH Host Keys
This is the most common reason developers suddenly see this error on GitHub specifically. In March 2023, GitHub rotated its RSA SSH host key after the private key was accidentally exposed in a public repository. Millions of developers woke up to this error overnight through no fault of their own. Any known_hosts file containing the old GitHub RSA key started throwing the mismatch error.
GitHub and other services occasionally rotate keys for security reasons. When they do, everyone who has previously connected sees this error until their known_hosts entry is updated.
Reason 2 — Server Was Rebuilt or Reinstalled
When a server’s operating system is reinstalled or the server is rebuilt from scratch, a new SSH host key pair is generated during setup. The server’s hostname and IP address might stay exactly the same, but it presents a completely different host key. Your known_hosts file still has the old key, the new server presents a different one, and SSH flags the mismatch.
This is extremely common when working with cloud servers, staging environments that get regularly rebuilt, and development VMs.
Reason 3 — You’re Connecting for the First Time
On a new machine or a new user account, the ~/.ssh/known_hosts file doesn’t exist yet. The first time you connect to any host, SSH asks you to verify the fingerprint:
The authenticity of host 'github.com (IP)' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
Are you sure you want to continue connecting (yes/no)?This isn’t quite the same error as host key verification failed, but if the prompt is dismissed, skipped, or handled incorrectly in an automated script, it can lead to the full verification failure.
Reason 4 — The Server’s IP Address Changed
DNS records can change. A hostname that used to point to one IP address might now point to a different one — perhaps after a server migration, a load balancer change, or a hosting provider move. If your known_hosts file stored the key associated with the old IP and the new server has a different key, the mismatch error appears.
Reason 5 — CI/CD Environment Has No known_hosts File
Automated environments like GitHub Actions runners, GitLab CI containers, Jenkins agents, and Docker build containers typically start without any ~/.ssh/known_hosts file. When these environments try to clone a repository or SSH into a server, they hit the host verification prompt — and since no one is there to type “yes,” the connection fails.
Reason 6 — Stale known_hosts After a System Restore or Migration
If you restored your machine from a backup, migrated from one machine to another, or copied your dotfiles from an old setup, the known_hosts file you imported might contain outdated fingerprints for servers that have since been updated. Every entry that no longer matches its server becomes a potential source of this error.
Reason 7 — A Genuine Security Concern (Rare but Real)
It would be irresponsible to write a guide on this error without acknowledging the case where the warning is real. If you’re connected to an unfamiliar network (an airport, hotel, conference wifi, or an unfamiliar corporate network), and you suddenly see this error for a server you’ve connected to many times before on trusted networks, treat it seriously. A mismatch on an untrusted network is exactly the scenario SSH is designed to catch. Don’t accept the new key blindly — verify the server’s current host key through a trusted out-of-band channel (call the server administrator, check the hosting provider’s documentation) before proceeding.
In practice, this scenario is rare. But it’s the reason the SSH warning is as loud as it is.
Fix 1 — Remove the Specific Offending Key From known_hosts
This is the cleanest and most targeted fix for the most common scenario: a server was rebuilt, a service rotated its keys, or an IP changed. You remove the specific stale entry from known_hosts, reconnect, and SSH adds the fresh key.
The error message tells you exactly which line to remove:
Offending RSA key in /home/user/.ssh/known_hosts:5The number after the colon is the line number. You have two ways to remove it.
Option A — Use ssh-keygen -R (Recommended)
The ssh-keygen tool has a built-in flag to remove a host’s entry from known_hosts:
ssh-keygen -R github.com
Replace github.com with whatever hostname is in your error message. This removes all entries for that hostname automatically, regardless of which line they’re on.
For a specific IP address instead of a hostname:
ssh-keygen -R 140.82.121.4
After running this, reconnect. SSH will show the new fingerprint and ask you to confirm:
The authenticity of host 'github.com' can't be established.
ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU.
Are you sure you want to continue connecting (yes/no)?Before typing yes, verify the fingerprint. For GitHub, the official fingerprints are published at https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints. Match the fingerprint in your terminal against the official list. If it matches, type yes. SSH will store the new key in known_hosts and the connection will proceed normally.
Option B — Edit known_hosts Manually
If you prefer to edit the file directly, open it in a text editor:
nano ~/.ssh/known_hosts
Find the line number mentioned in the error (line 5 in our example), delete that entire line, save and close the file.
Or use sed to delete it by line number without opening the file:
sed -i ‘5d’ ~/.ssh/known_hosts
Replace 5 with the actual line number from your error message.
Or delete the entry for a specific hostname using grep:
grep -v "github.com" ~/.ssh/known_hosts > ~/.ssh/known_hosts.tmp && mv ~/.ssh/known_hosts.tmp ~/.ssh/known_hostsFix 2 — Use ssh-keyscan to Add the Correct Key
Instead of removing the entry and then reconnecting, you can proactively fetch the server’s current host key and add it to known_hosts in a single command. This is particularly useful when you already know the key change is legitimate and want to update without an interactive confirmation prompt.
ssh-keyscan github.com >> ~/.ssh/known_hosts
This fetches the current public host key for github.com and appends it to your known_hosts file. After running this, SSH connections to GitHub will use the new key without prompting.
For GitLab:
ssh-keyscan gitlab.com >> ~/.ssh/known_hosts
For Bitbucket:
ssh-keyscan bitbucket.org >> ~/.ssh/known_hosts
For a private server by IP address:
ssh-keyscan 192.168.1.100 >> ~/.ssh/known_hosts
For a private server by hostname:
ssh-keyscan myserver.example.com >> ~/.ssh/known_hosts
If you want to fetch a specific key type only (useful for consistency in automated scripts):
ssh-keyscan -t ed25519 github.com >> ~/.ssh/known_hosts
ssh-keyscan -t rsa github.com >> ~/.ssh/known_hostsAfter running ssh-keyscan, verify the connection:
ssh -T git@github.com
Expected output for GitHub:
Hi username! You’ve successfully authenticated, but GitHub does not provide shell access.
One important note: ssh-keyscan fetches whatever key the server presents at that moment. It does not verify whether the key is legitimate — it just trusts what it gets. For a server you know and trust (like github.com, where you can cross-reference the fingerprint against official documentation), this is perfectly fine. For an unknown or potentially compromised server, you should verify the fingerprint through an out-of-band channel before accepting it.
Fix 3 — Fix the GitHub-Specific Key Rotation Error
If the error appeared suddenly for github.com without you changing anything on your machine, GitHub almost certainly rotated its SSH host keys. This happened in March 2023 and will happen again in the future for security reasons.
GitHub’s current official SSH fingerprints (verify these at https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints):
SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s (RSA)
SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM (ECDSA)
SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU (Ed25519)The quickest fix for the GitHub key rotation specifically:
Step 1 — Remove the old GitHub entry:
ssh-keygen -R github.com
Step 2 — Fetch and add GitHub’s current keys:
ssh-keyscan github.com >> ~/.ssh/known_hosts
Step 3 — Verify the fingerprint matches GitHub’s official list:
ssh-keygen -lf ~/.ssh/known_hosts | grep github.com
Compare the fingerprints shown against the official list above. If they match, you’re good.
Step 4 — Test the connection:
ssh -T git@github.com
If you manage multiple machines or want to distribute the fix to a team, GitHub also publishes its current SSH host keys at https://api.github.com/meta in the ssh_keys field. Automated scripts can fetch from this endpoint to keep known_hosts up to date.
Fix 4 — Fix the Error for a Rebuilt or New Remote Server
When you’re seeing this error for your own server — a VPS, a staging server, a development VM — the cause is almost always that the server was rebuilt and has a fresh SSH host key.
The approach here is slightly different from the GitHub fix because you want to verify the new key is actually from your server before accepting it.
Step 1 — Get the Server’s Current Host Key Fingerprint
Log into your server through a method other than SSH — your hosting provider’s web console, VNC, or a serial console. Once logged in, run:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
This outputs the fingerprint of the server’s actual current host key. Write this down.
Step 2 — Compare With What SSH Sees
From your local machine, check what fingerprint the server is presenting:
ssh-keyscan -t ed25519 YOUR-SERVER-IP | ssh-keygen -lf –
If the fingerprint matches what you got in Step 1, the connection is legitimate — the key just changed because the server was rebuilt, not because someone is intercepting your traffic.
Step 3 — Remove the Old Entry and Add the New One
ssh-keygen -R YOUR-SERVER-HOSTNAME
ssh-keyscan YOUR-SERVER-HOSTNAME >> ~/.ssh/known_hostsOr by IP:
ssh-keygen -R YOUR-SERVER-IP
ssh-keyscan YOUR-SERVER-IP >> ~/.ssh/known_hostsStep 4 — Reconnect and Verify
ssh user@YOUR-SERVER-HOSTNAME
You should now connect without any warnings.
Fix 5 — Fix the Error in CI/CD Pipelines and Automated Scripts
CI/CD environments are one of the most common places this error appears because every pipeline run starts with a clean environment — no known_hosts, no prior SSH connections, no stored fingerprints. When the pipeline tries to clone a repository or SSH into a deployment server, it hits either the interactive confirmation prompt (which hangs indefinitely in a non-interactive environment) or the host key verification failure.
There are three reliable ways to fix this in automated environments.
Option A — Add a known_hosts Setup Step to the Pipeline
The cleanest approach. Add a step at the start of your pipeline that runs ssh-keyscan and populates known_hosts before any Git or SSH operation happens.
In GitHub Actions:
- name: Setup known hosts
run: |
mkdir -p ~/.ssh
ssh-keyscan github.com >> ~/.ssh/known_hosts
chmod 700 ~/.ssh
chmod 600 ~/.ssh/known_hosts
In GitLab CI:
before_script:
- mkdir -p ~/.ssh
- ssh-keyscan github.com >> ~/.ssh/known_hosts
- chmod 700 ~/.ssh
- chmod 600 ~/.ssh/known_hosts
In a shell script:
mkdir -p ~/.ssh
ssh-keyscan github.com >> ~/.ssh/known_hosts
chmod 700 ~/.ssh
chmod 600 ~/.ssh/known_hosts
Option B — Use StrictHostKeyChecking=no (With Caution)
This disables host key verification entirely for the connection. It resolves the error but also removes the security protection SSH provides. Use this only for internal networks or environments where MITM attacks are not a realistic threat.
In a command:
ssh -o StrictHostKeyChecking=no user@server
In a Git command:
GIT_SSH_COMMAND=”ssh -o StrictHostKeyChecking=no” git clone git@github.com:USERNAME/REPO.git
In an SSH config file:
Host github.com
StrictHostKeyChecking no
In a pipeline environment variable (some CI systems support this):
GIT_SSH_COMMAND=ssh -o StrictHostKeyChecking=no
Important: never set StrictHostKeyChecking=no globally in your personal SSH config on a machine you use for regular development. Limit it to the specific host or use it only in controlled CI environments.
Option C — Bake a known_hosts File Into Your Docker Image or CI Environment
For Docker-based CI/CD, generate the known_hosts file once and include it in your Dockerfile or base image:
RUN mkdir -p /root/.ssh && \
ssh-keyscan github.com >> /root/.ssh/known_hosts && \
chmod 700 /root/.ssh && \
chmod 600 /root/.ssh/known_hostsThis bakes the current GitHub host key into the image. The downside is that if GitHub rotates its keys, you’ll need to rebuild the image — but since key rotations are rare, this is manageable for most teams.
For non-Docker CI systems, the pipeline setup step (Option A) is more maintainable because it always fetches the current key at runtime.
Fix 6 — Fix the Error on Windows
The host key verification failed error on Windows behaves the same way fundamentally, but the file paths and tools are slightly different depending on whether you’re using Git Bash, WSL, Windows OpenSSH, or PuTTY.
Git Bash on Windows
Git Bash uses its own SSH client and stores known_hosts at:
C:\Users\USERNAME.ssh\known_hosts
The commands are identical to Linux/macOS:
ssh-keygen -R github.com
ssh-keyscan github.com >> ~/.ssh/known_hosts
Run these in Git Bash, not in Command Prompt or PowerShell.
Windows OpenSSH (PowerShell or Command Prompt)
Windows 10 and 11 ship with a native OpenSSH client. Its known_hosts file is also at:
C:\Users\USERNAME.ssh\known_hosts
In PowerShell:
ssh-keygen -R github.com
ssh-keyscan github.com | Out-File -Append -FilePath “$env:USERPROFILE.ssh\known_hosts”
Or open the known_hosts file in Notepad and manually delete the offending line, then run:
ssh-keyscan github.com >> $env:USERPROFILE.ssh\known_hosts
WSL (Windows Subsystem for Linux)
WSL has its own separate SSH configuration from Windows. The known_hosts file is inside the WSL file system at:
~/.ssh/known_hosts
(equivalent to /home/yourusername/.ssh/known_hosts inside WSL)
Use the standard Linux commands inside the WSL terminal:
ssh-keygen -R github.com
ssh-keyscan github.com >> ~/.ssh/known_hosts
PuTTY
PuTTY doesn’t use known_hosts. It stores host keys in the Windows registry at:
HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys
When PuTTY detects a changed host key, it shows a GUI dialog asking whether to update the stored key. If the key change is legitimate, click Accept. If you want to manually remove the old key, open Registry Editor (regedit), navigate to the path above, and delete the entry for the affected host.
Fix 7 — Prevent the Error Permanently With SSH Config
The previous fixes handle the error after it appears. This fix — configuring your SSH config file properly — helps prevent the error from disrupting your workflow and gives you fine-grained control over how SSH handles host key verification for different hosts.
Create or edit the file at ~/.ssh/config and add host-specific configuration:
For Regular Development Hosts (Full Verification)
This is the default and what you want for any host you regularly connect to:
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519
StrictHostKeyChecking yes
No special options needed — just ensure StrictHostKeyChecking is yes (the default) so SSH always verifies the host key.
For Frequently Rebuilt Servers (Accept New Keys Automatically)
If you work with servers that are regularly rebuilt (staging environments, development VMs, containers), you can set SSH to accept changed host keys for those specific hosts without prompting:
Host staging.mycompany.com
StrictHostKeyChecking accept-new
UserKnownHostsFile ~/.ssh/known_hosts
The accept-new value is key here — it tells SSH to automatically accept new keys for hosts it hasn’t seen before, but still reject connections where a stored key doesn’t match. It’s a middle ground between full strictness and completely disabling verification.
For Hosts With Dynamic IPs
If you’re connecting to hosts whose IP addresses change (cloud instances that get different IPs each time they’re spun up), you can use a custom known_hosts file or disable host key checking for that specific pattern:
Host 10.0.0.*
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
Using UserKnownHostsFile /dev/null sends all known_hosts data to the void — SSH doesn’t store or verify anything for matching hosts. This is appropriate only for internal, trusted networks where you control all the machines.
The Correct Global Default
Your global SSH config should have strict checking as the default:
Host *
StrictHostKeyChecking yes
ServerAliveInterval 60
ServerAliveCountMax 3
Put this at the bottom of your config file. More specific Host blocks above it will override these defaults for individual hosts.
Real Terminal Example — Full Diagnostic Session
Here’s a complete terminal session showing the error appearing, being diagnosed, and being fixed. This example simulates the GitHub key rotation scenario on a Linux machine:
$ git pull origin main
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be intercepting your network communications!
Host key for 'github.com' has changed
Offending RSA key in /home/user/.ssh/known_hosts:3
RSA host key for github.com has changed and you have requested
strict checking.
Host key verification failed.
fatal: Could not read from remote repository.$ cat ~/.ssh/known_hosts | grep github.com
github.com ssh-rsa AAAAB3NzaC1yc2EAAAA…oldkey…
[Old RSA key stored — this is from before the rotation]$ ssh-keygen -R github.comHost github.com found: line 3
/home/user/.ssh/known_hosts updated.
Original contents retained as /home/user/.ssh/known_hosts.old
$ ssh-keyscan github.com >> ~/.ssh/known_hosts
github.com:22 SSH-2.0-babeld-12345678
github.com:22 SSH-2.0-babeld-12345678
github.com:22 SSH-2.0-babeld-12345678
$ ssh-keygen -lf ~/.ssh/known_hosts | grep github.com
3072 SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s github.com (RSA)
256 SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM github.com (ECDSA)
256 SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU github.com (ED25519)
[Checked against GitHub's official fingerprints — all match]$ ssh -T git@github.com
Hi devuser! You've successfully authenticated, but GitHub does not provide shell access.
[Authentication confirmed working]
$ git pull origin main
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (3/3), 712 bytes | 356.00 KiB/s, done.
From github.com:devuser/my-project
a1b2c3d..e4f5g6h main -> origin/main
Updating a1b2c3d..e4f5g6h
Fast-forward
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[All working]Prevention Tips — How to Avoid This Error Going Forward
Once you’ve fixed the immediate problem, a few good habits will keep this error from catching you off guard again.
Tip 1 — Verify Fingerprints, Don’t Just Accept Them
When SSH asks “Are you sure you want to continue connecting?” for a new host, don’t just type yes out of habit. Take five seconds to check the fingerprint against the official documentation for that service. For GitHub, the fingerprints are at https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints. Getting into this habit means you’re actually using the security SSH provides rather than just bypassing it.
Tip 2 — Back Up Your known_hosts File
Your known_hosts file is a record of every SSH host you’ve ever verified and trusted. It’s worth including in any dotfile backup strategy alongside your .ssh/config and other SSH files. When you set up a new machine from your dotfiles, you’ll have a populated known_hosts file immediately rather than having to re-verify every server from scratch.
Tip 3 — Keep an Eye on GitHub’s and GitLab’s Security Announcements
When a major hosting service rotates their SSH host keys, they announce it in advance (or at least post a detailed explanation quickly). Follow GitHub’s blog and security changelog, or the equivalent for whichever platform you use. Knowing a key rotation happened puts you in the right frame of mind when you see the error — instead of troubleshooting blindly, you know exactly what to do.
Tip 4 — Bake known_hosts Into Your CI/CD Pipelines at the Start
Don’t leave CI/CD pipelines to encounter this error mid-run. Add the ssh-keyscan step as the very first thing in any pipeline that uses SSH. It takes two seconds to run and eliminates an entire class of pipeline failures. Make it a standard part of every new pipeline template in your organization.
Tip 5 — Use accept-new for Frequently Rebuilt Servers
If you manage servers that are regularly rebuilt — staging environments, ephemeral cloud instances, development VMs — configure accept-new in your SSH config for those specific hosts. It protects you from MITM attacks (because it still rejects mismatches for previously seen keys) while not requiring you to manually update known_hosts every time a server is rebuilt.
Tip 6 — Document Your Server’s SSH Fingerprints
For servers you manage, run ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub right after setup and save the fingerprint somewhere accessible — a password manager, a team wiki, or an internal runbook. When you or a teammate sees the host key verification error for that server, having the official fingerprint documented means you can verify it in seconds rather than guessing.
Tip 7 — Rotate Server SSH Keys Deliberately, Not Accidentally
Server host keys get regenerated when you rebuild the OS. If you want to preserve the same host key across a rebuild (to avoid triggering this error for your whole team), back up the key files from /etc/ssh/ before the rebuild and restore them afterward:
Backup:
sudo cp /etc/ssh/ssh_host_* /secure/backup/location/
Restore after rebuild:
sudo cp /secure/backup/location/ssh_host_* /etc/ssh/
sudo chmod 600 /etc/ssh/ssh_host_*_key
sudo systemctl restart ssh
FAQ
Q: Is the “Host key verification failed” error dangerous? Could I be under attack?
In most cases, no — it’s a routine configuration issue. But the security dimension is real. If you’re on an unfamiliar network (hotel, airport, conference wifi) and the error appears for a server or service you’ve successfully connected to many times before on trusted networks, treat it seriously. Don’t accept the new key until you’ve verified it through an out-of-band channel (official documentation, a direct call to the server admin, or the hosting provider’s console). On your home network or a trusted office network, a sudden mismatch is almost always caused by a server rebuild or a key rotation — not an attack. Use your judgment about the environment you’re on.
Q: Why does this error appear in GitHub Actions even though I haven’t changed anything?
GitHub Actions runners start fresh for every workflow run with no SSH state. There’s no known_hosts file. When the runner tries to connect to GitHub over SSH, it encounters the host verification prompt — and since CI runners can’t respond to interactive prompts, the connection fails. The fix is to add a ssh-keyscan step at the start of your workflow. See Fix 5, Option A for the exact GitHub Actions YAML.
Q: Can I just delete the entire known_hosts file and start over?
Yes, you can. Deleting ~/.ssh/known_hosts removes all stored host fingerprints. The next time you connect to any host, SSH will ask you to verify its fingerprint and store it fresh. This is a blunt approach — you lose all your stored fingerprints and have to verify everything again — but it works. For most individual developers this is fine. For a team shared environment or a machine that connects to many servers, it’s more disruptive.
rm ~/.ssh/known_hosts
Q: What does “Offending RSA key in /home/user/.ssh/known_hosts:5” mean?
It’s telling you that the conflicting key entry is on line 5 of your known_hosts file. You can open the file and delete that line manually, use ssh-keygen -R hostname to remove it automatically, or use sed -i ‘5d’ ~/.ssh/known_hosts to delete line 5 without opening an editor. The ssh-keygen -R approach is recommended because it handles all entries for that hostname regardless of line number.
Q: Why do I see this error after restoring my Mac or Linux machine from a backup?
Your backup included the ~/.ssh/known_hosts file with the fingerprints of servers as they were when the backup was taken. If any of those servers have since been rebuilt or rotated their keys, the stored fingerprints are now stale. Use ssh-keygen -R hostname for each server that’s causing the error, then reconnect to re-verify and store the current fingerprint.
Q: I’m seeing this error for a server I manage. How do I know if the key really changed or if something malicious happened?
Log into the server through your hosting provider’s web console or VNC (not SSH), and run ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub. Compare the fingerprint shown with what’s in your known_hosts file and with what ssh-keyscan returns from your local machine. If all three match, the server’s key genuinely changed (through a rebuild or update) and you can safely update known_hosts. If the ssh-keyscan result doesn’t match the key on the server itself, something more suspicious may be happening — consult your security team.
Q: How do I fix this in VS Code’s integrated terminal or remote SSH extension?
VS Code’s integrated terminal uses your system’s SSH configuration and known_hosts file, so the fixes described in this guide apply directly. Run the fix commands in the VS Code terminal and they’ll work the same as in a standalone terminal. For the Remote SSH extension specifically, if VS Code is caching connection details separately, go to the Remote Explorer panel, right-click the affected host, and select Remove. VS Code will re-establish the connection from scratch and re-verify the host key.
Q: Can this error happen with GitHub Desktop or other Git GUIs?
Yes. GitHub Desktop and other Git GUIs use the same underlying SSH infrastructure as the command line. The known_hosts file that the command line uses is the same one these applications use. Fix the error on the command line using the steps in this guide, and the GUI applications will benefit from the fix automatically.
Q: My whole team suddenly got this error for our company server. What’s the most likely cause?
Almost certainly the server was rebuilt, upgraded to a new OS, or migrated to different hardware — all of which generate a new SSH host key. If the error appeared for everyone on the team at the same time, it wasn’t a per-machine issue, it was a server-side change. Ask your devops or infrastructure team whether any server maintenance happened recently. Once the cause is confirmed as legitimate, everyone on the team can run ssh-keygen -R SERVER-HOSTNAME followed by ssh-keyscan SERVER-HOSTNAME >> ~/.ssh/known_hosts.
Related Errors
These SSH errors frequently appear alongside or instead of host key verification failed, and are part of the same family of SSH authentication and connection issues.
Permission denied (publickey)
The most common SSH error after host key verification failed. Where this guide covers server-side identity verification, the publickey error covers client-side identity verification — your machine proving its identity to the server. If you fix the host key verification error and then hit “Permission denied (publickey),” you need to set up or re-load your SSH key pair. The full guide covers this error in detail.
ssh: connect to host github.com port 22: Connection refused
The connection was refused before host verification even happened. Usually means port 22 is blocked by a firewall or network policy. The fix is to use SSH over HTTPS port 443. Add this to ~/.ssh/config:
Host github.com
Hostname ssh.github.com
Port 443
User git
WARNING: UNPROTECTED PRIVATE KEY FILE
Your private key file has permissions that are too open — SSH refuses to use it. Fix the file permissions:
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh
fatal: Could not read from remote repository
A catch-all Git error that appears when SSH can’t complete authentication for any reason. This often appears as a consequence of host key verification failing. Fix the underlying SSH error first and this error will resolve itself.
ssh_exchange_identification: Connection closed by remote host
The remote server closed the connection before the SSH handshake completed. Can indicate a firewall rule, a server-side SSH configuration issue, or the server being under heavy load. Different from host key verification failure — the server never got to the point of presenting a host key.
no hostkey alg
Appears in older SSH clients when the server supports key algorithms that the client doesn’t recognize. Usually resolved by updating the SSH client or specifying a compatible algorithm in ~/.ssh/config:
Host myserver.com
HostKeyAlgorithms ssh-ed25519,ecdsa-sha2-nistp256,ssh-rsa
Conclusion
The “Host key verification failed” error deserves both the alarm it raises and the measured response it requires. SSH designed this warning to catch a real class of attack — and understanding that makes you a better engineer, not just someone who knows the command to suppress it.
In practice, though, almost every occurrence of this error in a normal development workflow comes down to something benign: GitHub rotated its keys, a server was rebuilt, a CI container started fresh, or a known_hosts file got stale. Fix 1 (removing the specific offending entry with ssh-keygen -R) and Fix 2 (adding the current key with ssh-keyscan) handle the vast majority of cases in under 60 seconds.
The GitHub-specific rotation scenario has its own dedicated Fix 3, and it’s worth bookmarking because GitHub will rotate keys again in the future. CI/CD environments need Fix 5 baked into every pipeline template from the start. And if you’re on Windows, Fix 6 covers the subtle differences between Git Bash, WSL, and Windows OpenSSH.
What ties all of this together is the principle at the heart of SSH: verify first, trust after. When you run ssh-keyscan and then check the fingerprint against official documentation before accepting it, you’re using SSH the way it was designed to be used — not just working around its warnings, but actually validating them. That habit is worth building.
If the error is still persisting after working through every fix in this guide, run ssh -vvv git@github.com and read the verbose output carefully. It logs every step of the SSH connection attempt, and the line where it fails will point directly to what’s left to resolve.
Related Resources
GitHub Docs — GitHub’s SSH key fingerprints
GitHub API — Current SSH host keys (machine-readable)
GitHub blogs – Github related collection of blogs
About the Author
Kedar Salunkhe
DevOps Engineer | Seven years of fixing things that break at 2am
Kubernetes • OpenShift • AWS • Coffee
I’ve spent almost 7 years keeping production systems running, often when everyone else is asleep. These days I’m working with Kubernetes and OpenShift deployments, automating everything that can be automated, and occasionally remembering to document the things I fix. When I’m not troubleshooting clusters, I’m probably trying out new DevOps tools or explaining to someone why we can’t just “restart everything” as a debugging strategy. You can usually find me where the coffee is strong and the error logs are confusing.