GitHub's SSH change: "key is too short", the 4 November brownout, and the error each old client prints

The dates

GitHub has not said at what hours the brownouts start or how long they last. Only Git over SSH is affected; GitHub says remotes that start with https:// are not. On GitHub Enterprise Server the same changes come with version 3.25.

Find your error

The client errors in this table came from our own test against a server set up like github.com after the removal. We have not yet seen github.com during a brownout; we will check it on 4 November and update this page. Every one of these messages also appears for ordinary reasons, such as a key that was never added to GitHub. Is it this change? shows how to tell.

"key is too short" when you add a key

Since 14 October 2026 GitHub refuses a new RSA key under 3072 bits, both as an account SSH key and as a deploy key. Through the API, which is what Terraform uses, one public report quotes the refusal like this:

Error: POST https://api.github.com/repos/<org>/<repo>/keys: 422 Validation Failed
[{Resource:PublicKey Field:key Code:custom Message:key is too short. GitHub recommends
using ssh-keygen to generate a RSA key of at least 3072 bits.}]

Keys that are already on GitHub keep working, so nothing fails until someone adds or rotates a key. That makes this easy to miss: an environment created next month, or a key rotated on schedule, fails long after the change.

Terraform. The hashicorp/tls provider's tls_private_key makes 2048-bit RSA keys unless you set rsa_bits. Any module that passes such a key to github_repository_deploy_key or github_user_ssh_key now fails on new keys. The fix is one of these:

resource "tls_private_key" "deploy" {
  algorithm = "ED25519"
}

resource "tls_private_key" "deploy" {
  algorithm = "RSA"
  rsa_bits  = 4096
}

GitHub recommends Ed25519 for new keys. If you choose ECDSA instead, set ecdsa_curve = "P256": the provider's default curve is P224, for which it produces no OpenSSH public key.

Changing algorithm or rsa_bits on an existing tls_private_key replaces the key. Terraform then creates a new key pair, and every system that holds the old private key, such as a CD tool's repository secret, needs the new one.

Command line. Make a new key with either of these:

ssh-keygen -t ed25519 -f ~/.ssh/github_ed25519
ssh-keygen -t rsa -b 4096 -f ~/.ssh/github_rsa4096

Before you pick RSA, check the client that will use the key. Since 15 March 2022, GitHub has accepted only SHA-2 signatures from RSA keys added on or after 2 November 2021. By that rule, a new RSA key of any size will not work from the old clients in the sections below, starting the day you add it, not on 4 November. For those clients use Ed25519, or ECDSA for the original JSch 0.1.55, which cannot load Ed25519 keys. Or upgrade the client.

Java: com.jcraft.jsch.JSchException: Auth fail

com.jcraft.jsch.JSchException: Auth fail
	at com.jcraft.jsch.Session.connect(Session.java:519)

Cause: the original JSch from JCraft (com.jcraft:jsch) has had no release since 0.1.55 in 2018. In our test it signed with an RSA key using SHA-1 (ssh-rsa), which GitHub is removing.

JGit 5.13.3 with its JSch transport on JSch 0.1.55 failed the same way. JSch's error is at the bottom of the chain (stack frames left out):

org.eclipse.jgit.api.errors.TransportException: ssh://git@…: Auth fail
Caused by: org.eclipse.jgit.errors.TransportException: ssh://git@…: Auth fail
Caused by: com.jcraft.jsch.JSchException: Auth fail

The same JGit connected with the maintained fork below in place of com.jcraft:jsch, and with JGit's Apache MINA sshd transport (org.eclipse.jgit.ssh.apache, sshd 2.7.0 in our test).

Fix: replace the dependency with the maintained fork, com.github.mwiede:jsch. Its README calls it a drop-in replacement: you change the dependency coordinates, not the code. In our test 0.1.66 and 2.28.8 passed with an RSA key; GitHub's minimum is 0.1.66.

<dependency>
  <groupId>com.github.mwiede</groupId>
  <artifactId>jsch</artifactId>
  <version>2.28.8</version>
</dependency>

If something else pulls in com.jcraft:jsch, exclude it there. Run mvn dependency:tree -Dincludes=com.jcraft or gradle dependencies to find out which dependency brings it in.

