GitHub sets October 14 SSH key deadline and November 4 brownout
GitHub will require new RSA SSH keys to be at least 3072 bits from October 14 and will brown out SHA-1 RSA signatures and an older Diffie-Hellman exchange on November 4. Developers using SSH remotes should check client support and key configuration before the rollout.
GitHub will tighten SSH compatibility in stages. New RSA keys uploaded after October 14, 2026 must be at least 3072 bits, while GitHub plans brownouts for SHA-1 RSA signatures and the diffie-hellman-group-exchange-sha256 key exchange on November 4 and December 9.
The change affects Git clients and SSH libraries that connect to GitHub. HTTPS remotes are outside the scope. Existing RSA keys do not automatically need replacement if the client negotiates rsa-sha2-256 or rsa-sha2-512; older clients and automation deserve an explicit check.
GitHub is removing weak SSH paths in stages
GitHub says it will remove the ssh-rsa signature type that uses SHA-1 and the diffie-hellman-group-exchange-sha256 key exchange. It is also adding mlkem768x25519-sha256 for GitHub.com and GitHub Enterprise Cloud with Data Residency, except for the U.S. region.
The first operational deadline is October 14: newly uploaded RSA keys must be at least 3072 bits. The first brownout is scheduled for November 4, followed by another on December 9. GitHub’s page also lists a final removal date, but the displayed year is inconsistent with the surrounding 2026 schedule; teams should confirm that date against a current GitHub update before treating it as a final migration deadline.

What SSH users need to check
GitHub distinguishes the generic RSA key type from the ssh-rsa signature algorithm. An existing RSA key can continue to work when the client supports SHA-2 signatures. The practical checks are:
- Inspect
git remote -vand identify repositories still using SSH rather than HTTPS. - Check the SSH client or library version used by developer machines, CI runners, deployment tools, and hosting integrations.
- Confirm that RSA authentication negotiates
rsa-sha2-256orrsa-sha2-512. - Prefer a new Ed25519 key for systems that can accept it; if RSA is required, generate at least a 3072-bit key.
- Test non-interactive CI and release jobs, not only a local
git clone.
GitHub says clients that support the new post-quantum exchange can prefer it automatically. Older clients should fall back to another supported exchange, but that fallback is not a reason to postpone upgrades: the removed algorithms will be exercised during the brownouts.
Why the post-quantum addition matters
The GitHub change is partly a compatibility cleanup and partly a cryptographic transition. SHA-1 signatures are considered weak, and the older Diffie-Hellman exchange is being removed as GitHub adopts a post-quantum hybrid option. OpenSSH’s release notes show the broader ecosystem is still tightening SSH validation, key handling, and protocol behavior, so GitHub’s policy should be treated as part of a client-and-automation maintenance cycle rather than a GitHub-only setting.
For teams with many repositories, record the SSH implementation and key type alongside runner images and deployment tooling. That turns a brownout into a controlled compatibility test instead of an incident during a release window.
Evidence and next milestone
GitHub’s published schedule puts the new RSA-key requirement on October 14, 2026 and the first algorithm brownout on November 4. The next useful action is a repository-wide inventory of SSH clients and CI integrations, followed by a test against supported RSA-SHA-2 or Ed25519 configurations.
Sources: GitHub’s SSH security changelog and OpenSSH release notes.
Try the related loot
Give Any Model a Sandboxed Shell and File Workspace with OpenRouter
