Cafiyn Pulse
← Startup Signals
5 min readUpdated 2026-09-25Issue 4

GitHub is switching off SHA-1 SSH keys. Find out now whether yours is one of them.

The keys at risk are the old ones, on the machines nobody logs into, in the pipelines that have run untouched for three years. Those are also the ones that will fail loudest.

ByKarthik KumarCafiyn Innovations
At a glance
Announced
22 September 2026
14 October 2026
New RSA keys must be at least 3072 bits, signing and authentication
4 November 2026
First brownout of ssh-rsa and diffie-hellman-group-exchange-sha256
9 December 2026
Second brownout
Final removal
The changelog prints a date that predates its own brownouts, so treat it as unconfirmed
Also on 14 October
mlkem768x25519-sha256 enabled on github.com

What is being removed

GitHub is removing the ssh-rsa signature type, which means RSA keys signed with SHA-1, and the diffie-hellman-group-exchange-sha256 key exchange algorithm. This is not the same as removing RSA keys. An RSA key can be used with a modern SHA-2 signature algorithm, rsa-sha2-256 or rsa-sha2-512, and those are unaffected. What is going away is the SHA-1 signature variant.

The distinction matters because it means the answer to "am I affected" is not visible from looking at your key file. The same key can negotiate either signature type depending on what the client and server agree on, which is determined by your OpenSSH version and configuration, not by the key itself.

The dates

From 14 October 2026, all new RSA SSH keys uploaded to GitHub must be at least 3072 bits, for both signing and authentication. Existing keys are not retroactively rejected by this particular rule, but it does mean you cannot upload a replacement 2048-bit key after that date.

Two brownouts follow, on 4 November and 9 December 2026. A brownout is a deliberate temporary outage of the deprecated mechanism: connections relying on ssh-rsa fail for a window, then work again. It exists so you discover the problem on a date GitHub chose rather than on the date of final removal.

The changelog also lists a final removal date, but it prints a year that falls before the brownouts listed above it on the same page. That is almost certainly a publishing error, and we are not going to guess the intended year. Check the changelog itself before you rely on a final date.

One addition rather than a removal: the same 14 October date enables mlkem768x25519-sha256, a post-quantum key exchange, on github.com.

How to find out what you actually negotiate

Do not audit this from your laptop alone. Your laptop probably has a recent OpenSSH and will negotiate something modern without you ever knowing there was a question. The risk lives in the environments you do not interactively use.

Run a verbose SSH connection from each environment and read what it reports, rather than inferring from key types.

  • Run ssh -v git@github.com from your CI image, not just your laptop, and read the negotiated server host key algorithm and key exchange
  • Do the same on any deploy box, bastion, build agent or container image that clones over SSH
  • Check older base images specifically. An image pinned to an old distribution release carries an old OpenSSH
  • List repository deploy keys and organisation SSH keys and note the type and bit length of each
  • Check any automation that uses a key generated years ago and has not been touched since, which is where 2048-bit RSA tends to survive

What to do about what you find

The simple answer for almost every case is to move to ed25519. It is smaller, faster, has no bit-length question to get wrong, and is supported everywhere GitHub is. Generate with ssh-keygen -t ed25519, add the new key, confirm it works, then remove the old one.

Where you genuinely need RSA, for example because some other system in the chain requires it, generate at 3072 bits or more so the key remains uploadable after 14 October.

Also worth doing while you are in there: deploy keys and organisation keys accumulate. An audit prompted by a deprecation is a good moment to delete the ones belonging to a former contractor, a retired CI system, or a project that shipped two years ago.

What to do

  1. 1Run ssh -v git@github.com from every CI image and deploy environment, not only your laptop.
  2. 2Rotate any key negotiating ssh-rsa, and any RSA key under 3072 bits, to ed25519.
  3. 3Upload replacement RSA keys before 14 October 2026 if you need them at 2048 bits for some other system, because after that date they will be refused.
  4. 4Diary 4 November 2026 as a fire drill and watch your pipelines that day.
  5. 5Delete deploy keys and organisation keys that no longer belong to anyone.

Common questions

Is GitHub removing RSA SSH keys?

No. It is removing the ssh-rsa signature type, which is RSA signed with SHA-1, and the diffie-hellman-group-exchange-sha256 key exchange. RSA keys using rsa-sha2-256 or rsa-sha2-512 are unaffected.

What changes on 14 October 2026?

