GitHub SSH鍵認証突然停止、.pubファイル欠如が原因

Lobsters の thorsell.io by GLaDER の報道によれば、2026年7月21日、GitHub上のリポジトリからgit pullが突然実行できなくなる事象が発生した。Permission denied (publickey) というエラーメッセージが表示され、鍵そのものの有効性や構成に問題がないにもかかわらず、認証が通らなくなったという。

問題の解決策は「.pubファイルの生成」という極めて単純なものだった。秘密鍵 ~/.ssh/github_rsa に対応する公開鍵ファイルが存在しない状態で、OpenSSHがGitHubのサーバーと認証する際に失敗していた。ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub で公開鍵ファイルを作成したところ、認証が正常に機能するようになった。

二つの認証フロー

この現象の背景には、OpenSSHが採用する二種類の認証フローがある。RFC 4252で定義される公開鍵認証方式では、クライアントはサーバーに対して認証要求を送信する際に、主に二つの流れが存在する。

一つは「プローブ→署名」の流れだ。クライアントがまず公開鍵をサーバーに提示し、サーバーがその鍵を受け入れる準備ができているかを確認した上で、チャレンジに対して署名付きの応答を返す。この方式では公開鍵ファイル（.pub）が必要となる。

もう一つは「直接署名送信」の流れである。クライアントはプローブを行わず、最初から署名済みの認証要求を送信する。この場合、クライアントは秘密鍵のみを持っていれば認証可能で、公開鍵ファイルは必須ではない。OpenSSHは秘密鍵しか存在しない場合、自動的にこの直接署名フローを選択する。

従来の標準的なsshdサーバーは両方のフローを受け入れてきた。しかし今回の事例では、GitHubのSSHフロントエンドが直接署名フローを拒否するように変更された可能性が高い。

サーバー側変更の兆候

thorsell.ioによる調査では、GitHubのSSHサーバーバナーに変化が見られた。デバッグログに記録されたサーバーの識別子は 6a2c000 であり、従来知られていた babeld- とは異なる。これはGitHubが新たなSSHフロントエンドソフトウェアを導入したことを示唆している。

新ソフトウェアが直接署名フローを拒否する仕様であれば、早朝まで正常だった認証が突如として失敗した理由が説明できる。クライアント側の構成は全く変更されていないにもかかわらず、サーバー側の変更が原因で認証不能に陥ったことになる。

GitHubのステータスページには障害の報告はなく、問題は一部のユーザーに限定的に発生している可能性がある。しかし、公開鍵ファイルを欠いた秘密鍵のみの設定は、特に再インストール直後や鍵管理を簡略化している開発者の間で珍しくない。

事実確認と再現実験

報告者は同一の秘密鍵を用いて、公開鍵ファイルがある場合とない場合でそれぞれ6回ずつ認証を試行した。公開鍵ファイルなしでは6回全て失敗し、公開鍵ファイルありでは6回全て成功した。この結果から、問題が鍵の内容やネットワークの不具合ではなく、ファイルの有無という条件に強く依存していることが確認された。

鍵そのものは、openssl rsa -check で「RSA key ok」と判定され、署名アルゴリズムは現代的な rsa-sha2-512 が使われていた。.ssh/config にも問題はなく、別のラップトップ（別の鍵を使用）では正常に動作していた。

影響と対策

この問題がGitHub全体に及んでいるのか、一部のサーバーインスタンスのみなのかは現時点では不明である。しかし、同一の秘密鍵に公開鍵ファイルが存在しない場合、すべてのユーザーが影響を受ける可能性がある。

当面の対策は、秘密鍵ファイルと同じディレクトリに.pubファイルを作成することだ。多くの開発者は秘密鍵から公開鍵を抽出するコマンドとして「ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub」を実行すればよい。

また、.ssh/config で IdentityFile として秘密鍵のみを指定している場合でも、OpenSSHは同名の.pubファイルを自動的に探索する。そのため、秘密鍵と公開鍵をペアで保持することが推奨される。

なお、この問題はGitHubだけに限らず、将来的に他のSSHベースのホスティングサービスやサーバーで同様の変更が行われる可能性もある。運用中の全秘密鍵に対して.pubファイルが存在するかどうかを確認しておくことが望ましい。

編集部の見解

短期的には、この問題に直面した開発者が急増する可能性がある。GitHubのSSHフロントエンド変更が段階的にロールアウトされている場合、まだ影響を受けていないユーザーも今後数週間で同様のエラーに遭遇するかもしれない。企業のCI/CDパイプラインで秘密鍵のみを使用しているケースでは、ビルドが突然停止するリスクがある。まずは全開発者に対して.pubファイルの有無を確認するよう周知すべきだ。 長期的には、OpenSSHの認証フロー仕様と、クラウドサービス側の実装の食い違いが表面化した事例として注目される。直接署名フローはRFCに準拠しているが、サービス事業者がセキュリティ上の理由からプローブ必須のフローに統一する方向に進むのか、あるいは互換性を維持するのかは不明だ。GitHubがこの変更を意図的に行ったのか、バグなのかも含めて、今後の公式見解が待たれる。 編集部からの問いとして、この問題は他のSSHサービス（GitLab、Bitbucket、SourceForgeなど）でも再現するのか、という点が挙げられる。

参考

• 「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)
• 元記事URL: https://thorsell.io/2026/07/21/github-ssh-keys.html