本記事は、筆者との対話ログに基づきLLM(Gemini)が全構成・本文を直接執筆した技術レポートです。
実際に発生したエラーログの解析から、原因特定・解決手順の提示・運用上の注意点までをGeminiが整理してまとめています。
最新のOpenSSHクライアント(Macや端末など)からLinuxサーバーにSSH接続した際、以下のような警告メッセージが表示されることがあります。
** 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. See https://openssh.com/pq.html
今回はこの警告を解消するために行った検証と、最終的に判明した原因(CentOS Stream 9の仕様)についてまとめます。
1. 警告の意味と発生原因
この警告は、「接続先のサーバーが耐量子暗号(Post-Quantum Cryptography)に対応した鍵交換アルゴリズム(sntrup761x25519-sha512@openssh.com や mlkem768... など)を使用していない」 ことを意味します。
将来の量子コンピュータによる解読リスク(Store Now, Decrypt Later攻撃)を防ぐため、最新のOpenSSHクライアントが自動的に警告を発しています。
2. 解決に向けて行った検証プロセス
検証①:OpenSSHのバージョン確認
「OpenSSHが古いのかな?」と思い、サーバー側のバージョンを確認しました。
# サーバー内で確認
sshd -V
# 出力例: OpenSSH_9.9p1
結果、サーバー側は耐量子暗号に対応している OpenSSH 9.9p1 でした。バージョン自体には問題がありませんでした。
検証②:sshd_config の確認
特定の鍵交換アルゴリズムが制限されている可能性を疑い、/etc/ssh/sshd_config や /etc/ssh/sshd_config.d/ を調査しました。
grep -ri "KexAlgorithms" /etc/ssh/
しかし、明示的に KexAlgorithms を制限する記述は見つかりませんでした。
検証③:crypto-policies(システム全体の暗号化ポリシー)の確認
CentOS Stream 9 や RHEL 9 系には、システム全体の暗号化設定を統一管理する crypto-policies という機能があります。
設定を確認したところ:
update-crypto-policies --show
# 出力: DEFAULT
crypto-policies が DEFAULT になっており、このシステムポリシーによってOpenSSHが使用できる鍵交換アルゴリズムが制限されていることが判明しました。
検証④:カスタムモジュール追加による回避の試み
crypto-policies に耐量子アルゴリズムを追加しようとカスタムモジュール(.pmod)の作成を試みました。
# PQ-KEX.pmod の記述試行
key_exchange = +sntrup761x25519-sha512@openssh.com
しかし、update-crypto-policies 実行時に構文エラーが発生しました。
Errors found in policy, first one:
Bad value of policy property `key_exchange`: `sntrup761x25519-sha512@openssh.com`
crypto-policies 側が sntrup761... や mlkem... などの暗号識別子を「有効な値」として認識しないため、システムポリシーレベルで設定追加が弾かれる結果となりました。
3. 結論:CentOS Stream 9(RHEL 9系)の仕様
今回の現象の根本的な原因は、CentOS Stream 9(および RHEL 9 系)の crypto-policies における標準仕様です。
- RHEL/CentOS 9 の方針: エンタープライズ向けの安定性を重視するため、比較的新しい「耐量子鍵交換アルゴリズム」を現時点の
DEFAULTポリシーの許可リストに含めていない。 - OpenSSH 側の挙動: サーバー側(CentOS Stream 9)が耐量子鍵交換を拒否するため、従来の鍵交換(
curve25519-sha256等)にフォールバックして接続が確立される。その結果、クライアント側が警告を出力する。
4. どう対応すべきか?
- 直ちに対応する必要はない(静観で問題なし) 従来の強固な暗号方式(AES-256 / Curve25519 等)で通信自体は高度に保護されているため、セキュリティ上の実害はありません。将来的なOSアップデートで
crypto-policies側に耐量子暗号が採用されるのを待つのが安全です。 - 手元(クライアント)側で警告を抑制したい場合 手元PCの
~/.ssh/configに設定を追加するか、接続コマンド側で無視・制御を行うのが最も確実な対処法となります。