All new RSA SSH keys uploaded to GitHub after that date must be at least 3072 bits, for both signing and authentication. The same date also enables the mlkem768x25519-sha256 post-quantum key exchange on github.com.

What is a brownout?

A deliberate temporary disabling of the deprecated mechanism, so affected users discover the problem before permanent removal. GitHub has scheduled brownouts on 4 November and 9 December 2026.

When is final removal?

The changelog states a date, but the year printed falls before the brownouts listed above it on the same page, which suggests a publishing error. We are not quoting a year for it. Check the GitHub changelog directly before relying on a final date.

How do I check which algorithm my machine uses?

Run ssh -v git@github.com from that environment and read the negotiated server host key algorithm and key exchange in the verbose output. The key file alone does not tell you, because the signature type is negotiated at connection time.

Sources

Read against the primary documentation rather than secondary coverage. Where a figure comes from a provider's own docs, it is quoted as published on 2026-09-25.

Related

What else lives in your home directory →Pre-launch security checklist →

More from Signals

A 9.5 in next/og. Whether it reaches you depends on one line in your OG route.
The advisory rates it 9.5, but it only fires if your OG image route puts attacker-controlled text into SVG. Here is how to find out which side of that line you are on.
OpenAI and Anthropic both cut prices on 22 September. One of them costs you a refactor.
Two frontier price cuts in one day is a good week for anyone paying a token bill. The migration cost is not evenly distributed, and one of the two prices comes with an expiry hedge.
A package install reads your home directory. This week two of them did it on purpose.
The implant did nothing clever. It read the files your shell reads, in the place your credentials live, and sent them somewhere else. That is the whole attack, and it works.
Every third-party script tag is a standing grant to run code on your visitors.
A marketing form, a chat widget, an analytics snippet. Each one is permission for someone else's server to execute whatever it sends, on every page it sits on, forever.
1.8 million Android apps were scanned for hardcoded keys. Here is how to check yours.
Finding secrets in shipped apps is now a cheap, automated pipeline. Anything compiled into an APK, an IPA or a JavaScript bundle should be treated as already published.
OpenAI's Agents API will hold your agent state. What breaks if you ever need to leave.
Two major providers moved into the agent state layer in the same week. A managed harness is a real shortcut, as long as you keep a copy of what it holds.
Meta's Muse agent can now check out at your store. What merchants should change.
Agent purchases are arriving through wallets and single-use cards, not through merchants adopting a new protocol. Many merchants will receive them without choosing to.
What Brevo's SSO incident teaches about multi-tenant SAML and hijacked sending accounts.
One incident, two lessons: why email authentication did not help, and the tenant-scoping mistake anyone shipping SSO can make.
Cloudflare now sorts bots into Search, Training and Agent. What it means for your site and your agent.
The same change lands on two audiences. Site owners can now accidentally block search; agent builders will find more doors closed.
OpenAI has published seven shutdown dates. Here is the calendar.
Seven dates between 23 October and 26 February. Every one announced months ahead, in public. The failure mode is never the notice.
Nvidia bought Hugging Face. Your open-weight fallback is now a vendor relationship.
The commitments say nothing breaks. The structural change is that "we can always self-host" is now a dependency on one vendor rather than on a neutral commons.
The Videos API goes away on 24 September and OpenAI names nothing to move to.
Every other deprecation on OpenAI's page offers a migration target. This one does not, which makes it a different kind of problem.
Whisper shuts down on 26 February. The risk is not the deadline.
Five months is a generous window. Whisper is also typically wired into a background job that fails into a queue rather than into a user's face.
The Assistants API is gone. Your app may not have told you yet.
It shut down on 26 August 2026. The replacement is not a drop-in, and the most common migration mistake changes your model's behaviour without throwing an error.
One Copilot code review costs 13 requests. Here is the rest of the maths.
Copilot now bills on usage rather than seats. The headline change is simple. The multipliers underneath it are where teams get surprised.
Row-level security is on by default now. That is not the same as being protected.
Lovable fixed the default. The gap that actually leaks data was never the default, it was the policy, and no platform can write that for you.
Your model comparison is measuring the wrong number.
Every price list is per token. Your bill is per finished piece of work. Those two numbers can rank models in opposite orders.
An agent with production log access is a new identity. Treat it like one.
Always-on agents that read production logs are arriving fast. The access-control question they raise is old and well understood, which is the good news.

Open the tool.

Ten production categories, three minutes, and a ranked list of what to fix first.

Check your own stack