Key workaround: an ECDSA key worked with JSch 0.1.55 in our test. An Ed25519 key does not, because 0.1.55 cannot load it.

Go: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain

Cause: golang.org/x/crypto/ssh from November 2021 (v0.0.0-20211117183948-ae814b36b871 in our test) signed with an RSA key using SHA-1.

Fix: upgrade the module and rebuild.

go get golang.org/x/crypto@latest
go mod tidy

GitHub's table asks for v0.16.0. In our test v0.1.0 and v0.15.0 also passed, so a binary built with one of those is probably not your problem. Check what a built binary contains with go version -m ./yourbinary | grep x/crypto.

Key workaround: Ed25519 and ECDSA keys worked with the old version in our test.

go-git v5.4.2, built with the x/crypto it requires (April 2021), printed the same message for both List and PlainClone with an RSA key. go-git v5.19.3 connected:

go get github.com/go-git/go-git/v5@latest
go mod tidy

Node.js: All configured authentication methods failed

Error: All configured authentication methods failed

This is the error the Client emits, with level: 'client-authentication'.

Cause: ssh2 0.8.9 and 1.0.0 signed with an RSA key using SHA-1 in our test. GitHub's version table does not list ssh2.

Fix: npm install ssh2@latest. 1.17.0 passed in our test. If ssh2 comes in through another package, npm ls ssh2 shows which one, and an overrides entry in package.json can force a newer version, if that package works with it.

Key workaround: Ed25519 and ECDSA keys worked with 0.8.9 and 1.0.0 in our test.

Python paramiko: not a valid OPENSSH private key file or encountered RSA key, expected OPENSSH key

This is the most misleading one. With a PEM-format RSA key (its first line contains BEGIN RSA PRIVATE KEY; ssh-keygen -m PEM writes this format) passed as key_filename=, SSHClient.connect in paramiko 2.4.2 printed:

paramiko.ssh_exception.SSHException: not a valid OPENSSH private key file

and paramiko 2.8.1 printed:

paramiko.ssh_exception.SSHException: encountered RSA key, expected OPENSSH key

No login error appears, and nothing in either message mentions ssh-rsa. The traceback shows why: paramiko tries the key file as each key type it knows, and after the server refused the RSA signature, the last try read the file as an Ed25519 key. That parse error is the one you see. Our test server's log showed the real refusal, signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms; GitHub does not show you its log.

We did not test an RSA key in the newer OpenSSH format (its first line contains BEGIN OPENSSH PRIVATE KEY), or keys that paramiko finds through an SSH agent or look_for_keys. Those may print something else.

Cause: paramiko 2.4.2 and 2.8.1 signed with an RSA key using SHA-1 in our test. GitHub's version table does not list paramiko.

Fix: pip install -U paramiko. 2.9.0 is the first version that passed in our test, and 5.1.0 passed too.

Key workaround: Ed25519 and ECDSA keys worked with 2.4.2 and 2.8.1 in our test.

PuTTY plink: Server refused our key

