GitHub RSA SSH Key Rotation Incident: Why It Mattered

On March 24, 2023, GitHub replaced its RSA SSH host key after the private key was briefly exposed in a public GitHub repository. While GitHub moved quickly and no evidence of exploitation was found, this incident exposed a supply chain risk hiding in plain sight: the SSH host key that millions of developers trust every time they push or pull code.

Note: While GitHub disclosed this in March, the implications for SSH key management were a growing concern throughout early 2023. This analysis covers what happened and why it matters.

The Incident

GitHub's RSA SSH host key — the cryptographic key that proves you're actually connecting to GitHub and not an impersonator — was accidentally committed to a public repository. The key was the private portion of the host key, meaning anyone who obtained it could theoretically impersonate GitHub's SSH servers.

GitHub's response was swift:

1. Detected the exposure
2. Generated a new RSA SSH host key
3. Replaced the old key on GitHub.com
4. Published the new key fingerprint
5. Communicated the change to users

The immediate impact was that every developer who connects to GitHub over SSH saw a scary warning message:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

For security-conscious developers, this warning is working as designed — it's telling you the server's identity changed, which could indicate a man-in-the-middle attack. The problem is what many developers actually did when they saw it.

The Human Factor

When millions of developers saw the host key warning, the most common response was to Google "how to fix SSH host key error" and follow instructions to delete the old key and accept the new one. In this case, that was the right thing to do because GitHub had actually changed the key. But it reinforced a dangerous habit.

Training users to dismiss SSH host key warnings is exactly what makes man-in-the-middle attacks effective. The next time a developer sees this warning, it might be because an attacker is intercepting their connection, and they'll dismiss it just as quickly.

Supply Chain Implications

Git as Critical Infrastructure

Virtually every software supply chain in existence depends on Git, and a massive portion of that traffic flows through GitHub. The SSH host key is the root of trust for those connections. If an attacker had obtained the exposed key before GitHub rotated it, they could have:

• Intercepted code pushes: Captured source code as developers pushed to GitHub
• Modified code in transit: Altered source code during push or pull operations without detection
• Stolen credentials: Captured SSH authentication tokens and private keys used to authenticate with GitHub
• Injected malicious code: Modified pull responses to deliver backdoored versions of repositories

CI/CD Pipeline Exposure

The impact extends far beyond individual developers. Every CI/CD system that pulls code from GitHub over SSH had the old host key fingerprint cached. Automated systems are often configured to be less strict about host key verification — many use StrictHostKeyChecking=no in their SSH configurations to avoid exactly this kind of interruption.

Those systems were potentially vulnerable even after GitHub rotated the key, because an attacker with the old private key could impersonate GitHub to systems that hadn't updated their known_hosts files.

Dependency Resolution

When your build system resolves dependencies from GitHub (Go modules, npm packages with git dependencies, Cargo crates with git sources), those Git operations rely on the same SSH trust chain. A compromised host key could allow an attacker to serve malicious versions of dependencies to build systems.

The Larger Key Management Problem

This incident highlights a systemic issue: most organizations have no inventory of the SSH keys they trust and no process for key rotation.

What Most Organizations Don't Know

• How many SSH host keys are in their known_hosts files
• When those keys were last rotated
• Which automated systems have which host keys cached
• Whether their CI/CD pipelines verify host keys at all

The Rotation Challenge

When GitHub rotated their key, well-prepared organizations updated their known_hosts files across all systems within hours. Poorly prepared organizations dealt with broken builds, failed deployments, and confused developers for days.

Key rotation should be a routine operation, not an emergency response. But most organizations have never practiced rotating the host keys for the external services they depend on.

Lessons Learned

1. Automate known_hosts Management

Don't rely on individual developers to manage SSH keys on their machines. Use configuration management to maintain consistent known_hosts files across your organization.

2. Prefer HTTPS Where Possible

GitHub supports both SSH and HTTPS for Git operations. HTTPS with token authentication uses the standard certificate authority trust chain, which has more mature infrastructure for key rotation and revocation.

3. Verify Host Keys Through Multiple Channels

When a host key changes, verify the new fingerprint through an independent channel — GitHub's blog post, their API, their documentation — before accepting it.

4. Audit CI/CD SSH Configurations

Search for StrictHostKeyChecking=no in your codebase and CI/CD configurations. Every instance is a place where an SSH-based supply chain attack could succeed.

5. Plan for Key Rotation

Have a documented process for updating SSH host keys across your organization. Test it before you need it in an emergency.

How Safeguard.sh Helps

Safeguard.sh strengthens the trust chain in your software supply chain:

• Artifact Integrity Verification: Safeguard.sh verifies the integrity of source code and build artifacts independent of the transport layer, catching modifications even if SSH or HTTPS connections are compromised.
• SBOM Comparison: By comparing SBOMs across builds, Safeguard.sh detects unexpected changes in dependencies or source code that might indicate a man-in-the-middle modification.
• Configuration Auditing: Safeguard.sh scans your infrastructure configurations for insecure patterns like disabled host key checking, helping you identify weak points in your supply chain trust model.
• Continuous Supply Chain Monitoring: Rather than relying solely on transport security, Safeguard.sh provides end-to-end supply chain visibility, ensuring that what you build is what you intended, regardless of how it was transmitted.

The GitHub SSH key incident was a wake-up call about the fragility of the trust mechanisms underlying our software supply chains. The SSH host key is just one link in a long chain, and every link needs to be monitored.