GitHubとの通信でも使われているOpenSSHの耐量子暗号(PQC)対応を調べてみた

GitHubとの通信でも使われているOpenSSHの耐量子暗号(PQC)対応を調べてみた

2025.12.22

将来の量子コンピュータによる解読に耐えられる暗号技術としてPQC(耐量子暗号)が急速に広まっています。

OpenSSHはNISTが2024年に標準決定する何年も前からPQCをデフォルトで動くようにサポートしてきたため、比較的多くのクライアント・サーバー環境ではOpenSSHのバージョンを意識することなく、PQC鍵交換を利用できます。

本記事では、OpenSSHのPQC対応状況を整理し、バージョンによって、実際にPQCが使われていることを動作確認します。

PQC(Post-Quantum Cryptography)とは

PQC(耐量子暗号)は、将来的に実用化が見込まれる量子コンピュータによる解読に耐えられる暗号技術です。

現在広く使われているRSAやECDSAなどの公開鍵暗号は、量子コンピュータの登場により危殆化する可能性があります。

米国国立標準技術研究所(NIST)は2016年からPQCの公募を開始し、2024年に標準アルゴリズムを決定しました。

PQCはあくまでも総称のため、格子暗号や符号暗号など、様々な実現方法があります。

例えば、NISTが標準化したPQCは鍵交換・署名ともに異なる暗号方式が採用されており、脆弱性等が発見された場合のバックアップとして位置づけられています。

用途 規格 NIST標準名称 旧称 数学的基盤
鍵交換 FIPS 203 ML-KEM CRYSTALS-Kyber モジュール格子
署名 FIPS 204 ML-DSA CRYSTALS-Dilithium モジュール格子
署名 FIPS 205 SLH-DSA SPHINCS+ ハッシュ関数
署名 FIPS 206(ドラフト) FN-DSA Falcon NTRU格子
鍵交換 FIPS化予定 HQC HQC 符号理論

Harvest Now, Decrypt Later攻撃

今すぐにでもPQC対応を検討すべき理由が「Harvest Now, Decrypt Later」攻撃です。

攻撃者が現在の暗号化された通信を傍受・保存しておき、将来量子コンピュータが実用化された時点で復号するという攻撃シナリオです。機密性の高い情報や長期間秘匿すべきデータを扱う場合、この攻撃への対策が急務となっています。

OSやブラウザなどがPQC対応を進めている背景には、この攻撃に対する防御が含まれています。

検証ケース

SSH接続でPQCが使用されるかどうかは、サーバーとクライアント双方の対応状況によって決まります。

# クライアント サーバー 結果
1 PQC対応 PQC対応 PQC鍵交換が使用される
2 PQC対応 PQC非対応 古典方式にフォールバック (最近のバージョンは警告表示)
3 PQC非対応 PQC対応 古典方式にフォールバック
4 PQC非対応 PQC非対応 古典方式

この中で、1つ目と2つ目の動作を確認します。

ケース1: PQC対応クライアント + PQC対応サーバー

クライアントとサーバーの両方がPQCに対応している場合のみ、PQC鍵交換が使用されます。

GitHub.com は2025年9月から SSH プロトコルでの通信で PQCに対応しています。

https://github.blog/engineering/platform-security/post-quantum-security-for-ssh-access-on-github/

クライアントから以下のコマンドを叩いてみましょう

$ ssh -v git@github.com exit 2>&1 | grep 'kex: algorithm:'
debug1: kex: algorithm: sntrup761x25519-sha512

鍵交換方式(kex: algorithm:)として sntrup761x25519-sha512 というのは見慣れない鍵交換アルゴリズムが表示されています。

sntrup761x25519-sha512 というのは、次の2つがハイブリッドで使われていることを意味します。

  • 耐量子(格子)暗号 : sntrup761
  • 楕円曲線暗号 : x25519

現在の鍵交換方法は、楕円曲線暗号等の従来方式から耐量子暗号への過渡期にあり、ハイブリッド方式が採用されています。従来のX25519と新しいPQCアルゴリズムを組み合わせることで、どちらか一方が破られても安全性を保てる設計になっています。

HTTPS 通信時の鍵交換でも、同様にハイブリッドの X25519MLKEM768 などが急速に普及しています。

https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/

クライアント環境のバージョンが古いと、従来のような鍵交換方式が出力されるはずです

$ ssh -v git@github.com exit 2>&1 | grep 'kex: algorithm:'
debug1: kex: algorithm: curve25519-sha256

ケース2: クライアントはPQC対応しているがサーバーがPQC対応していない

比較的新しいPQC対応したクライアント環境から、PQC対応以前の OpenSSH 7.6@Ubuntu 18.04 のような古い sshd と通信すると、PQC鍵交換は使用されません。

耐量子コンピュータは未来の技術ですが、攻撃者が通信を傍受して保存し、将来量子コンピュータが実用化された時点で復号する「Store Now, Decrypt Later/Harvest Now, Decrypt Later」という攻撃が知られています。

