Verify GitHub's SSH host key the first time you connect

The first time you connect to GitHub over SSH, your client asks you to trust a host key. Do not just type yes. Compare the fingerprint to the ones GitHub publishes, or add GitHub's published host key entries to known_hosts ahead of time, which is the right approach for CI and new machines.

Why the prompt exists

SSH has no certificate authority by default. The first connection records the server's key, and later connections check against it. If someone intercepts that first connection, you could record the wrong key. Comparing the fingerprint with a trusted source closes that gap.

What GitHub publishes

GitHub publishes its SSH public key fingerprints in its documentation. The key types listed include RSA, DSA (described as closing down), ECDSA and Ed25519. It also points to its REST API meta endpoint for the keys. I have not reproduced the fingerprints here; copy them from the official page so you are reading the current values.

Two ways to do it

1. Interactive check. When prompted, compare the fingerprint your client shows to the published one. Accept only on a match.
2. Pre-seed known_hosts. Add GitHub's published host key entries to the known_hosts file before the first connection. Your client then trusts them with no prompt.

For CI runners and container builds, pre-seeding is better than disabling host key checking. Turning checking off removes the protection entirely.

Mistakes to avoid

• Using a setting that disables strict host key checking in a pipeline script.
• Copying a host key from a blog post or old gist rather than the official page.
• Ignoring a warning that a host key has changed. That warning can mean a rotation or an interception, so check GitHub's current published keys before you proceed.

Habits for teams

Keep the known_hosts entries in a shared, reviewed file in your image or bootstrap script, with a comment linking the official page. Revisit it when GitHub announces changes. Also prefer SSH keys with passphrases or hardware backing for people, and short lived credentials for automation; see Git credential managers.

For laptops, the one time check is enough. For fleets, a managed known_hosts file is better, because it removes the decision from every individual. Include it in your base image or your configuration management, and treat a change to it like any other security change, with a reviewer. If you use more than one Git host, keep a separate documented source for each host rather than copying a combined list from an unknown origin.

If you keep the entries in a repository, add a note with the date you last compared them to GitHub's published values. That date tells the next engineer how stale the file is. For build systems, fetch the entries from your own reviewed copy, not live from the internet at build time, because a live fetch repeats the original trust problem.

Quick check

Sources

• GitHub's SSH key fingerprints, GitHub Docs

Last reviewed: 19 October 2026.