GitHub SSH Brownout November 2026 Explained: The 4 November Brownout, the 13 January Removal and How to Check Your Setup

GitHub SSH brownout November 2026 — the GitHub mark

Image: GitHub — the GitHub mark (official logo, via Wikimedia Commons, CC BY 4.0). The SSH changes in this post apply to every developer who connects to GitHub over SSH.

TL;DR: GitHub SSH brownout November 2026 in one line: GitHub's first brownout of two legacy SSH algorithms was scheduled for 4 November 2026 — the ssh-rsa signature (RSA with SHA-1) and the diffie-hellman-group-exchange-sha256 key exchange were switched off temporarily, and both are permanently removed on 13 January 2027. Most developers are unaffected, but old SSH clients and CI runners can fail — check yours now.

📌 KEY HIGHLIGHTS

  • The change: GitHub announced on 22 September 2026 that it will stop accepting RSA signatures that use SHA-1 (the ssh-rsa signature type) and the diffie-hellman-group-exchange-sha256 key exchange.
  • The dates: first brownout 4 November 2026, second brownout 9 December 2026, permanent removal 13 January 2027.
  • New keys: RSA keys uploaded after 14 October 2026 must be at least 3,072 bits. GitHub also switched on a hybrid post-quantum key exchange, mlkem768x25519-sha256.
  • Your existing key usually still works: the problem is old clients, not old keys — if your client signs with rsa-sha2-256 or rsa-sha2-512, your RSA key keeps working.
  • HTTPS users are unaffected: Git remotes that start with https:// never negotiate these SSH algorithms.

GitHub SSH brownout November 2026: what actually changed

A brownout is not an outage. It is a planned, temporary switch-off of something that is about to be removed for good — GitHub turns the old algorithms off for a while so that anything still depending on them fails loudly, while there is still time to fix it. The idea is to surface broken setups in November and December, not on the day the algorithms disappear in January.

GitHub's announcement, published in its changelog on 22 September 2026, makes four changes. Two are removals: the ssh-rsa signature type, which is an RSA key signing with SHA-1 (including RSA certificates that use SHA-1), and the diffie-hellman-group-exchange-sha256 key-exchange method. One is stricter: every new RSA SSH key uploaded after 14 October 2026 must be at least 3,072 bits, for both signing in and signing commits. And one is an addition: the hybrid post-quantum key exchange mlkem768x25519-sha256, switched on the same day on github.com and GitHub Enterprise Cloud with Data Residency, except the US region. For self-hosted GitHub Enterprise Server, the removals arrive in version 3.25 and the post-quantum key exchange in 3.24.

GitHub gave no time of day or duration for the brownouts, so this post does not claim a specific hour when connections failed — the schedule is the fact, and the schedule is what teams should plan around.

DateWhat happens
22 September 2026GitHub announces the SSH changes in its changelog
14 October 2026New RSA keys must be at least 3,072 bits; mlkem768x25519-sha256 key exchange enabled
4 November 2026First brownout — ssh-rsa and the old Diffie-Hellman key exchange switched off temporarily
9 December 2026Second brownout
13 January 2027Permanent removal of both legacy algorithms

GitHub SSH brownout November 2026 — server racks in a data centre

Illustrative image: server racks in a data centre — the kind of machines developers and CI runners reach over SSH. Image: Wikimedia Commons (CC0).

Does your RSA key still work? The key-versus-signature confusion

This is the part most people get wrong, and GitHub's own announcement spends time on it. The name ssh-rsa means two different things. It is the key type of every RSA public key — a key file that starts with "ssh-rsa" is normal. It is also the name of a signature type: an RSA key signing with SHA-1. The same RSA key can sign with SHA-1 (ssh-rsa), SHA-256 (rsa-sha2-256) or SHA-512 (rsa-sha2-512), and only the SHA-1 option is being removed.

So an existing RSA key usually keeps working, as long as the software doing the connecting signs with SHA-2. GitHub lists the minimum client versions that do this reliably with default settings: OpenSSH 7.2p1, PuTTY 0.82, libssh2 1.11.0, Go SSH 0.16.0 and TeamCity 2021.2.3. Those are minimums, not recommendations — a current, maintained client is always the better choice, because it also carries years of other security fixes. And the keys most at risk are the oldest ones: since March 2022, only RSA keys added before 2 November 2021 can sign with SHA-1 on GitHub at all.

