Host key verification failed. followed by fatal: Could not read from remote repository. on a git clone over SSH means the SSH client has no record of the server's host key and nobody could answer its question about it. Add the server's key to ~/.ssh/known_hosts after checking its fingerprint, then clone again.

The fix is to fetch the key with ssh-keyscan and print its fingerprint with ssh-keygen -lf (both run here), compare that fingerprint with the list GitHub publishes, and only then append the key to known_hosts. Turning off host key checking is not a fix; it removes the check that this message is there for.

The error

$ git clone git@github.com:octocat/Hello-World.git < /dev/null
Cloning into 'Hello-World'...
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
exit=128

Why it happens

The clone ran in a fresh container with no ~/.ssh folder at all, so there was no known_hosts entry for github.com. The container ran without a terminal (no -t), the way a CI job, a Docker build or a script does, so there was nowhere to accept the key. The connection stopped at that point and Git reported it as a remote it could not read, with exit code 128.

The second half of the message, about access rights and the repository existing, is Git's generic text for a failed transport. In this run the repository is public and the problem was the host key alone, as the next run shows.

The fix

$ mkdir -p ~/.ssh
$ ssh-keyscan -t ed25519 github.com > /root/github.keys
exit=0
$ ssh-keygen -lf /root/github.keys
256 SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU github.com (ED25519)
$ cat /root/github.keys >> ~/.ssh/known_hosts
$ git clone git@github.com:octocat/Hello-World.git < /dev/null
Cloning into 'Hello-World'...
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
...

After the key went into known_hosts, the host key message was gone. The clone then failed one step further on, because the container had no SSH key of its own; that is a separate error with its own post, linked below. The fingerprint printed by ssh-keygen -lf is the value to compare with GitHub's published SSH key fingerprints before you trust the key. The fingerprint in this capture is the Ed25519 one listed on that page when it was read on November 6, 2026. ssh-keyscan fetches whatever key the server on the other end presents, so the comparison is the part that makes this safe. In a CI system, store the checked line and write it to known_hosts in the job rather than scanning on every run.

How it was reproduced

In a throwaway alpine container with git 2.54.0 and OpenSSH_10.3p1 installed by apk add --no-cache git openssh-client, no SSH key and no known_hosts, a git clone of the public octocat/Hello-World repository over SSH with input closed. Nothing on the host machine's SSH setup was read or changed; the container was removed afterwards.

Frequently asked

How do I fix Host key verification failed in git clone?
Add the server's host key to ~/.ssh/known_hosts. Fetch it with ssh-keyscan, print its fingerprint with ssh-keygen -lf, compare it with the fingerprint the host publishes, then append the line to known_hosts and clone again.
Why does Host key verification failed happen in Docker or CI?
In this test the container had no known_hosts file and ran without a terminal (no -t), the way a CI job, a Docker build or a script does, so there was nowhere to accept the unknown key and the connection stopped.
Should I set StrictHostKeyChecking=no to fix it?
No. That turns off the check that confirms you are talking to the real server. Put a verified key into known_hosts instead.

The next error after this one is Permission denied (publickey). More decoded errors in the Fixes category.