Ubuntu 如何啟用後量子 SSH 金鑰交換？

後量子 SSH 的變更內容

大多數使用者已預設啟用後量子 SSH，且無需進行任何設定。當前版本的 OpenSSH 客戶端與伺服器連線時，會預設選擇混合式後量子金鑰交換（hybrid post-quantum key exchange），確保連線金鑰能抵禦攻擊者在今日側錄流量並於未來解密。此保護機制確實存在，但其範圍比「量子安全 SSH」（quantum-safe SSH）一詞所暗示的更為狹窄。

首先釐清兩個術語。SSH（secure shell）是您登入伺服器所使用的協定。金鑰交換（key exchange，通常簡稱為 kex）是每個 SSH 連線的第一步：雙方協議出一組共享密鑰，後續所有傳輸內容皆以此密鑰加密。本次變更僅限於金鑰交換部分，其餘部分均未更動。

請勿盲目信任本頁內容，請務必執行指令

下方列出的演算法名稱均來自您可以自行執行的指令。這是刻意安排的。預設值會隨著每次 OpenSSH 的發布而變動，因此兩年前撰寫的指南所提到的演算法，您的機器可能已不再優先採用，且該指南無法告知您這一點。請學習這些指令，您便不再需要依賴這類文章，包括本文。

從您的建置版本所支援的功能開始。

ssh -V
ssh -Q kex

ssh -V 會印出一行以 OpenSSH_ 開頭的版本資訊，後接 Ubuntu 套件後綴與 OpenSSL 版本。ssh -Q kex 會逐行印出金鑰交換演算法。在支援後量子密碼學（post-quantum）的建置版本中，您會在清單中發現如 mlkem768x25519-sha256 與 sntrup761x25519-sha512@openssh.com 等名稱，並與 curve25519-sha256 等傳統名稱並列。

建置支援的功能與實際提供的功能並不相同

這是大多數文章都會忽略的區別。ssh -Q kex 回答了一個問題：此二進位檔能做什麼。它並未回答您真正在意的問題：此連線實際上會提議什麼。這兩個清單並不相同，而兩者之間的落差正是舊建議造成實際損害的地方。

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

mlkem768x25519-sha256 是一種混合機制。它同時執行參數集為 768 的 ML-KEM（模組格密鑰封裝機制，標準化為 FIPS 203）與 X25519 橢圓曲線 Diffie-Hellman，並將兩者的輸出混合為對話密鑰。

若面對較舊的伺服器，您可能會看到：

debug1: kex: algorithm: curve25519-sha256

該名稱不包含後量子密碼學部分。curve25519-sha256 僅為橢圓曲線 Diffie-Hellman，大型量子電腦可破解此演算法。這正是預設值變更的主因。

有一條協商規則解釋了為何單一台舊機器會拖累整個連線。客戶端會按優先順序發送演算法列表，伺服器亦同；最終選擇的演算法是客戶端列表中第一個同時出現在伺服器列表中的名稱。客戶端的偏好優先，因此兩端中較舊的一方決定了協商結果的上限。升級您的筆記型電腦，並不會讓連線升級至一台從未聽過 ML-KEM 的伺服器。

ssh -v 的價值不僅止於此行輸出，因為當登入被直接拒絕時，您也可以在相同的輸出中 追蹤 Permission denied (publickey) 失敗的原因。

移除 grep 並使用 ssh -v 即可顯示完整的協商過程，包含下一節將討論的內容：

debug1: kex: host key algorithm: ssh-ed25519

哪一個 OpenSSH 版本將混合式金鑰交換設為預設值

上游發布說明提供了明確的時序。日期比版本號更重要，因為這顯示了該功能已在背景運作了多久。

• 8.5 版（2021-03-03 發布）加入了 sntrup761x25519-sha512@openssh.com，但預設為停用。
• 9.0 版（2022-04-08 發布）將其啟用。發布說明指出 OpenSSH 將「預設使用混合式 Streamlined NTRU Prime + x25519 金鑰交換方法」。這是後量子金鑰交換成為常態的版本。
• 9.9 版（2024-09-19 發布）加入了 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 或更新版本的兩台機器，在無需額外設定且未通知輸入 ssh 使用者的情況下，皆已採用後量子金鑰交換。

哪些 Ubuntu 版本內建此功能

Ubuntu 會在發行時鎖定 OpenSSH 版本，並將安全性修補程式向後移植（backport），而不會變更版本號。因此，您所使用的 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，並會針對非後量子（post-quantum）連線發出警告。

請實際測試一對機器。若使用 26.04 的筆電連線至 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 的大型量子電腦為止，屆時再進行解密。這稱為「先截獲後解密」（harvest now, decrypt later），或稱「先儲存後解密」（store now, decrypt later）。這對當前的攻擊者而言無需高超技術，僅需磁碟空間與耐心。

