GitHub Rejects Your RSA Key? How to Meet the 3072-Bit Minimum

TLDR

New RSA SSH uploads require at least 3072 bits.
Existing RSA keys can use SHA-2 signatures without being regenerated.
Check the public key when uploading; check the client and authentication result when connecting.

A new 2048-bit RSA upload no longer meets the minimum

GitHub raised the minimum for newly uploaded RSA SSH keys to 3072 bits on October 14, 2026. The September announcement covers authentication and signing keys. Check the file you are trying to upload:

ssh-keygen -lf ~/.ssh/id_rsa.pub

Replace the path with your public key’s location. The first number reports its bit length. The fingerprint display also includes a hash label such as SHA256:; that is not evidence of the signature algorithm negotiated during a connection.

Choose Ed25519, or explicitly generate a larger RSA key

GitHub’s key-generation guide uses Ed25519 by default and a 4096-bit RSA alternative for systems that do not support it. Choose one of these commands and replace the email:

ssh-keygen -t ed25519 -C "[email protected]"
# Alternative when RSA is required:
ssh-keygen -t rsa -b 4096 -C "[email protected]"

Give the new key a different filename if the suggested location already contains a key. The 4096-bit example exceeds the minimum; it does not mean that 3072-bit keys are rejected.

For a personal account, open Settings → SSH and GPG keys → New SSH key. Select authentication or signing and paste the complete public key from the .pub file. Truncated text or a private-key file can still cause a format error even when the generated key is large enough.

The text ssh-rsa does not tell you which signature is used

An RSA public key can produce SHA-2 signatures. OpenSSH’s 8.8 release notes explicitly explain why disabling SHA-1 signatures does not require replacing existing RSA keys.

The naming is confusing: ssh-rsa identifies the key format, but it also names the RSA/SHA-1 signature scheme. For an existing key, check whether the SSH client or library supports rsa-sha2-256 or rsa-sha2-512, rather than deciding from the public key’s first word.

Confirm the account in the authentication response

Once the key is registered and configured locally, use GitHub’s connection test:

ssh -T [email protected]

Check any first-connection host fingerprint against GitHub’s published fingerprints. A successful response names your account and explains that GitHub does not provide shell access. Exit code 1 is expected for this test, so do not treat it alone as authentication failure.

SHA-1 retirement follows a separate schedule: temporary brownouts on November 4 and December 9, then removal on January 13, 2027. GitHub Enterprise Server receives the change in 3.25. Meet the size requirement for a new upload; inspect the client used by existing automation before deciding to replace its keys.