Direct answer: If your Git remotes use HTTPS, GitHub says these SSH changes do not affect you. If you connect over SSH, check your client now: new RSA keys uploaded after October 14, 2026 must be at least 3072 bits, and older clients that rely on RSA/SHA-1 or diffie-hellman-group-exchange-sha256 need upgrading before the announced brownouts.[1]
Five-minute audit
1. Check whether your repositories use SSH
Run this inside each important repository:
git remote -v
URLs beginning with https:// are outside the scope of this SSH change. SSH remotes commonly look like git@github.com:OWNER/REPOSITORY.git.[1]
For a quick scan of repositories under the current directory:
find . -name .git -type d -prune -print0 2>/dev/null |
while IFS= read -r -d '' gitdir; do
repo=${gitdir%/.git}
printf '\n[%s]\n' "$repo"
git -C "$repo" remote -v
done
2. Check your SSH client version
ssh -V
GitHub lists these minimum versions for robust RSA-with-SHA-2 support under default configuration: OpenSSH 7.2p1, JSch 0.1.66 from the mwiede fork, TeamCity 2021.2.3, Go SSH 0.16.0, libssh2 1.11.0 and PuTTY 0.82.[1]
If a CI runner, IDE, Java service or deployment appliance uses an embedded SSH library, audit that component too—not only the ssh command on your laptop.[1]
3. Inventory local public keys and key sizes
GitHub recommends checking ~/.ssh for existing public keys before generating another one.[2]
for key in "$HOME"/.ssh/*.pub; do
[ -e "$key" ] || continue
ssh-keygen -lf "$key"
done
The output shows each key’s bit length and algorithm. An existing RSA key does not automatically need replacing: GitHub says RSA keys can continue when the client uses RSA with SHA-2, and most compatible implementations negotiate that automatically.[1]
4. Prefer Ed25519 for a replacement key
GitHub recommends Ed25519 when possible. Its documented command is:[3]
ssh-keygen -t ed25519 -C "your_email@example.com"
Use a unique filename if you already have a key at the default path, and protect the new private key with a passphrase.[3] GitHub’s upload process requires the public key, not the private-key file.[5]
If a legacy system requires RSA, GitHub’s current setup guide uses a 4096-bit RSA key, which is above the new 3072-bit minimum:[3]
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
5. Add the public key and test it
After generating a key pair, add the public .pub file under GitHub → Settings → SSH and GPG keys → New SSH key. GitHub also documents the gh ssh-key add command for authenticated GitHub CLI users.[5]
gh ssh-key add ~/.ssh/id_ed25519.pub --type authentication --title "work-laptop-2026"
Then test the connection:
ssh -T git@github.com
A successful test reports that you authenticated but GitHub does not provide shell access. GitHub notes that this successful authentication test intentionally exits with status code 1, so CI scripts should verify the message rather than assuming any non-zero exit means authentication failed.[4]
What GitHub is changing
GitHub’s September 22 notice announces four SSH changes: removal of the RSA/SHA-1 ssh-rsa signature type, removal of diffie-hellman-group-exchange-sha256, a 3072-bit minimum for newly uploaded RSA keys after October 14, and support for the post-quantum mlkem768x25519-sha256 key-exchange method in stated GitHub.com and Enterprise Cloud environments.[1]
The new RSA-size requirement applies to keys uploaded after October 14. It does not mean every existing RSA key suddenly stops working on that date. The more important compatibility check for an existing RSA key is whether the client can negotiate rsa-sha2-256 or rsa-sha2-512 instead of RSA/SHA-1.[1]
GitHub schedules brownouts for November 4 and December 9 for the legacy signature and key-exchange removals. These are useful test windows for finding forgotten CI agents and old integrations.[1]
Team and CI migration checklist
- Export or inventory SSH credentials used by developer laptops, CI runners, deploy keys, build servers, bots and release appliances.
- Map each credential to its owner, repository scope and last verified use.
- Check the actual SSH library version inside containers, IDEs and Java applications.[1]
- Upgrade clients before rotating keys when the existing RSA key is strong but the software lacks RSA/SHA-2 support.[1]
- Prefer a new Ed25519 key when compatibility permits.[1][3]
- If RSA is mandatory, generate at least 3072 bits; GitHub’s setup guide demonstrates 4096 bits.[1][3]
- Upload only the public key, test authentication, then test a real clone or fetch against a non-critical repository.[4][5]
- Keep the old key during a controlled overlap, then revoke it after every required environment passes.
- Record rollback steps before changing production deployment credentials.
Important schedule caveat
GitHub’s current announcement lists the final removal as “January 13, 2026,” even though that date precedes the September announcement and the November and December brownouts. This appears chronologically inconsistent. Do not silently substitute a different year: re-check the official notice before planning around the final-removal date. The October 14 requirement and the two stated 2026 brownout dates are clear in the same notice.[1]
FAQ
Do HTTPS Git remotes need any change?
No for this specific SSH migration. GitHub says remotes beginning with https:// are not affected by these SSH changes.[1]
Must I replace every existing RSA key?
No. GitHub says an existing RSA key can continue if the SSH client uses RSA with SHA-2. Upgrade incompatible software or move to Ed25519 rather than assuming the key label ssh-rsa proves SHA-1 is being used.[1]
What is the minimum size for a new RSA key?
Starting October 14, 2026, GitHub says newly uploaded RSA keys must be at least 3072 bits. Its general key-generation guide currently demonstrates 4096 bits for legacy systems that cannot use Ed25519.[1][3]
Why can ssh -T git@github.com return exit code 1 after success?
GitHub authenticates the key but does not provide interactive shell access, and its testing guide explicitly says the command should exit with code 1. Confirm that the message contains your GitHub username.[4]
When is the final removal date?
The published notice currently contains an internally inconsistent year for that milestone. Use the announced November 4 and December 9 brownouts for testing, and verify the official changelog again before the final cutover.[1]
Official sources
1. Security improvements for SSH — GitHub Changelog
2. Checking for existing SSH keys — GitHub Docs
3. Generating a new SSH key and adding it to the ssh-agent — GitHub Docs
4. Testing your SSH connection — GitHub Docs
5. Adding a new SSH key to your GitHub account — GitHub Docs
Last checked: September 23, 2026. Re-check GitHub’s official changelog before the scheduled brownouts or final cutover.