PuTTY 0.70 (Ubuntu 18.04's package) printed:

Server refused our key
FATAL ERROR: Disconnected: No supported authentication methods available (server sent: publickey)

PuTTY 0.73 (Ubuntu 20.04's package) printed:

Server refused our key
FATAL ERROR: No supported authentication methods available (server sent: publickey)

Cause: these versions signed with an RSA key using SHA-1 in our test.

Fix: upgrade PuTTY. 0.76 and 0.81 passed in our test; GitHub's table asks for 0.82, so use that or later where you can. plink -V prints the version. We tested the Linux builds only.

Key workaround: Ed25519 and ECDSA keys worked with 0.70 and 0.73 in our test.

libssh2: curl: (67) Authentication failure and curl: (2) Failure establishing ssh session

We tested libssh2 through curl. Other programs built on libssh2 word their errors their own way, so check the libssh2 version rather than the message.

libssh2 1.10.0 (Debian 12's package) failed with an RSA key, because it signed with SHA-1:

curl: (67) Authentication failure

With curl -v the lines before it include:

* SSH public key authentication failed: Username/PublicKey combination invalid

Ed25519 and ECDSA keys worked with it. Debian 12 has long-term support until 30 June 2028, so this one will be around.

libssh2 1.8.0 (CentOS 7's package) failed before it reached the login, with every key type:

curl: (2) Failure establishing ssh session

The key exchange GitHub is removing is the only one this version shares with github.com. A different key does not help, because 1.8.0 cannot load Ed25519 or ECDSA keys either. Move that job to a newer system.

Fix: libssh2 1.11.1 (Debian 13's package) passed in our test; GitHub's minimum is 1.11.0. curl -V | grep -o 'libssh2/[0-9.]*' shows the version your curl uses.

Is it this change, or something else?

All of the messages above also appear when the key was never added to GitHub, or the program is reading a different key. Three checks separate the two:

1. Try the same key with OpenSSH. GitHub lists OpenSSH 7.2p1 and later as fine.

   ssh -i ~/.ssh/your_key -o IdentitiesOnly=yes -T git@github.com

   If it greets you with Hi …! You've successfully authenticated, but GitHub does not provide shell access., GitHub accepts the key, and the program that fails is the suspect. A PuTTY .ppk key needs converting first: puttygen your_key.ppk -O private-openssh -o your_key.

2. Look at the date. If it fails on 4 November or 9 December and works the day before and after, the brownout is the likely cause.

3. Look at the version. Compare the client's version with the passing versions in its section.

Check before 4 November

Only remotes that do not start with https:// matter, and git remote -v lists them. ssh-add -l shows the type of each key in your SSH agent, in brackets at the end of its line; ssh-keygen -lf followed by a key file does the same for a key on disk. Ed25519 and ECDSA avoid the SHA-1 RSA change; the client still needs a supported key exchange. So whatever the key, find what makes the connection and its version. Run each of these where that tool or project is installed:

git remote -v
ssh-add -l
pip show paramiko | grep Version
npm ls ssh2
go list -m golang.org/x/crypto
plink -V
curl -V | grep -o 'libssh2/[0-9.]*'

For Java, look for jsch in mvn dependency:tree or gradle dependencies. A program that bundles its own SSH library will not show up in any of these.

A working RSA connection today does not tell you whether the key is affected. The SHA-1 part of the change newly matters only for RSA keys added to GitHub before 2 November 2021, and from outside you cannot tell a key's age from a connection that works. Your GitHub settings show when each key was added; the client's version tells you the rest.

The brownout dates are also in our Breakage Calendar.

How we tested

On 21 October 2026 we set our own OpenSSH 10.0p2 server to github.com's SSH algorithm lists as read that day, then removed ssh-rsa signatures and diffie-hellman-group-exchange-sha256. We connected from 35 client stacks with RSA (3072-bit), ECDSA and Ed25519 keys, twice each. 32 stacks could log in before the removal. After it, 10 of the 32 failed. Every failure involved the RSA key; none of the stacks failed with an ECDSA or Ed25519 key it could load. The one key-exchange failure, CentOS 7's libssh2 1.8.0, can load no other key type. All five OpenSSH clients we tried kept working, as did the newest versions of every library we tried.

On 23 October we ran 29 configurations again against the same stand-in, twice each, this time through each library's normal top-level call, to record the exact messages on this page, and added JGit and go-git. All 10 failing stacks failed again, JGit on JSch 0.1.55 and go-git v5.4.2 failed too, and every newer version connected. The 24 results that could be compared with the 21 October run all matched. The RSA test key was 3072-bit, in PEM format.

This was our stand-in, not GitHub's server. GitHub's real servers could negotiate differently. We will connect to github.com during the 4 November brownout and update this page. We did not test Windows clients, TortoiseGit, TeamCity, libgit2 builds, Dropbear or ssh-agent setups. Executed by us; not independently reproduced.

Sources: GitHub changelog, "Security improvements for SSH", 22 September 2026; GitHub blog, "Improving Git protocol security on GitHub" (SHA-2 only for RSA keys added from 2 November 2021); GitHub Docs, "Testing your SSH connection"; tls_private_key documentation; the 422 report; the maintained JSch fork.