OpenSSH 從 10.0 起就把 mlkem768x25519-sha256 訂為預設的金鑰交換演算法，到了 10.1 甚至會對沒有走 post-quantum KEX 的連線直接跳警告。過了將近一年，簽章這一塊卻沒動——host key、使用者金鑰依舊只剩 Ed25519、ECDSA、RSA 三個可選。2026 年 7 月 6 日釋出的 10.4 把這個空缺補起來：ML-DSA 44 加 Ed25519 的複合簽章第一次以實驗算法的身分進主線，ssh-keygen -t mldsa44-ed25519 可以直接生出 host key 或使用者金鑰。同一份 changelog 裡塞的另一組修補更值得先看——SFTP 跟 SCP 客戶端被惡意伺服器牽著鼻子把檔案寫到別的路徑的漏洞，是這次八項安全修補中影響面最廣的一支。
為什麼 KEX 換完了簽章還得再換一次
Post-quantum KEX 解決的是「今天錄下來、明天量子電腦算出 session key」這條 store-now-decrypt-later 攻擊路徑，重點是保護連線內容的機密性。簽章不一樣，被破解的後果是身分冒充：一把用了三年的 host key 私鑰如果哪天被推回來，攻擊者就能在中間人位置對舊客戶端偽造成整臺伺服器。長效金鑰的威脅視窗遠比 session 長，可是真正能落地的 post-quantum 簽章方案一直卡在成本問題上。
ML-DSA 44 是 NIST FIPS 204 標準底下最小一組參數，公開金鑰 1312 位元組、簽章 2420 位元組，跟 Ed25519 的 32 位元組公鑰、64 位元組簽章比起來，膨脹的是好幾十倍。放進 SSH 握手裡，多出來的往返延遲跟頻寬對走一般網際網路的 VPS 影響有限，但在高頻自動化情境——CI runner 對 Git 伺服器每分鐘拉數十次、Ansible 對數百臺主機 fan-out——就會被放大。10.4 的做法是把 ML-DSA 44 跟 Ed25519 拼成 composite signature，同一組金鑰同時產出兩個簽章，任一邊被破解另一邊還撐得住。設計文件是 IETF 的 draft-miller-sshm-mldsa44-ed25519-composite-sigs，實作上仍算實驗，還沒進 draft-standard 階段。
mldsa44-ed25519 在自架伺服器上的最小可行設定
生金鑰的動作跟過去沒兩樣：
1 | ssh-keygen -t mldsa44-ed25519 -f ~/.ssh/id_mldsa44_ed25519 -C "vps-2026" |
實際會產出將近 4 KB 的公開金鑰檔，authorized_keys 貼進去照樣認得。伺服器端要在 /etc/ssh/sshd_config 補一組 host key 設定，並把演算法加進允許清單：
1 | HostKey /etc/ssh/ssh_host_mldsa44_ed25519_key |
+ 前綴是接在預設清單後面而不取代——這一點很關鍵，寫成 = 或忘了前綴會把 Ed25519、RSA 一起洗掉，非 10.4 客戶端從此連不進來。客戶端這邊 ~/.ssh/config 也得配一份，只設伺服器不設客戶端，握手時仍會回落到 Ed25519：
1 | Host vps-2026 |
^ 是把該演算法插到清單最前，優先協商。日常維運上實驗算法建議只用在特定機器上——用 Match host 或 Host block 圈住，避免整個 fleet 一次改動。至於現有的 Ed25519 host key 該不該砍掉，答案是不該。並存跑一段時間、把 known_hosts 上的 mldsa44 fingerprint 分發完再收掉舊的，任何一步爆炸都還有回頭路。
SFTP 的路徑竊改比新演算法更急
sftp host:/path . 這種命令列下載，過去預設信任伺服器回傳的檔名。10.4 修的其中一支洞就是：惡意伺服器可以在回應裡塞入包含目錄跳脫的檔名，讓客戶端把檔案寫到工作目錄以外的位置，最惡劣的情形是覆蓋掉 .ssh/authorized_keys 或 shell 啟動腳本。SCP 的 remote-to-remote 傳輸也吃到類似的問題，惡意來源可以把檔案倒進上層目錄。兩個都不是要 root 權限、也不需要客戶端接受任何提示的漏洞——只要對方伺服器被打下來、或本來就是不可信的第三方，帳號跑起 sftp/scp 那一刻就中招。
另一個容易被忽略的修補在 sshd 的 internal-sftp 子系統上：命令列超過九個引數之後靜默截斷。這代表 ForceCommand internal-sftp -f -u -d /jail -R -e -o LogLevel=INFO -p 22 -X 這類長設定可能有安全相關的參數就這樣被吃掉、卻沒任何錯誤訊息。用 chroot SFTP 做多租戶檔案伺服器的部署要特別回頭檢查一次。GSSAPI 預先認證的 DoS 影響範圍窄一點，只針對開了 GSSAPIAuthentication yes 的機器；rekey 過程中伺服器更換 host key 觸發客戶端 UAF 的那支，則是 10.4 修掉的 memory safety 洞裡最紮實的一項。
三個容易漏看的 breaking change
第一個是 sshd -G 印出的 directive 名稱從全小寫改成混合大小寫，例如 pubkeyauthentication 變成 PubkeyAuthentication。任何用 grep 或 awk 剖析這份輸出的組態管理工具、監控腳本，都得先確認過。Puppet、Chef、Ansible 用來驗證 sshd 設定的 module 幾乎都會踩到。
第二個是 Linux 上的 seccomp sandbox 失敗行為改為 fatal。過去 seccomp 建不起來會回落到其他 sandbox 或直接繼續跑，10.4 把這個容忍度收掉了——除非在編譯時或 sshd_config 裡明確關閉，否則沙盒建不起來 sshd 就不會啟動。跑在很舊的 kernel 或客製化 syscall filter 的環境會被擋在門口。
第三個是傳輸層現在會直接踢掉在 post-authentication rekey 過程中送出非 KEX 訊息的對端。過去有些連線多工工具或不夠嚴謹的 SSH 函式庫會在這個窗口塞 SSH_MSG_CHANNEL_DATA，之前是被忽略，現在是斷線。開源函式庫如 golang.org/x/crypto/ssh、paramiko 的舊版本可能會踩到，先在測試環境跑過一輪比較保險。
該不該現在就升上去
現階段的實際建議很單純：安全修補該立刻拉，post-quantum 簽章可以先在少數幾臺實驗機開起來。SFTP 跟 SCP 的路徑竊改沒有 CVSS 9.x 的耀眼分數，可是攻擊條件低、後果直接——共用 SFTP jail 主機、CI 使用第三方 registry、跨組織備份都在暴露面上。相較之下複合簽章目前只是 draft、跟不支援的客戶端互通還會被強制 downgrade，把 Ed25519 全數換掉沒有實質好處，但拿一臺跳板機或 bastion 起頭跑一下，累積操作經驗、確認硬體 token（例如 YubiKey firmware 對 mldsa44 的支援進度）跟自動化流程能跟上，是務實的下一步。
NCSE Network 的臺灣是方電訊機房 VPS 全線支援自帶 kernel 跟自訂 OpenSSH build，Intel Gold CPU 加 NVMe SSD 的組合處理 ML-DSA 簽章驗證幾乎感覺不到額外開銷，適合拿來作為 post-quantum SSH 的實驗與遷移環境。有興趣把長效身分金鑰提前抗量子化、或想在正式導入前先評估握手成本的團隊，可以到 ncse.tw 了解相關方案。