For new keys, GitHub recommends Ed25519 where the environment supports it. If RSA is needed for compatibility with other systems, generate a key of at least 3,072 bits — the 2,048-bit default that older ssh-keygen versions still produce is now rejected on upload. Do not "fix" a failing connection by re-enabling SHA-1 in your SSH config: that restores the exact path GitHub is removing, and it will stop working again on 13 January 2027.

How to check your setup in two minutes

First, find out whether you even use SSH. In a repository, run git remote -v: a remote that starts with git@github.com uses SSH, while one that starts with https://github.com does not touch these algorithms at all. Second, check your client version with ssh -V and compare it with the minimums above — anything from the last decade is almost certainly fine on a laptop; the risk lives in old build containers, self-hosted runners, deployment appliances and embedded Git clients that nobody has updated in years.

Third, test the connection itself with ssh -T git@github.com. A working account gets GitHub's message that shell access is not provided — that is a pass, not an error, and the command changes nothing in any repository. If it fails, run it with -v and look at which algorithms were negotiated: "Permission denied (publickey)" points at a signature problem, while "unable to negotiate" points at the key exchange. Finally, repeat the test from the environment that actually runs your automation, not just your laptop — a project can look healthy in local development while its release pipeline fails, because the runner uses a different SSH library.

Why it matters for World Tech readers — including in India

No India-specific advisory is attached to this change, and this post invents none. The relevance is practical: GitHub is where a huge share of India's students, freelancers and startup teams keep their code, and SSH is the default way many of them connect. A laptop running a recent OpenSSH will not notice the brownouts at all. The people who will notice are teams with old CI setups — a self-hosted runner on an unpatched image, a deployment script pinned to an old library, a build server nobody has touched since 2023. Those are exactly the systems that fail silently at 2 AM during a release, which is why GitHub runs brownouts first.

The same week's developer-tooling news points the same way: see our Visual Studio Code 1.145 update and our Xcode 27.3 beta explainer — and the credential-hygiene lesson from our Gheist GitHub stolen-tokens incident still applies: your GitHub access is only as safe as the oldest client holding a key to it.

Should you care?

✅ If you push code to GitHub over SSH: yes — run the two-minute check above, and do it on your CI runners and old servers too, not just your laptop. The fix is usually a client update, not a new key. ⏳ If you use HTTPS remotes, or a modern SSH client: nothing to do. But put 13 January 2027 on your list anyway — that is when the old algorithms stop working for good, and an old tool surfacing then is worse than one surfacing now.

FAQs

Will GitHub SSH stop working on November 4?
Not for most users. GitHub scheduled a temporary brownout affecting only clients that depend on the two deprecated algorithms — the ssh-rsa signature and the diffie-hellman-group-exchange-sha256 key exchange. Modern, compatible clients keep working through it.

Do I need to replace my RSA SSH key?
Usually not. An existing RSA key keeps working when your SSH client signs with rsa-sha2-256 or rsa-sha2-512. The 3,072-bit minimum applies only to RSA keys newly uploaded after 14 October 2026.

Does this affect HTTPS Git connections?
No. GitHub states that Git remotes beginning with https:// are outside the scope of these SSH changes — they never negotiate SSH algorithms.

When will the old algorithms be permanently removed?
On 13 January 2027, following brownouts on 4 November and 9 December 2026. GitHub Enterprise Server gets the removals in version 3.25.

Takeaway: GitHub's SSH clean-up is a scheduled retirement, not a surprise outage — the 4 November brownout was the rehearsal, and 13 January 2027 is the real deadline. Check your client once, especially on CI runners, and the removal will pass you by.

Follow World Tech on TechByCountry for tomorrow's 6 PM update.

📸 Get tech in the last 24 hours on Instagram — follow @_techinlast24hrs for daily posts (9 AM–9 PM) and reels at 12:30 PM & 8:30 PM.

Sources

Comments