GitHub RSA SSH Host Key Exposure 2023: How One Leaked Private Key Forced a Global Key Rotation

In March 2023, GitHub found that the private half of GitHub.com's RSA SSH host key, the key that proves to every developer's Git client that it is really talking to GitHub, had been briefly exposed in a public GitHub repository. At about 05:00 UTC on 24 March 2023 GitHub replaced the key "out of an abundance of caution", and its chief security officer, Mike Hanley, announced the change in a blog post the same morning (dated 23 March in US time). GitHub said the exposure was an inadvertent publication, not a compromise of its systems, that the key did not grant access to its infrastructure or customer data, and that it had no reason to believe the key was abused. The cost of the rotation still fell on users: anyone who connected over SSH with RSA saw a host identification warning and had to update their known hosts. GitHub has not said how long the key was exposed or how it came to be committed.

At a glance

What happened

When a developer runs git clone or git push over SSH, their client checks GitHub's host key against the copy stored in its known hosts file. That check is what stops an attacker from posing as GitHub. GitHub.com offered RSA, ECDSA and Ed25519 host keys, and the RSA key was the one many older clients and scripts relied on.

On 24 March 2023 GitHub published a short post by Mike Hanley, its chief security officer and senior vice president of engineering. "This week, we discovered that GitHub.com's RSA SSH private key was briefly exposed in a public GitHub repository," he wrote. "We immediately acted to contain the exposure and began investigating to understand the root cause and impact." GitHub said it replaced the key at approximately 05:00 UTC on 24 March and that the change would propagate over the next thirty minutes. Some users had noticed the new key appear from around 02:30 UTC during preparations.

GitHub stressed what the key could not do. "This key does not grant access to GitHub's infrastructure or customer data," the post said, and "this issue was not the result of a compromise of any GitHub systems or customer information." It called the cause "an inadvertent publishing of private information" and said: "We have no reason to believe that the exposed key was abused". Only Git operations over SSH using RSA were affected. Web traffic, Git over HTTPS and users of the ECDSA and Ed25519 keys needed to do nothing.

BleepingComputer pointed out that GitHub did not say when the exposure began or how long it lasted, and that the discovery came weeks after GitHub had rolled out secret scanning for all public repositories. GitGuardian's Dwayne McDaniel explained the real risk: with the private key, an attacker in a position to intercept traffic could impersonate GitHub. He also warned of a second risk created by the fix itself, since developers told to delete the old key might accept whatever new key they were shown without checking it. His advice was "verify, only then trust."

Timeline

How it happened: the identity attack path

1. A service-wide machine identity. GitHub.com's RSA host key identified the service to every SSH client that connected with RSA, so it was trusted by a very large number of machines and scripts.
2. Private key published. The private half of that key was pushed to a public GitHub repository. GitHub has not said by whom or how; it describes the event as inadvertent.
3. Exposure window. The key was public for an undisclosed, brief period until GitHub found it. Anyone who copied it in that window could, in principle, impersonate GitHub to clients that trusted the RSA key.
4. Rotation as the only remedy. A host key cannot be scoped or partly revoked, so GitHub had to replace it for everyone, which broke cached trust in clients and some GitHub Actions workflows.
5. Re-establishing trust. Users had to remove the old key and add the new one, ideally after checking the fingerprint GitHub published, or risk trusting an impostor's key instead.

Impact

• Confirmed: GitHub replaced its RSA SSH host key worldwide. SSH users who connected with RSA saw a "remote host identification has changed" warning and had to update their known hosts. GitHub said workflows using actions/checkout with the ssh-key option could fail until the action was updated, and that workflows pinned to a commit SHA needed changes.
• Not confirmed: misuse of the exposed key. GitHub said it had no reason to believe the key was abused and that the key gave no access to its infrastructure or customer data.
• Potential: while the key was public, an attacker able to intercept a victim's network traffic could have impersonated GitHub to SSH clients or eavesdropped on Git operations. During the rotation, users who skipped fingerprint checks were exposed to accepting a malicious key.

