著者 UbuntuのSSHはポスト量子化で何が変わった？
現行のOpenSSHはポスト量子鍵交換をデフォルトで使います。Ubuntuで実際のkexを確認し、ホスト鍵が従来型のまま残る理由もコマンドで確かめます。
ポスト量子 SSH で変わったこと
ポスト量子 SSH は、すでに大半の利用者の環境で有効になっており、利用者が設定する必要はありません。現行の OpenSSH client が現行の OpenSSH server に接続すると、デフォルトでハイブリッド方式のポスト量子鍵交換が選択されます。そのため、現在のネットワークトラフィックを記録し、数年後に復号しようとする攻撃者に対しても、セッション鍵が耐性を持ちます。この保護は実際に機能しますが、「quantum-safe SSH」という表現から受ける印象ほど範囲が広いものではありません。
まず、2つの用語を確認します。SSH（secure shell）は、サーバーにログインするためのプロトコルです。鍵交換は通常「kex」と表記され、すべての SSH 接続で最初に行われます。接続の両端が共有秘密を合意し、その秘密によって以降のすべての通信が暗号化されます。今回変わったのは鍵交換の部分です。それ以外は変わっていません。
このページを信頼せず、コマンドを実行してください
以下の各アルゴリズム名は、すべて自分で実行できるコマンドの出力に基づいています。これは意図的なものです。OpenSSH のリリースごとにデフォルト設定は変わります。そのため、2 年前に書かれたガイドでは、現在のマシンが優先しなくなったアルゴリズムが示されていることがあります。しかし、そのガイドからは判断できません。これらのコマンドを覚えれば、この記事を含め、この話題に関する記事に頼る必要がなくなります。
まず、使用中のビルドで利用できる機能を確認します。
ssh -V
ssh -Q kexssh -V は OpenSSH_ で始まるバージョン行を出力し、その後に Ubuntu パッケージのサフィックスと OpenSSL のバージョンが続きます。ssh -Q kex は、鍵交換アルゴリズムを 1 行に 1 つずつ出力します。耐量子暗号に対応したビルドでは、一覧に mlkem768x25519-sha256 や sntrup761x25519-sha512@openssh.com などの名前が、curve25519-sha256 のような従来型の名前と並んで表示されます。
ビルドが対応していることと、実際に提示することは異なります
この違いは、多くの記事で省かれています。ssh -Q kexが答えるのは、「このバイナリで何ができるか」という問いです。しかし、必要なのは「この接続で実際に何を提示するか」という問いへの答えです。この2つの一覧は異なります。その差が、古い情報による実害の原因になります。
ssh -G example.com | grep -i '^kexalgorithms'
sudo sshd -T | grep -i '^kexalgorithms'ssh -G <host>は、~/.ssh/configと/etc/ssh/ssh_configを適用した後の、そのホストに対するクライアントの実効設定を表示します。sshd -Tは、サーバーについて同じ処理を行います。どちらも優先順位順に並んだ単一のkexalgorithms行を表示します。その行の先頭にある名前が、その側の第一候補です。この行の内容が、実際にネットワーク上で提示されます。
この差は理論上のものではありません。2021-03-03 にリリースされた OpenSSH 8.5 では、sntrup761x25519-sha512@openssh.comが追加されましたが、デフォルトの一覧には意図的に含まれませんでした。このリリースでは、ssh -Q kexにはそのアルゴリズムが表示されますが、ssh -Gには表示されません。つまり、そのバイナリはポスト量子鍵交換を実行できますが、実際の接続でそれが要求されることはありません。
接続でネゴシエートされたアルゴリズムを確認する
ssh -v example.com 2>&1 | grep 'kex: algorithm'現在のクライアントと現在のサーバー間では、次のように表示されます。
debug1: kex: algorithm: mlkem768x25519-sha256mlkem768x25519-sha256 はハイブリッド方式です。パラメータセット 768 の ML-KEM（module-lattice key encapsulation mechanism、FIPS 203 として標準化）と、X25519 elliptic curve Diffie-Hellman を使用し、両方の出力をセッションキーに混ぜ合わせます。
古いサーバーに接続すると、代わりに次のように表示されることがあります。
debug1: kex: algorithm: curve25519-sha256この名前には post-quantum の要素がありません。curve25519-sha256 は単独の elliptic curve Diffie-Hellman であり、大規模な量子コンピューターによって破られます。これがデフォルトが変更された理由です。
1 台の古いマシンによってセッションの方式が制限される理由は、1 つのネゴシエーション規則で説明できます。クライアントは優先順位順に一覧を送信し、サーバーも独自の一覧を送信します。選択されるアルゴリズムは、クライアントの一覧にある名前のうち、サーバーにも存在する最初の名前です。クライアントの優先順位が優先されるため、両端のうち古い側によって、一覧のどこまで使用できるかが決まります。ノートパソコンをアップグレードしても、ML-KEM を認識しないサーバーとのセッション方式はアップグレードされません。
ssh -v は、この 1 行以外の理由でも知っておく価値があります。ログインが完全に拒否されたときに、同じ出力から Permission denied (publickey) エラーを調査できるためです。
grep と ssh -v を削除すると、次のセクションで扱う行を含め、ネゴシエーションの残りが表示されます。
debug1: kex: host key algorithm: ssh-ed25519どの OpenSSH リリースでハイブリッド交換がデフォルトになったか
upstream のリリースノートには、明確な経緯が示されています。バージョン番号より日付が重要です。これにより、この仕組みがどれほど長く静かに運用されてきたかが分かります。
- 8.5 は 2021-03-03 にリリースされ、
sntrup761x25519-sha512@openssh.comを追加しました。ただし、デフォルトでは無効でした。 - 9.0 は 2022-04-08 にリリースされ、これを有効にしました。リリースノートには、OpenSSH が「ハイブリッド方式の Streamlined NTRU Prime + x25519 key exchange method をデフォルトで使用する」と記載されています。ポスト量子鍵交換が通常の動作になったのは、このリリースからです。
- 9.9 は 2024-09-19 にリリースされ、2 つ目の選択肢として
mlkem768x25519-sha256を追加しました。同じリリースで、従来の方式に IANA 登録名sntrup761x25519-sha512が付けられました。そのため、新しいビルドでは両方の表記で一覧に表示されます。 - 10.0 は 2025-04-09 にリリースされ、鍵合意のデフォルトを
mlkem768x25519-sha256に変更しました。 - 10.1 は 2025-10-06 にリリースされ、ポスト量子方式の要素を含まない鍵交換が接続時にネゴシエートされた場合に、クライアントが警告を表示する機能を追加しました。この機能は
ssh_configのWarnWeakCryptoオプションで制御され、デフォルトで有効です。
覚えておくべき日付は 2022 年 4 月です。OpenSSH 9.0 以降を実行している 2 台のマシン間では、それ以降、設定を変更しなくてもポスト量子鍵交換が実行されています。ssh を入力する利用者に通知はありません。
Ubuntu のどのリリースに含まれているか
Ubuntu はリリース時点で OpenSSH のバージョンを固定し、その後はバージョン番号を変更せずにセキュリティ修正をバックポートします。そのため、実行している Ubuntu のリリースによってデフォルトのアルゴリズムが決まります。一覧をそのまま信頼せず、ssh -V で目の前のマシンを確認してください。2026 年 8 月時点で、アーカイブには次のバージョンがあります。
- 22.04 LTS には
1:8.9p1が含まれます。これは 9.0 より前のため、標準インストールではcurve25519-sha256をネゴシエートします。 - 24.04 LTS には
1:9.6p1が含まれます。これは 9.0 より後かつ 9.9 より前のため、デフォルトはsntrup761x25519-sha512@openssh.comで、ML-KEM はありません。 - 25.10 には
1:10.0p1が含まれ、デフォルトはmlkem768x25519-sha256です。 - 26.04 LTS には
1:10.2p1が含まれ、デフォルトはmlkem768x25519-sha256です。また、ポスト量子ではない接続について警告します。
実際の 2 台のマシンで確認します。26.04 のノート PC から 24.04 のサーバーに接続します。クライアントの最初の選択肢 mlkem768x25519-sha256 は、9.6 のサーバーの一覧にありません。サーバーが対応している次のポスト量子方式の選択肢は sntrup761x25519-sha512@openssh.com であり、ssh -v が報告する名前もこれです。2024 年に構築されたサーバーに対して、設定を追加しなくても、鍵交換はポスト量子方式になります。
22.04 の場合は逆で、ssh -Q kex だけでは判断を誤る理由がよく分かります。OpenSSH 8.9 は sntrup761x25519-sha512@openssh.com という名前を認識するため、そのマシンで ssh -Q kex を実行すると一覧に表示されます。しかし、デフォルトの提案には含まれないため、ネゴシエーションでは curve25519-sha256 が選択されます。OpenSSH 10.1 以降のクライアントから接続すると、次のように表示されます。
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.この警告は、クライアントではなく、接続先サーバーについての事実です。対処方法はサーバーをアップグレードすることです。WarnWeakCrypto no を設定するとメッセージは消えますが、接続の内容は変わりません。
なぜハイブリッドなのか、また「今収集し、後で復号する」とは何か
脅威の構造は単純です。ネットワークトラフィックを見られる攻撃者は、暗号化されたバイト列を今記録して保存します。今すぐ読み取ることはできません。X25519 を破れる規模の量子コンピューターが実現するまで保持し、その後で読み取ります。これは「今収集し、後で復号する」、または「今保存し、後で復号する」と呼ばれます。現時点で攻撃者に高度な手法は必要ありません。必要なのはディスク容量と忍耐だけです。
この問題は暗号化にはありますが、署名にはありません。この非対称性が、その他すべての判断を左右します。記録された暗号文は、その内部のデータが機密である限り価値を保ちます。一方、署名は検証された時点で偽造できなければ十分です。2035 年に署名アルゴリズムを破れるようになっても、誰かが 2035 年にサーバーになりすませるだけです。2026 年のログインを過去にさかのぼって偽造することはできません。そのため、最初に鍵交換を対策する必要があり、署名側は後回しにできます。
ハイブリッドでは、両方のアルゴリズムを実行し、両方の結果をセッション鍵の生成に使用します。mlkem768x25519-sha256の背後にある秘密を復元するには、攻撃者は ML-KEM 768 と X25519 の両方を破る必要があります。この組み合わせは意図的なものです。ML-KEM は X25519 より大幅に新しく、暗号解読研究者による攻撃にさらされてきた期間もはるかに短いためです。そのため、新しいアルゴリズムに欠陥が見つかっても、従来から得ていた保護まで失うことはありません。
保護されるものと保護されないもの
鍵交換は保護されます。セッションを暗号化する共有秘密はハイブリッド交換から生成されるため、今日記録したセッションが、量子コンピューターの実用化後に復号可能になることはありません。
ホスト鍵は保護されません。debug1: kex: host key algorithm: ssh-ed25519 の行は古典的な署名方式を指定しており、rsa-sha2-512 と ECDSA（楕円曲線デジタル署名アルゴリズム）の方式も同様です。実用的な量子コンピューターを持つ攻撃者は、その署名を偽造してサーバーになりすませる可能性があります。ただし、それが可能なのは将来、その時点で確立されるライブ接続に対してだけです。現在記録されている通信が攻撃対象になることはありません。
ログイン用の鍵も保護されません。~/.ssh/id_ed25519 にある鍵は、同じ種類の古典的な署名方式です。そのため、同じ説明が当てはまります。今年その鍵を保護するのは、鍵がどこに保存され、誰が読み取れるかという点です。したがって、適切な SSH 鍵管理によって、このページに記載されたアルゴリズム名よりも実際のリスクを大幅に抑えられます。
これらについて対応する必要はありません。切り替え先が存在しないためです。OpenSSH は、ポスト量子署名のサポートを将来のリリースで追加すると表明しています。対応版がリリースされるまで、OpenSSH にはポスト量子ホスト鍵タイプもポスト量子ユーザー鍵タイプもなく、ssh-keygen にも提供できるものはありません。それを生成するよう案内するガイドは、まだ存在しないソフトウェアについて説明しています。
同じサーバーで使用する TLS については、別の問題であり、答えも別です。TLS（トランスポート層セキュリティ）は Web サーバーが 443 番ポートで使用するプロトコルであり、異なるコードベースと異なる開発スケジュールに基づいています。OpenSSH をアップグレードしても、TLS には何も影響しません。同じ VPS でプライベートサービスに自己署名証明書を使用している場合、その署名と鍵交換は OpenSSL と Web サーバーによって決まります。その構成は、個別に確認してください。
現在行うべき、適切な運用
OpenSSH を最新の状態に保ち、それ以上は行わないでください。この問題への対策は、本当にこれだけです。sudo apt update && sudo apt upgrade を使用すると、Ubuntu のリリースに含まれるバージョンが維持されます。新しい OpenSSH を使うには、より新しい Ubuntu リリースへ移行します。自動セキュリティ更新を有効にすると、手動で覚えておかなくてもパッチが適用されます。アルゴリズム名を追いかけるために OpenSSH をソースからビルドするのは、割に合いません。サーバー上で最も外部に公開されるサービスについて、ディストリビューションのセキュリティ更新を受けられなくなるためです。それでもソースを取得する場合は、ビルド前に公開されているチェックサムとダウンロード内容を照合してください。
KexAlgorithms の行を手書きで追加しないでください。これだけは、確実に状況を悪化させる操作です。2018 年のハードニングガイドには、2018 年には正しかった一覧が載っています。それを sshd_config に貼り付けると、既定の一覧への追加ではなく、既定の一覧全体の置き換えになります。その結果、それ以降に追加されたすべてのアルゴリズムが除外され、単独なら mlkem768x25519-sha256 をネゴシエートできるサーバーも、固定された一覧に残った方式まで静かにフォールバックします。引き継いだサーバーでは sudo sshd -T | grep -i '^kexalgorithms' を実行してください。同じリリースを新規インストールした環境の出力より一覧が短ければ、誰かが固定しています。
一覧を変更する本当の理由がある場合は、置き換えずに追加してください。OpenSSH は先頭が + の指定を追加として、先頭が - の指定を削除として、先頭が ^ の指定を先頭へ移動する指定として解釈します。
KexAlgorithms ^mlkem768x25519-sha256設定ファイルを信頼して使用する前にテストしてください。sudo sshd -t は設定を解析し、内容が有効な場合は何も出力しません。ビルドに含まれていないアルゴリズムを指定する KexAlgorithms の行があると、sshd は起動しません。リモートサーバーでは、これは再接続できなくなることを意味します。そのため、作業中は 2 つ目のセッションを開いたままにしてください。双方の一覧に重複する方式がなくなると、クライアントは明確にそのことを表示します。
Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256「量子耐性」という宣伝文句は、1 つの層に関する主張として受け取ってください。ベンダーが製品を量子耐性と呼ぶ場合、説明しているのは指定した層だけであり、通常はどこかの鍵交換層です。アルゴリズム名と、それが適用されるプロトコルを確認してください。2026 年 8 月時点の OpenSSH について、この主張を正確に表現すると、鍵交換はハイブリッドなポスト量子方式ですが、署名は従来方式です。それより広い主張をするなら、ssh -Q kex の出力で確認できる名前を示す必要があります。
地道な対策も続けてください。ポスト量子鍵交換を使用しても、推測しやすいパスワードや、後に盗まれるノート PC にコピーされた秘密鍵には対処できません。実際にサーバーを侵害するのは、こうした問題です。VPS での標準的な SSH ハードニングが、今でも対策の大部分を担います。ここで説明したネゴシエーションの手順が不明な場合は、接続時に SSH が行う処理で、このページが前提としている各段階を確認できます。
FAQ
SSH 接続はすでにポスト量子暗号に対応していますか？
ssh -v yourserver 2>&1 | grep 'kex: algorithm' を実行し、表示された名前を確認します。mlkem768x25519-sha256 と sntrup761x25519-sha512@openssh.com はハイブリッド型のポスト量子鍵交換です。curve25519-sha256、ecdh-sha2-nistp256、および diffie-hellman-group の名前はすべて古典方式です。クライアントとサーバーの両方が、ポスト量子方式の名前を提供するバージョンである必要があります。ネゴシエーションでは、クライアントが最初に提示し、サーバーも対応している方式が選ばれるため、古いマシンの対応状況が上限になります。
ポスト量子鍵交換をデフォルトにした OpenSSH のリリースはどれですか？
2022-04-08 にリリースされた OpenSSH 9.0 は、sntrup761x25519-sha512@openssh.com をデフォルトの鍵交換にしました。2024-09-19 にリリースされた OpenSSH 9.9 は mlkem768x25519-sha256 を追加し、2025-04-09 にリリースされた OpenSSH 10.0 は、こちらをデフォルトにしました。2025-10-06 にリリースされた OpenSSH 10.1 は、どちらもネゴシエーションされなかった場合に警告を表示するようになりました。使用している Ubuntu のリリースによって利用できる方式が決まるため、ssh -Q kex と ssh -G <host> で自分のビルドの動作を確認してください。
ポスト量子 SSH 鍵を生成すべきですか？
いいえ。OpenSSH にはそのような鍵種別がないためです。これまでのポスト量子対応は鍵交換を対象としており、ユーザー側の鍵ファイルも設定も必要ありません。ホスト鍵とログイン鍵は、Ed25519 や RSA などの古典的な署名のままです。upstream は、ポスト量子署名は将来のリリースで導入すると説明しています。引き続き Ed25519 鍵を使用し、その保存場所を適切に保護してください。
ssh が接続はポスト量子暗号に対応していないと警告するのはなぜですか？
OpenSSH 10.1 以降は、ネゴシエーションされた鍵交換にポスト量子方式が含まれない場合、** WARNING: connection is not using a post-quantum key exchange algorithm. を表示します。この警告はクライアントではなくサーバーに関するものです。クライアントはポスト量子方式の名前を提示したものの、サーバーがどれも受け入れなかったためです。サーバーの OpenSSH をアップグレードするか、サーバーの sshd_config に、現行の方式を除外する KexAlgorithms 行が固定されていないか確認してください。WarnWeakCrypto no を設定するとメッセージは非表示になりますが、接続は設定前と同じく脆弱なままです。