GitHub SSH Key Authentication Suddenly Halted Due to Missing .pub Files

According to a report by thorsell.io on Lobsters, starting July 21, 2026, users encountered a sudden issue where they were unable to perform git pull operations on GitHub repositories. The error message “Permission denied (publickey)” appeared, and authentication failed even though the validity and configuration of the private key were confirmed to be correct.

The solution to the problem was surprisingly simple: generating a .pub file. The absence of a public key file corresponding to the private key located at ~/.ssh/github_rsa caused OpenSSH to fail during authentication with GitHub’s servers. Once a public key file was created using the command ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub, authentication worked as expected.

Two Authentication Flows

The issue stems from the two authentication flows used by OpenSSH. According to RFC 4252, which defines the public key authentication method, there are two main processes that a client can follow when sending an authentication request to a server.

1. Probe → Signature Flow: In this flow, the client first presents the public key to the server. The server checks if it is prepared to accept the key and then responds with a challenge. The client replies with a signed response. This process requires a .pub file.

2. Direct Signature Flow: Here, the client skips the probing step and sends a signed authentication request upfront. In this case, the client only needs the private key for authentication, and the .pub file is not necessary. If only a private key is present, OpenSSH automatically defaults to this direct signature flow.

Historically, standard SSHD servers have accepted both flows. However, in this instance, GitHub’s SSH frontend appears to have been updated to reject the direct signature flow.

Signs of Server-Side Changes

Investigations by thorsell.io revealed changes in GitHub’s SSH server banner. The server identifier recorded in debug logs was 6a2c000, differing from the previously known babeld-<hash> identifier. This suggests GitHub may have introduced new SSH frontend software.

If the new software is configured to reject the direct signature flow, this would explain why authentication, which worked without issue until earlier that morning, suddenly began to fail. This indicates that the failure was caused by server-side changes, as no modifications were made to the client-side configurations.

GitHub’s status page has not reported any outages, suggesting that the issue may be limited to certain users. However, setups that rely solely on private keys, which are not uncommon among developers simplifying key management or post-reinstallation, are particularly vulnerable.

Verification and Reproduction

The reporter conducted tests using the same private key, attempting authentication six times each in scenarios with and without a .pub file. All six attempts failed in the absence of a .pub file, while all six succeeded when the file was present. This confirmed that the issue was not due to the key’s content or network issues but was instead highly dependent on the presence of the .pub file.

The private key itself passed validation using openssl rsa -check, which returned “RSA key ok,” and the signature algorithm rsa-sha2-512 was confirmed as modern. The .ssh/config file contained no errors, and authentication worked normally on another laptop using a different key.

Impact and Countermeasures

It remains unclear whether this problem affects all of GitHub or only specific server instances. However, if a .pub file is missing for a private key, any user could potentially face this issue.

The immediate solution is to generate a .pub file in the same directory as the private key. Most developers can extract a public key from a private key using the command: ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub.

Even if only the private key is specified in the .ssh/config file as the IdentityFile, OpenSSH will automatically search for a .pub file with the same name. Therefore, it is recommended to always keep the private and public keys paired.

This issue is not limited to GitHub; similar changes could occur with other SSH-based hosting services or servers in the future. Developers should ensure that .pub files exist for all operational private keys as a precaution.

Editorial Opinion

In the short term, this issue could lead to a surge of affected developers. If GitHub’s SSH frontend changes are being rolled out gradually, users who have not yet experienced the problem may encounter it in the coming weeks. In corporate CI/CD pipelines where only private keys are used, this could lead to sudden build failures. Companies should urgently inform their developers to check for the presence of .pub files.

In the long term, this event highlights a gap between OpenSSH’s authentication flow specifications and the implementation decisions of cloud service providers. While the direct signature flow complies with RFC 4252, it remains unclear whether service providers will standardize on the probe-required flow for security reasons or maintain compatibility. It is also uncertain whether GitHub’s change was intentional or a bug. Official clarification from GitHub will be crucial.

A key question from the editorial team is whether this issue could also occur with other SSH services such as GitLab, Bitbucket, or SourceForge.

References

• “GitHub suddenly rejected my SSH key (the fix was a .pub file?!)”, by thorsell.io by GLaDER — Lobsters, 2026-07-21T10:11:59.000Z (ARR)
• Source URL: https://thorsell.io/2026/07/21/github-ssh-keys.html