Ubuntu 的後量子 SSH：實際啟用哪些功能？

後量子 SSH 的變更

對大多數使用者而言，後量子 SSH 已經啟用，而且不需要手動設定。新版 OpenSSH client 連線至新版 OpenSSH server 時，預設會選擇混合式後量子金鑰交換。因此，即使攻擊者現在記錄你的網路流量，並在多年後解密，工作階段金鑰仍可抵抗這類攻擊。這項防護確實有效，但涵蓋範圍比「量子安全 SSH」這個說法所暗示的更小。

先說明兩個術語。SSH（secure shell）是用來登入 server 的通訊協定。金鑰交換通常寫作「kex」，是每次 SSH 連線的第一個步驟：兩端協議出共用秘密，接著使用該秘密加密後續的所有內容。這次變更的是金鑰交換部分，其他部分沒有變更。

不要相信本頁內容，請自行執行指令

以下列出的每個演算法名稱，都來自您可以自行執行的指令。這是刻意安排的。預設值會隨每個 OpenSSH 版本變更，因此，兩年前撰寫的指南可能列出您的電腦已不再偏好的演算法，而且無法告訴您這項差異。請熟悉這些指令，之後就不必依賴相關文章，包括本篇文章。

先確認您的組建支援哪些功能。

ssh -V
ssh -Q kex

ssh -V 會輸出以 OpenSSH_ 開頭的版本行，後面接著 Ubuntu 套件後綴與 OpenSSL 版本。ssh -Q kex 會逐行輸出一個金鑰交換演算法。在支援後量子功能的組建中，您會在清單中看到 mlkem768x25519-sha256 和 sntrup761x25519-sha512@openssh.com 等名稱，並列於 curve25519-sha256 等傳統演算法名稱旁。

建置支援的項目不等於實際提供的項目

這是大多數文章略過的區別。ssh -Q kex回答的是一個問題：這個 binary 能做什麼？但它沒有回答你真正關心的問題：這個連線實際會提出什麼演算法？這兩份清單不同，而兩者之間的落差正是過時建議造成實際損害的地方。

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，其中第一個名稱就是該端的首選項目。線路上傳送的就是這一行。

這個落差並非理論問題。OpenSSH 8.5 於 2021-03-03 發布，新增了 sntrup761x25519-sha512@openssh.com，但刻意未將它列入預設清單。在該版本中，ssh -Q kex 會顯示這個演算法，而 ssh -G 不會，這表示該 binary 能執行 post-quantum key exchange，卻沒有任何連線會要求使用它。

讀取連線協商的演算法

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 的伺服器之間的工作階段升級。

移除 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 版本，之後只將安全性修正向後移植到該版本，不會變更版本號。因此，您執行的 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，並會對非後量子連線發出警告。

以下實際檢視一組機器。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 的量子電腦，然後再讀取內容。這稱為「現在擷取、日後解密」，也稱為「現在儲存、日後解密」。攻擊者目前不需要採用複雜手法，只需要磁碟空間與耐心。

這個問題存在於加密，簽章則沒有，因此其他設計都受到這種不對稱性的影響。只要密文中的資料仍具敏感性，錄下來的密文就會持續具有價值。簽章只需在驗證當下仍無法偽造即可。若有人在 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，並不是划算的做法，因為您會失去該發行版本對主機上暴露程度最高的服務所提供的安全性更新。如果仍要取得原始碼，請在建置前依照發布的 checksum 驗證下載內容。

不要手動撰寫 KexAlgorithms 設定行。這是唯一一個必定讓情況惡化的動作。2018 年的強化指南會提供一份在 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

對「量子安全」的行銷說法，請將其視為只針對某一層的宣稱。供應商稱產品具備量子安全性時，指的是他們所指定的某一層，而該層通常是某處的金鑰交換。請要求對方提供演算法名稱及其適用的通訊協定。以 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 版本將後量子金鑰交換設為預設值？

OpenSSH 9.0 於 2022-04-08 發布，並將 sntrup761x25519-sha512@openssh.com 設為預設的金鑰交換。OpenSSH 9.9 於 2024-09-19 發布，新增 mlkem768x25519-sha256；OpenSSH 10.0 於 2025-04-09 發布，並改將該項目設為預設值。OpenSSH 10.1 於 2025-10-06 發布，開始在連線協商未使用任何一者時顯示警告。使用 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 只會隱藏訊息，連線的安全性仍與原本相同。