What this means for NHI governance

Host keys are rarely on anyone's list of non-human identities, yet they are some of the most widely trusted credentials on the internet. GitHub's RSA key was effectively the identity of GitHub itself for SSH clients. One accidental push put it in public view, and because there is no way to revoke a host key gracefully, the only safe response was a disruptive global rotation. The same pattern applies to code signing keys, TLS private keys and GitHub App private keys: long-lived, high-trust and painful to replace.

The case also shows that strong detection is not the same as prevention. GitHub had just rolled out secret scanning for all public repositories and still found its own key in a public repository. Keeping private keys in hardware or a key management service, so they cannot be copied into a repository at all, and rehearsing rotation so it can happen quickly and safely, are the controls that matter. Our SSH Key Management Guide and Cryptographic Key Management Guide cover both. A larger, later example is the 474 GitHub App private keys found leaked in 2026.

Recommendations

• Rotate a leaked private key immediately, even without evidence of abuse. GitHub replaced its key within days of discovery. Treat any private key seen in public as compromised. See the Leaked Credential Response Playbook.
• Keep high-value private keys where they cannot be copied. Store host, signing and TLS keys in hardware security modules or a managed key service so that no engineer or pipeline ever handles the raw key. See our Cryptographic Key Management Guide.
• Verify new host keys before trusting them. Compare fingerprints with the values the provider publishes, or fetch keys from an authenticated source, rather than accepting the first key you see. See our SSH Key Management Guide.
• Prefer SSH certificates over pinned static keys. Host certificates signed by a certificate authority make rotation and verification easier than a single static key pinned in every client. See our Machine Identity, PKI and Certificate Lifecycle Guide.
• Block private keys at commit time. Use pre-commit hooks and push protection so that a private key cannot reach a public repository in the first place, and scan history for keys already there.
• Rehearse rotation for every critical key. Know which clients, scripts and CI workflows pin a key, and test the change so that a real rotation does not break builds.

Frequently asked questions

Why did GitHub change its RSA SSH host key in 2023?

GitHub found that the private half of its RSA SSH host key had been briefly exposed in a public GitHub repository. On 24 March 2023 it replaced the key out of caution, so that nobody holding the old key could impersonate GitHub or eavesdrop on Git operations over SSH.

Was the GitHub SSH private key exploited?

There is no evidence it was. GitHub said it had no reason to believe the key was abused, that the exposure was an inadvertent publication rather than a compromise, and that the key did not grant access to its infrastructure or customer data. It has not said how long the key was exposed.

What did users need to do after the GitHub host key change?

Users who connected to GitHub over SSH with RSA had to remove the old GitHub entry from their known hosts file and add the new key, checking it against the fingerprint GitHub published. Users of ECDSA or Ed25519 keys and HTTPS did not need to act. Some GitHub Actions workflows also needed updating.

Related NHI Mgmt Group resources

474 GitHub App private keys leaked 2026 · Microsoft Storm-0558 key breach 2023 · SSH Key Management Guide · Cryptographic Key Management Guide · Leaked Credential Response Playbook

How NHI Mgmt Group can help

Host keys, signing keys and certificates are machine identities that whole ecosystems trust, and few organisations have an inventory of them or a tested plan to rotate them. We help teams find these keys, move them into protected storage and rehearse rotation before they need it. See our NHI and AI agent security training.

References

• GitHub Blog (Mike Hanley): We updated our RSA SSH host key (23 March 2023)
• BleepingComputer: GitHub.com rotates its exposed private SSH key (24 March 2023)
• Dark Reading: GitHub's Private RSA SSH Key Mistakenly Exposed in Public Repository (24 March 2023)
• GitGuardian: GitHub Exposed A Private SSH Key: What You Need To Know (24 March 2023)