加密機制存在此問題，但數位簽章則不然，這種不對稱性主導了後續的所有決策。已記錄的密文，其價值取決於內部資料的敏感程度；而簽章僅需在驗證當下無法被偽造即可。在 2035 年破解簽章演算法，僅能讓攻擊者在 2035 年冒充伺服器，無法回溯偽造 2026 年的登入紀錄。因此，金鑰交換必須優先修復，而簽章部分則可稍後處理。

混合式（hybrid）意味著兩種演算法同時執行，且兩者的結果皆會匯入工作階段金鑰（session key）。若要恢復 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 (transport layer security) 是您的網頁伺服器在 443 埠所使用的協定，其程式碼庫與更新時程皆不相同。升級 OpenSSH 對此並無影響。若您在 同一台 VPS 上為私人服務執行自簽憑證，其簽章與金鑰交換是由 OpenSSL 與您的網頁伺服器決定，請針對該技術堆疊另行評估。

稱職的維運人員現在該做的事

保持 OpenSSH 處於最新狀態，僅此而已。這確實是解決此問題的完整策略。sudo apt update && sudo apt upgrade 會讓您維持在 Ubuntu 發行版所提供的版本，而升級至較新的 Ubuntu 發行版，即會自動更新 OpenSSH。啟用 自動安全性更新 可確保在您未留意時套用這些修補程式。為了追求特定的演算法名稱而從原始碼編譯 OpenSSH 是不划算的，因為這會讓您失去發行版針對該伺服器上最暴露服務所提供的安全性更新。若您仍決定取得原始碼，請務必在編譯前 比對下載檔案的校驗碼。

請勿手動編寫 KexAlgorithms 設定行。這是最容易導致問題惡化的操作。一份 2018 年的加固指南所提供的清單在當時或許正確，但將其貼入 sshd_config 會取代預設清單，而非進行補充。這會導致自該時間點後發明的所有演算法皆被排除，使得原本能協商出 mlkem768x25519-sha256 的伺服器，被迫降級使用固定清單中殘存的演算法。請在任何接手的伺服器上執行 sudo sshd -T | grep -i '^kexalgorithms'。若該行長度短於相同發行版全新安裝的預設值，代表有人曾對其進行過限制。

若您有正當理由需要變更清單，請採用附加方式而非取代。OpenSSH 會將開頭為 + 的項目視為附加，開頭為 - 視為移除，開頭為 ^ 則視為移至最前端。

KexAlgorithms ^mlkem768x25519-sha256

在依賴設定檔前請先進行測試。sudo sshd -t 會解析設定檔，若語法正確則不會輸出任何訊息。若 KexAlgorithms 行中指定的演算法不存在於目前的建置版本中，將導致 sshd 無法啟動；在遠端伺服器上，這意味著您將無法再次登入，因此作業時請務必保持另一個連線階段開啟。當雙方的演算法清單不再有交集時，用戶端會明確顯示：

Unable to negotiate with 203.0.113.10 port 22: no matching key exchange method found. Their offer: curve25519-sha256,ecdh-sha2-nistp256

將「量子安全」（quantum-safe）的行銷用語視為僅針對單一層級的聲明。廠商稱產品為量子安全時，僅是指其所指名的特定層級，且該層級通常僅為某處的密鑰交換。請要求提供演算法名稱及其適用的協定。以 2026 年 8 月的 OpenSSH 而言，誠實的說法是其密鑰交換採用混合式後量子加密，而簽章仍為傳統加密。任何超出此範圍的宣稱，都應提供您能在 ssh -Q kex 輸出中找到的名稱。

持續做好基礎工作。後量子密鑰交換無法解決密碼容易被猜測，或私鑰被複製到筆記型電腦後遭竊的問題。這些才是導致伺服器被入侵的真正原因，而 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 開始在連線未協商出抗量子演算法時發出警告。請使用 ssh -Q kex 與 ssh -G <host> 檢查您目前的建置版本，因為您所使用的 Ubuntu 版本決定了您所擁有的功能。

我應該產生抗量子 SSH 金鑰嗎？

不需要，因為 OpenSSH 目前沒有這類金鑰類型。目前的抗量子技術僅涵蓋金鑰交換，這不需要您提供任何金鑰檔案，也無需進行任何設定。主機金鑰與登入金鑰仍使用 Ed25519 或 RSA 等傳統簽章，開發團隊已表示抗量子簽章將在未來版本中加入。請繼續使用 Ed25519 金鑰，並妥善保護其儲存位置。

為什麼 ssh 警告我的連線不具備抗量子安全性？

當協商出的交換演算法不包含抗量子部分時，OpenSSH 10.1 及更新版本會顯示 ** WARNING: connection is not using a post-quantum key exchange algorithm.。此警告針對的是伺服器而非您的客戶端，因為您的客戶端已提供抗量子名稱，但伺服器並未接受任何一個。請升級伺服器的 OpenSSH，或檢查是否有人在 sshd_config 中鎖定了 KexAlgorithms 行，導致排除了現代演算法名稱。設定 WarnWeakCrypto no 可以隱藏此訊息，但連線的安全性強度將維持不變。