OpenSSH 10.1以降のクライアントがPQC非対応なサーバーに接続すると、この攻撃に対する注意喚起が表示されるようになりました。

$ ssh -V
OpenSSH_10.2p1, OpenSSL 3.6.0 1 Oct 2025

$ ssh xxx@host.example.internal
Warning: Permanently added '[host.example.internal]:49882' (ED25519) to the list of known hosts.

** 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

Welcome to Ubuntu 18.04.6 LTS (GNU/Linux 4.15.0-212-generic aarch64)

OpenSSHのPQC対応

OpenSSHのPQC対応履歴

OpenSSHのPQC対応の特徴の一つは、NISTが2024年に標準決定する前からPQCをデフォルトで動くようにサポートしてきた点です。NISTの標準化から外れたNTRU系の格子暗号が2022年からデフォルトで動作しているのは、そうした背景もあります。

バージョン 内容 状態
8.6 (2021-04) sntrup761x25519-sha512 選択的に利用可能
9.0 (2022-04) sntrup761x25519-sha512 デフォルトで選択
9.9 (2024-09) mlkem768x25519-sha256 選択的に利用可能
10.0 (2025-04) mlkem768x25519-sha256 デフォルトで選択
10.1 (2025-10) 非PQCサーバー接続時に警告表示 -

※ 8.0〜8.5 では sntrup 系が実験的にサポートされていました

接続時のネゴシエーション内容を確認

local client KEXINIT proposal がクライアント側、peer server KEXINIT proposal がサーバー側の鍵交換アルゴリズム一覧です。

$ ssh -vv git@github.com 2>&1 | grep 'KEXINIT proposal' -A1
debug2: local client KEXINIT proposal
debug2: KEX algorithms: sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,mlkem768x25519-sha256,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,kex-strict-c-v00@openssh.com
--
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,kex-strict-s-v00@openssh.com

クライアントの鍵交換アルゴリズム一覧

お使いのSSHクライアントがPQCをサポートしているか確認するには、以下のコマンドを実行します。

$ ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
curve25519-sha256@libssh.org
sntrup761x25519-sha512
sntrup761x25519-sha512@openssh.com
mlkem768x25519-sha256

サーバーがサポートするアルゴリズム一覧(nmap利用)

$ nmap --script ssh2-enum-algos -sV -p 22 example.com

Starting Nmap 7.98 ( https://nmap.org ) at 2025-12-19 00:57 +0900
Nmap scan report for example.com (xx.xx.xx.xx)
Host is up (0.022s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     (protocol 2.0)
| ssh2-enum-algos:
|   kex_algorithms: (9)
|       sntrup761x25519-sha512
|       sntrup761x25519-sha512@openssh.com
|       curve25519-sha256
|       curve25519-sha256@libssh.org
|       ecdh-sha2-nistp256
|       ecdh-sha2-nistp384
|       ecdh-sha2-nistp521
|       diffie-hellman-group-exchange-sha256
|       kex-strict-s-v00@openssh.com
|   server_host_key_algorithms: (5)
|       ssh-ed25519
|       ecdsa-sha2-nistp256
|       rsa-sha2-512
|       rsa-sha2-256
|       ssh-rsa
|   encryption_algorithms: (6)
|       chacha20-poly1305@openssh.com
|       aes256-gcm@openssh.com
|       aes128-gcm@openssh.com
|       aes256-ctr
|       aes192-ctr
|       aes128-ctr
|   mac_algorithms: (4)
|       hmac-sha2-512-etm@openssh.com
|       hmac-sha2-256-etm@openssh.com
|       hmac-sha2-512
|       hmac-sha2-256
|   compression_algorithms: (2)
|       none
|_      zlib@openssh.com
| fingerprint-strings:
|   NULL:
|_    SSH-2.0-1e748d5
1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service :
SF-Port22-TCP:V=7.98%I=7%D=12/19%Time=69442465%P=arm-apple-darwin24.4.0%r(
SF:NULL,11,"SSH-2\.0-1e748d5\r\n");

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 7.11 seconds

アルゴリズムの強制指定

クライアント側でPQCアルゴリズムのみを指定できます。

$ ssh -o KexAlgorithms=mlkem768x25519-sha256 example.com

まとめ

GitHubが2025年9月に発表した耐量子暗号(PQC)対応をきっかけにPQC over SSHについて調べました。

OpenSSHがデフォルトでPQCをサポートするようになって数年経過しているため、比較的新しいクライアント・サーバー環境ではユーザーが意識することなく、よりセキュアな通信方式としてPQCが自動的に利用されています。

機密性の高いデータを扱うGitHubにとって、このPQC対応はユーザー、特に金融・ヘルスケアのようなセキュリティ要件の厳しい利用者に安心感を与える重要な一歩です。この対応を裏で支えるOpenSSHが、NISTの標準化より数年も前からPQCをデフォルト化していたおかげで、今日、クライアント・サーバー双方でのスムーズなPQC移行が実現しているのだと感じました。

2025年10月に登壇したPQCのSSHトピックを掘り下げたブログです。

参考資料

この記事をシェアする

FacebookHatena blogX

関連記事