SSH で GitHub に接続しているなら、10月14日の RSA 鍵3072ビット必須、11月と12月のブラウンアウト、ssh-rsa 署名と DH 鍵交換の削除のうち、自分に効くのがどれかを切り分ける。
3072ビット 10月14日以降に登録する新規 RSA 鍵の最小サイズ 一次情報の Schedule と「RSA key changes」節。署名用・認証用の両方が対象と明記されている
GitHub への remote が https:// で始まっているなら、今回の SSH の変更で壊れるものはない。影響を受けるのは Git クライアントから SSH で接続している人と、GitHub Enterprise Server で認証なしの Git プロトコルを使っている人だけだと、2026年9月22日の changelog が明示している。
該当するなら、見る場所は二つに分かれる。鍵の側（RSA 鍵がどのハッシュで署名しているか、新しく登録する RSA 鍵のサイズ）と、鍵交換の側（diffie-hellman-group-exchange-sha256 に依存していないか）だ。どちらが効くかで、期日もやることも変わる。
| 日付 | 内容 |
|---|---|
| 2026年10月14日 | 新規にアップロードする RSA 鍵は3072ビット以上が必須。あわせて mlkem768x25519-sha256 が github.com とデータレジデンシー付き GitHub Enterprise Cloud（米国リージョンを除く）で有効に |
| 2026年11月4日 | ssh-rsa 署名方式と diffie-hellman-group-exchange-sha256 のブラウンアウト |
| 2026年12月9日 | 同じ2つで2回目のブラウンアウト |
| 原文「January 13, 2026」 | ssh-rsa 署名方式と diffie-hellman-group-exchange-sha256 を削除 |
出典：GitHub Changelog「Security improvements for SSH」（2026年9月22日）
最後の行は原文が「January 13, 2026」と書いている。直前の項目は2026年12月9日なので、並び順と年が噛み合わない。年の誤りなのかどうかは changelog の記述からは判断できないため、ここでは原文のまま置いた。原文の表では削除が2回のブラウンアウトの後に並んでいるが、日付どおりの実施順序は確定できない。
消えるのは署名方式としての ssh-rsa、SHA-1 で署名する RSA のことだ。SHA-1 を使う ssh-rsa-cert-v01@openssh.com 証明書も同じく対象になる。鍵の種類を指す ssh-rsa は署名アルゴリズムに関係なくすべての RSA 鍵を指す名前で、こちらが無効になるわけではない。changelog 自身も、この二つの名前が紛らわしいと断っている。
ここが実務でいちばん効く。既存の RSA 鍵を作り直す必要はない。 RSA 鍵はどのハッシュでも署名できるので、使っている SSH 実装が rsa-sha2-256 か rsa-sha2-512 を扱えるなら、同じ鍵を使い続けられる。SHA-2 に対応した実装はたいていそちらを自動で選ぶ、と書かれている。期日までに確かめるのは鍵ではなく実装の版だ。
| ソフトウェア | 最低バージョン |
|---|---|
| OpenSSH | 7.2p1 |
| JSch | 0.1.66（changelog が指すフォーク版） |
| TeamCity | 2021.2.3 |
| Go SSH | 0.16.0 |
| libssh2 | 1.11.0 |
| PuTTY | 0.82 |
出典：同 changelog「Preparing for these changes」の一覧
版を上げられない環境なら、Ed25519 か ECDSA の鍵に替える道がある。GitHub がサポートする Ed25519 と ECDSA の鍵はこの先も使えるとされている。新規に作るなら Ed25519 が推奨で、他サービスとの互換で RSA が必要なときだけ3072ビット以上にする。
3072ビットの条件は「10月14日以降にアップロードする新規 RSA 鍵」に掛かる書き方で、署名用と認証用の両方が対象だと明記されている。それに満たないサイズで既に登録済みの鍵をどう扱うかは、changelog に書かれていない。
diffie-hellman-group-exchange-sha256 の削除は、鍵の種類と無関係に効く。鍵を Ed25519 にしても、クライアントがこの鍵交換方式しか提示できなければ接続は通らない。changelog は「上の一覧にある SHA-2 対応の実装なら、強い鍵交換方式にも対応しているはずだ」と書くだけで、残る方式の一覧は示していない。
ブラウンアウトが2回あるのは、ここの切り分けに使える。削除を先取りして落とす日なので、11月4日と12月9日に自分の接続が失敗するなら、対象に当たっているということになる。その2日を通過したなら削除時も通ると推測できるが、changelog はブラウンアウトの時間帯も範囲も書いていない。
10月14日に有効になる mlkem768x25519-sha256 は、利用者側の変更を求めないとされる。優先するよう設定されたクライアントは自動で使い、古いクライアントは以前の鍵交換方式に自動で落ちる。対象は github.com と、データレジデンシー付きの GitHub Enterprise Cloud。ただし米国リージョンだけは、この追加の対象外だ。除外の理由は書かれていない。
この項目だけは、期日までに直すものがない。鍵交換の選択肢が一つ増える話で、対応していないクライアントは従来の方式のまま繋がる。
自分で GitHub Enterprise Server を運用しているなら、上の日程表よりアップグレード計画のほうを見る。今回の変更は GHES 3.25 で効く。例外は mlkem768x25519-sha256 の追加で、こちらは3.24で入る。それぞれのリリース時期は changelog に書かれていない。
SHA-1 を外す作業は HTTPS 側でも別に進んでいて、changelog には9月15日付で「SHA-1 in HTTPS on GitHub sunset」が並ぶ（GitHub の HTTPS から SHA-1 が消えた）。SSH 側は日程も対象も別に動く。今日やることがあるとすれば、使っている SSH 実装の版を上の表と照らすことだけだ。届いていれば鍵は触らずに済む。届いていなければ最初のブラウンアウト前に、署名方式だけが問題なら実装を更新するか Ed25519 または ECDSA の鍵を試す。鍵交換方式にも対応できないなら、鍵の交換では直らず、対応する実装への更新が必要だ。
