GitHub SSH Security: 3072-Bit Keys Required by October 14

GitHub published a security changelog on September 22 that most teams skimmed past. Three SSH changes, two hard deadlines. The first lands in 17 days — October 14 — when GitHub stops accepting new RSA SSH keys under 3072 bits. The second hits November 4, when the old ssh-rsa signature type gets a temporary block. If your CI pipeline is running on a 2048-bit deploy key or a four-year-old SSH library, you are about to discover that the hard way.

Change One: October 14 and the Key Size Floor

Starting October 14, 2026, any new RSA SSH key uploaded to GitHub must be at least 3072 bits. Two things to understand immediately. First, this applies only to new key uploads — keys already in your account are not revoked. Second, the threshold is 3072 bits, not 4096. GitHub is meeting NIST SP 800-131A‘s current guidance for acceptable RSA security through 2031.

Who gets caught: teams that auto-generate fresh deploy keys on first run, CI configurations that create ephemeral keys per build, and anyone who followed an old tutorial that still runs ssh-keygen -t rsa -b 2048. The failure mode is quiet — GitHub rejects the key upload, the next deploy fails, and the error message points at “authentication failure” rather than the key size.

The right fix is to skip RSA entirely. Generate Ed25519:

# Recommended: Ed25519 (equivalent security to RSA 3072, much smaller)
ssh-keygen -t ed25519 -C "your@email.com"

# If a legacy system requires RSA, use 4096 bits minimum
ssh-keygen -t rsa -b 4096 -C "your@email.com"

Ed25519 gives you equivalent security to RSA 3072 with a 68-byte public key instead of 400 bytes. It signs faster and sidesteps every future conversation about RSA key sizes. GitHub explicitly recommends it in the changelog.

Change Two: The November Brownout That Will Break CI Pipelines

This one is more dangerous because it affects existing connections, not just new key uploads.

On November 4, 2026, GitHub runs a brownout — a temporary block — on two things: the ssh-rsa signature type (RSA keys signing with SHA-1) and the diffie-hellman-group-exchange-sha256 key exchange algorithm. A second brownout follows December 9. The permanent cutoff is January 13, 2027.

Here is the part most teams miss: the ssh-rsa issue is not about your key’s size — it is about the signature type your SSH client sends. RSA keys can sign with SHA-1 (going away) or SHA-256 (fine). OpenSSH 7.2 and newer automatically use rsa-sha2-256 when talking to modern servers. Any machine updated in the last five years is almost certainly fine.

The problem is SSH libraries buried inside CI tools. Old Jenkins configurations. Ansible playbooks using Paramiko. GitHub Actions with custom Docker images. Any tool using libssh2 before 1.8.2 or Paramiko before 2.6 will send ssh-rsa and break on November 4.

Audit before the brownout hits:

# Check what signature type your client is actually negotiating
ssh -vT git@github.com 2>&1 | grep "pubkey type"
# Should show: rsa-sha2-256 or rsa-sha2-512
# If it shows: ssh-rsa — fix before November 4

# Check your client version
ssh -V
# OpenSSH 7.2+ is safe; below that, upgrade your SSH client

What Everyone Is Confusing

GitHub’s announcement covers two distinct issues. The October 14 change is about new key uploads and key size. The November 4 change is about active SSH connections and the signature algorithm. You can have a fresh 4096-bit RSA key uploaded yesterday and still break on November 4 if your CI tool sends ssh-rsa.

Check both, separately:

# Find your RSA key size (Oct 14 check)
ssh-keygen -l -f ~/.ssh/id_rsa
# 2048 SHA256:... — too small for new uploads after Oct 14
# 4096 SHA256:... — fine for size

# Find your signature type (Nov 4 check)
ssh -vT git@github.com 2>&1 | grep "pubkey type"
# rsa-sha2-256 — you are fine
# ssh-rsa — fix required before November 4

Post-Quantum SSH: Already on GitHub, Nothing to Configure

GitHub has also enabled mlkem768x25519-sha256 — the NIST FIPS 203 post-quantum key exchange — on github.com. OpenSSH 9.9 introduced it; OpenSSH 10.0 made it the default key exchange. If you are running OpenSSH 10.x, your GitHub connections are already using post-quantum key exchange with nothing to configure.

This is not a deadline item. It is forward-looking infrastructure against harvest-now-decrypt-later attacks. To confirm your session uses it:

ssh -vT git@github.com 2>&1 | grep "kex: algorithm"
# Look for: mlkem768x25519-sha256

What to Do This Week

1. Run the verbose SSH test. Check whether your pubkey type shows rsa-sha2-256 or ssh-rsa. If ssh-rsa, upgrade your SSH library now — not on November 3.
2. Audit deploy key generation scripts. If they default to -t rsa -b 2048, update to Ed25519 or RSA 4096 before October 14.
3. Upgrade SSH clients on build machines. OpenSSH 7.x or earlier on any build agent should be upgraded now. This resolves both issues simultaneously.

The brownouts exist precisely to catch these problems before the permanent cutoff. GitHub is giving you a warning. Use it.