GitHubが突然SSHキーを拒否した理由：消えた.pubファイル

 (thorsell.io)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 何も変更していないノートPCで GitHub の git pull が突然失敗したが、秘密鍵に対応する .pub ファイルを生成したところ、再び認証されるようになった
  • .pub ファイルがある場合、OpenSSH はまず公開鍵を提示して承認を得た後に署名する。一方、ない場合は 署名済みの認証リクエストを即座に送信する
  • どちらのフローも RFC 4252 に準拠しており、一般的な sshd も許可するが、当時の GitHub SSH フロントエンドは直接署名されたリクエストを受け付けていないように見えた
  • 12回の対照試験で、.pub ファイルがなかった6回はすべて拒否され、ファイルがあった6回はすべて成功した
  • サーバーバナーの変化から サーバー側ソフトウェアが変更された可能性は推測できるが、正確な原因は確認されていないため、対応する公開鍵ファイルを一緒に保持しておくのが安全

突然の認証失敗と解決

  • メインのノートPCで git pull が Permission denied (publickey) エラーとともに中断した
    • そのキーは依然として GitHub に登録されていた
    • 別のキーを使うノートPCでは同じリポジトリを正常に取得できた
  • キーとクライアント設定には異常が見つからなかった
    • openssl rsa -check は RSA key ok を返した
    • 最新の署名アルゴリズムである rsa-sha2-512 を使用していた
    • ~/.ssh/config に問題はなく、GitHub のステータスページも正常だった
  • 再インストール後、~/.ssh/github_rsa に対応する 公開鍵ファイルが消えた状態になっており、次のコマンドで生成したところ認証に成功した
ssh-keygen -y -f ~/.ssh/github_rsa > ~/.ssh/github_rsa.pub
  • 対照試験では、.pub ファイルがなかった6回はすべて失敗し、あった6回はすべて成功した

.pub ファイルによって変わる認証フロー

  • OpenSSH は .pub ファイルの有無によって異なる 公開鍵認証フローを使用する
    • ファイルがある場合は、まず公開鍵を提示してサーバーの承認を待ってから署名する
    • 秘密鍵だけがある場合は、事前確認を省略して完全に署名済みの認証リクエストをそのまま送る
  • どちらの方式も RFC 4252 で許可されており、一般的な sshd はどちらも受け入れる
  • 当時の GitHub では、直接署名された公開鍵リクエストが拒否されたが、GitHub 側で実際に変更があったかどうかは確認されていない
    • デバッグログのサーバーバナーは、過去の babeld-<hash> 形式ではなく 6a2c000 と表示された
    • 新しいサーバーソフトウェアが直接署名されたリクエストを拒否していた可能性は推測にとどまる
  • 同じ問題を避けるには、秘密鍵に対応する .pub ファイルを一緒に保持しておく必要がある

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rsのコメント

  • この4時間、同じ問題に遭遇しており、すでに https://www.githubstatus.com/incidents/g40zcbvchny4 に登録されている

  • 数週間前にSSHキーを入れ替えた際、Gitで無視されていた古い .pub ファイルを削除していなかったところ、新しいキーで接続しても失敗し続けた
    複数のデバッグオプションを有効にして、ようやくSSHクライアントが古いフィンガープリントを送っていることに気づいた。OpenSSHが.pubファイルを読むこと自体を知らず、これまで完全に不要なファイルだと思っていた

  • 今日、CIサーバーが突然github.comに接続できなくなったような同じ障害に遭遇した
    キーを正しいed25519キーに差し替えると再び動作したが、このキーにも対応する.pubファイルがないため、なぜ解決したのかは分からない

    • キーが突然動かなくなり、まず侵害を心配したが、今はGitHubが直接対応しているようで安心した

  • 今日同じ問題に遭遇したが、GitHubがSSH認証の動作変更を計画していたという告知は、知る限りなかった

    • 計画された変更だったとは思えない

  • パスワードとリカバリーキーを両方失い、SSHキーによるアカウント復旧手続きを行ったが、GitHubがそのSSHキーを期限切れ扱いにしたため、アカウントへのアクセス権を完全に失った

  • 7〜8年の間.pubファイルを置いたことがない気がするので、次にGitHubを使う前に問題が解決していることを願う

    • 公開鍵ファイルは簡単に再生成でき、そのコマンドも元記事に載っている

  • 2つの認証フローがどちらも正当なら、なぜキー探索フローが存在するのか疑問だ
    こうした奇妙な挙動を引き起こすだけのように見えるし、どうせ秘密鍵から公開鍵を作れるならSSHが自動で処理すればよさそうだ

    • 秘密鍵が暗号化されている、またはハードウェアセキュリティトークンに保存されていて、すぐには使えない状況のための機能だ
      SSHはまずサーバーにどのキーが通るか確認し、認証に確実に失敗するキーをユーザーが無駄に復号しなくて済むようにする
      この挙動には https://github.com/FiloSottile/whoami.filippo.io のような特殊な副作用もあるため、ユーザーが誤って間違ったサーバーに接続した場合に備え、サーバーがクライアントの公開鍵を事前に知らなければ認証を試みられない方式も許容する必要がある

  • 仕事用のOffice 365アカウントも、5年ぶりに今日突然動かなくなった
    Microsoftで侵害事故が起きてすべての値を再ソルトしたのか、それとも最近のChat Control 1.0の採決のせいで欧州ユーザーだけに起きていることなのか気になる

    • GitHubの接続終了サービスとM365アカウント認証はまったく関係なく、偶然の一致だと99.999%確信している
      GitHubのGit SystemsとMicrosoftのOffice/M365製品群の両方で働いたことがあると私が知る2人のうちの1人なので、そう断言する資格も十分にある
      仮に両サービスに同じように適用されるポリシーや技術変更が原因だったとしても、互いに分断されたシステムなので、同じ日にデプロイされる可能性は極めて低い