NoteStack

This page explains what the SSH warning about “not using a post-quantum key exchange algorithm” means, how to verify the actually selected KEX from ssh -vv, and remember: seeing mlkem in the proposal list does not mean it was used.

SSHのWARNING：post-quantum鍵交換ではないと言われたときの確認と対策

Git Bash などから ssh でサーバーへ接続したとき、次のような WARNING が出ることがあります。

WARNING: connection is not using a post-quantum key exchange algorithm.
This session may be vulnerable to "store now, decrypt later" attacks.
The server may need to be upgraded.

このページでは、初心者の方でも混乱しないように「何が起きているのか」「今すぐ対応が必要なのか」「どこを見れば判断できるのか」を、手順つきでまとめます。

このWARNINGは何を意味する？（まずやさしく）

ざっくり言うと、SSH の“最初の握手”（鍵交換 / KEX）で 耐量子（Post-Quantum）方式が使われなかった、という注意です。

ここで言う「耐量子」は、将来とても強い量子コンピューターが普及したときに、過去の通信が復号される可能性（いま盗聴して保存し、将来解読する）に備える考え方です。

重要：この WARNING は「いま乗っ取られている」ではありません。多くの場合は、クライアント（あなたのPC側）とサーバー側で、耐量子KEXの共通対応がなく、従来方式にフォールバックしただけです。

先に結論：今すぐ対策が必要なケース／不要なケース

多くの個人サーバー運用での結論
現時点の安全性（盗聴・改ざん耐性）が直ちに崩れる話ではないため、すぐに危険という意味ではありません。ただし「長期機密（何年も秘密であるべき情報）」を扱うなら、将来的には対応を考える価値があります。
いま対応したほうが良い例
医療・契約・研究データなど「将来に渡って漏れてはいけない情報」を SSH で扱う／規制や社内要件で PQ 対応が必須、など。
いま急がなくて良い例
個人のWebサーバー運用で、主にメンテ作業や設定変更が目的（短期の作業ログ程度）など。OS更新のタイミングで自然に追従するのが現実的です。

誤解しやすいポイント：mlkem... が見えても「使われた」とは限らない

ssh -vv のログで、次のように mlkem768x25519-sha256 が見えることがあります。

debug2: KEX algorithms: mlkem768x25519-sha256, sntrup761x25519-sha512, ...

これはたいていの場合、クライアントが「使える候補」を並べて提案している一覧です。ここに載っている＝採用された、ではありません。

採用された方式は、ログの後半に出る次の形式の行で判断します。

kex: algorithm: XXXXX

確認手順（初心者でも迷わない）

ステップ1：詳細ログを出す

クライアント（あなたのPC）側で実行します。

ssh -vv ユーザー名@サーバー名

（例）ホスト別名を使っているなら：

ssh -vv sakura-vps

ステップ2：「本当に採用されたKEX」を探す

出力の中から、次の行（または近い表現）を探します。

kex: algorithm: ...

ステップ3：判定する

PQ（耐量子）KEX が採用されている例
kex: algorithm: mlkem768x25519-sha256 のように、mlkem を含む方式が採用されていれば、WARNING の趣旨は解消しています。
従来型KEXにフォールバックしている例
curve25519-sha256 などが採用されている場合は、サーバー側が PQ に対応していない可能性が高く、WARNING が出ます。

なぜWARNINGが出るの？（もう少し正確に）

SSH 接続は、最初に「鍵交換（KEX）」で“この接続専用の共通鍵”を作ります。クライアントとサーバーが同じ方式に合意できない場合、両者が対応している別の方式に切り替えます（フォールバック）。

この WARNING は、耐量子方式が採用されなかったことを知らせるだけで、暗号自体が弱いと言っているわけではありません。現代の脅威モデルでは十分安全でも、「将来の量子」を想定するとリスクが残る、という位置づけです。

対策（現実的な順番）

対策A：サーバー側の OpenSSH を更新（可能なら最優先）

WARNING の本文に「server may need to be upgraded」とある通り、サーバー側が PQ KEX に対応していないと、クライアントだけ新しくしても解決しません。

サーバーにログインできる状態で、まず現状確認：

ssh -V
rpm -q openssh openssh-server

次に、OS の標準更新で上がる範囲は上げます（運用判断の上で実行してください）。

sudo dnf update -y openssh\*
sudo systemctl restart sshd

更新後、もう一度クライアントから ssh -vv を実行し、kex: algorithm: 行で採用KEXが変わったか確認します。

対策B：クライアント（Git Bash / OpenSSH）を更新

Git for Windows を更新すると、同梱の OpenSSH が更新され、PQ 対応が改善する場合があります。まずはバージョン確認：

ssh -V

対策C：「警告だけ消す」設定変更はおすすめしない

見た目上の WARNING を抑制する方法があっても、根本原因（PQ KEX 未採用）が変わらなければ意味が薄いです。まずは「採用KEXを確認」→「更新できる範囲で更新」が王道です。

やらなくていい（事故りやすい）こと

チェックリスト（この順で見ればOK）

  1. ssh -vv を実行する
  2. kex: algorithm: の行を探す
  3. 採用KEXが mlkem... なら（少なくともこの警告の趣旨は）解消
  4. 採用KEXが従来型なら、サーバー側 OpenSSH が PQ 非対応の可能性が高い
  5. 運用要件（長期機密かどうか）で「今対応するか／OS更新時に対応するか」を決める