Linux 伺服器十年老漏洞曝光：密碼亂打一長串就能登入，修補已推出

OpenSSH 10.6p2 緊急修補 musl 系統上的密碼驗證繞過漏洞，沒設密碼的帳號會被超長密碼直接登入。三個各自合理的舊決定疊在一起，藏了十年才被找出來，OpenSSH 與 musl 對責任歸屬各執一詞。
（前情提要：漏洞末日來襲？Wiz 技術長：PHP2Shell 不是特例，下一個很快就來）
（背景補充：OpenAI 發表最強資安模型「GPT-6 Cyber」！挖出 Firefox 81 個高危漏洞，被列為最高 Critical 風險級）

本文目錄

從得知到發布修補，OpenSSH 僅用了約一天。漏洞出在 Alpine Linux 等採用 musl 的系統：一旦機器上有帳號沒設密碼，攻擊者送出 257 到 1,024 位元組的超長密碼就能登入，一次連線、每次成功。

OpenSSH 開發者 Damien Miller 在公告中寫道「我們昨天才得知這個問題」，11/5 就發布了 10.6p2（見發布說明）。發現者是 Wakefield 資安公司的 Özgün Kültekin，漏洞暱稱「*sshole」，編號 CVE-2026-123158。

一個星號怎麼變成萬能鑰匙

故事從 1980 年代的慣例開始：Unix 裡不該用密碼登入的帳號，密碼欄位放一個星號。星號不是雜湊（密碼運算後存下的結果），沒有任何密碼算得出它。這個慣例沿用至今。

多數 Linux 發行版把密碼驗證交給 PAM 模組；沒走 PAM 的 sshd 得自己驗：用 crypt()（把密碼轉成雜湊的函式）算一遍輸入的密碼，再和欄位比對。三個各自合理的決定，後來疊在一起。

2012 年 8 月，musl 為了不讓程式在 crypt() 失敗回傳空值時當機，改成失敗就回傳星號。二十天後，musl 加入 SHA-512，為防超長密碼拖慢伺服器，訂下 256 位元組上限，超過就失敗，也就是回傳星號。2016 年，為了堵住靠回應時間分辨帳號是否存在的 CVE-2016-6210，sshd 遇到沒有可用雜湊的帳號，改借別的帳號的鹽值（雜湊前加的隨機前綴）照算一遍。

疊起來就是：沒設密碼的帳號欄位是星號，短到不能當鹽值，sshd 借走另一個帳號的 $6$ 鹽值，把超過 256 位元組的密碼丟進 musl 的 crypt()。musl 回傳星號，和欄位上的星號一比對，相同，放行。機器上若沒有 $5$ 或 $6$ 雜湊可借鹽，這條路就不通。

誰會中招，現在要做什麼

四個條件同時成立才中：系統用 musl 且 sshd 沒走 PAM（Alpine 的 openssh-server 套件預設如此，改裝 openssh-server-pam 卻設 UsePAM no 也算）；允許密碼登入（預設就是）；有帳號的密碼欄位是星號，例如 Alpine 3.16 之後的 root（root:*）和沒設密碼的金鑰帳號；另有一個帳號設過 $5$ 或 $6$ 雜湊。不受影響的有 glibc 系統、走 PAM 驗證、關掉密碼登入、容器裡沒跑 sshd、用 cloud-init 設定的映像，以及 2019 年之後的 Dropbear。

Alpine 官方雲端映像要特別小心。3.18.11 到 3.24.3 的 tiny-cloud 映像內建 alpine 帳號，密碼欄位是星號，還有免密碼的 doas（讓帳號升為 root 的指令）。首次開機是安全的，但機器上一旦出現任何 $6$ 雜湊，例如管理員設了登入密碼，攻擊者就能先以 alpine 登入，再用 doas 變成 root。OpenSSH 預設的 PermitRootLogin prohibit-password 雖然擋得住直接登入 root，卻擋不住這條路。

如果你的伺服器跑 Alpine，先升級：

apk upgrade -U -a

升級套件不會重啟正在跑的 sshd，所以一定要再執行：

rc-service sshd restart

暫時無法升級的話，先關閉密碼登入，把 /etc/ssh/sshd_config 裡每一行 PasswordAuthentication（包括 Match 區塊內的）都改成：

PasswordAuthentication no

動手前先確認金鑰登入可用，並保持現有連線，直到新登入測試成功。Alpine 公告附有一次改完設定檔的指令。重啟 sshd 後，用下面這條確認實際生效的設定：

sshd -T | grep -i passwordauthentication

應回傳 passwordauthentication no。至於有沒有被登入過，檢查 /var/log/messages 有沒有 sshd 對沒設密碼的帳號（alpine、root、僅用金鑰的帳號）記錄「Accepted password」。無法排除的話，就當作機器已遭入侵。

兩個專案互指對方，風險有多高

OpenSSH 的發布說明寫明，根本原因在 sshd 之外，10.6p2 是權宜修補，做法是儲存欄位短於 4 個字元就不予放行。musl 作者 Rich Felker 在公告中的立場相反：這不是 musl 的錯，是呼叫端用錯。不過 Felker 補了一句，這個機制「已經想改很久」，下個版本週期很可能更動。

NVD 上的 CVSS 3.1 評分是 8.1（高風險，攻擊複雜度列為高）。美國網路安全暨基礎設施安全局（CISA）評估利用狀態為「已有概念驗證」，不是已遭積極利用。但公開當天，Kültekin 的 GitHub 已放上重現環境與 PoC，另外兩個第三方重現環境也上了 GitHub，Google 的開源掃描器 goonami-scanner 當天也加入偵測。