很多搞網路資安的朋友頭髮可能又要掉好幾根了，近日爆出當你在 Alpine Linux 上用 SSH 連線，只要密碼輸入超過 256 個字元，就能以 root 權限成功登入系統。攻擊者不需要知道任何密碼，一次連線就能進入，不必重試，也不會被鎖。這個名為 *sshole 的漏洞（真幽默）由安全研究者 Özgün Kültekin 在 2026 年 11 月 5 日公開，他自行架設的說明網站 sshhole.com 直接用一句話概括：「是的，任何密碼。是的。是的，我知道。是的。」
OpenSSH 團隊在同日釋出 10.6p2 版本修補這項缺陷，Alpine Linux 也為旗下所有發行版推出更新套件。OpenSSH 專案成員 Damien Miller 對媒體表示，目前尚未接獲任何利用此漏洞的攻擊通報。漏洞的觸發條件相當嚴苛，根因落在 C 語言函式庫與 SSH 伺服器的交界處，牽涉一場延續將近十年的修補副作用。
漏洞觸及的是哪些系統
Alpine 官方安全公告列出的受影響條件，必須同時成立才會中標：
- musl libc 系統：Alpine Linux、OpenWrt、Buildroot、Yocto。這是 OpenSSH 編譯時未啟用 PAM 的典型環境
- PAM 關閉：Alpine 的
openssh-server套件預設不編譯 PAM。若改用openssh-server-pam並設定UsePAM yes，則不受影響 PasswordAuthentication yes：OpenSSH 的預設值，管理者通常不會去改- 至少一個帳號的密碼欄位是
*：代表該帳號沒有設定密碼。這在 Alpine 很常見，root從 3.16 版起在基礎映像中就是root:*；用adduser建立但沒給密碼的使用者、透過 musl-nscd 連入的目錄服務帳號同樣符合 - 至少一個本機帳號有
$5$或$6$的密碼雜湊：也就是真的有設定密碼的帳號
最後一項條件最關鍵。只要機器上有一個設了密碼的帳號，所有沒有密碼的帳號就會一併暴露，攻擊者只要知道其中一個帳號名稱就能登入。Alpine 官方測試的結果是，受影響版本涵蓋 3.16 到 3.24 以及 edge 開發分支所有版本。（此漏洞只發生在 Alpine Linux）
至於 root 帳號，OpenSSH 預設的 PermitRootLogin prohibit-password 擋住了直接登入，只有設定成 PermitRootLogin yes 才會直接暴露。但這道防護擋不住提權路徑。Alpine 官方 tiny-cloud 映像（qcow2、VHD、AMI 格式）從 3.18.11 到 3.24.3 都內建一個密碼欄位為 * 的 alpine 帳號，且擁有免密碼的 doas 權限。這些映像首次開機時是安全的，一旦管理員設定了主控台密碼、或 user-data 加入帶 hashed_passwd 的使用者，機器就會被打通，攻擊者登入 alpine 後再透過 doas 升級為 root。
為什麼十年都沒人發現
Kültekin 在自己的說明頁面列出幾個原因：全新安裝、沒有設定任何密碼的機器不會受影響；shadow 檔案裡是 * 的帳號需要先錯一次才會觸發；OpenSSH 在 OpenBSD 與 glibc 系統上測試，musl 這條路徑不在測試範圍；多數發行版走 PAM，而 PAM 對 * 欄位根本不會呼叫 crypt。
他也在頁面上整理了幾次擦身而過的紀錄。2013 年 7 月，一位 Debian 開發者曾要求 glibc 複製 musl 的星號行為；六年後 Debian 轉用 libxcrypt，該函式庫回傳 *0，距離關閉這個 bug 只差一個字元。2024 年 12 月底 musl 郵件討論列表討論 busybox 的 passwd 在 257 字元密碼上出錯，同樣的限制、同樣的星號，但沒有人把它和 sshd 連在一起。
最接近的一次發生在 2026 年 10 月 30 日，OpenSSH 一次安全審查剛好修正了 pick_salt() 的問題。Kültekin 寫道，那個 bug 就在該函式下方四行，四天後他才找到。
修補方式與版本選擇
OpenSSH 10.6p2 的修法是讓 sshd 在密碼欄位長度少於四個字元時拒絕比對。官方把這項改動稱為 workaround，並明確說明根因位於 sshd 之外。漏洞由 Wakefield 的 Özgün Kültekin 通報。
Alpine 為每個分支都製作了帶相同修補的套件：edge 分支 10.6_p2-r0、3.24 分支 10.3_p1-r2、3.23 分支 10.2_p1-r1、3.22 分支 10.0_p1-r11、3.21 分支 9.9_p2-r1，往下到 3.16 分支的 9.0_p1-r6。其中 3.21 已在 2026 年 11 月 1 日終止支援。
官方提醒了一個容易踩到的陷阱：只更新套件不會重新啟動執行中的 sshd，必須另外執行 rc-service sshd restart。無法立即更新的管理者，則可設定 PasswordAuthentication no 關閉密碼登入，Alpine 公告提供了建立 drop-in 設定檔與檢查 sshd -T 輸出的完整指令。
要確認是否遭到利用，公告建議檢查 /var/log/messages 中出現 Accepted password for 卻對應到無密碼帳號的紀錄，例如 alpine、root 或僅用金鑰的使用者。公告並直言，若無法排除有登入發生，就當作機器已被入侵處理。
AI 代理參與漏洞挖掘
Kültekin 描述自己的發現過程時提到，他建置了多種組合的 sshd，包含 glibc、musl、有無 PAM、有無 shadow 等變體，並丟出約 17,600 次刻意設計的登入測試，涵蓋異常雜湊值、損壞的帳號與超長密碼。他在說明頁面還補了一句：「抱歉我說了『我』，跑的是一大群 AI agent」。
OpenSSH 團隊對這次漏洞的態度同樣值得記錄。Miller 在發布說明中提到，近期收到大量由 AI 模型或 AI 協助完成的安全漏洞通報，團隊目前採取較頻繁的釋出節奏，把修補盡快送到使用者手上，而非累積到下一個預定版本。他的理由是，已經出現 AI 工具找出某個 bug 之後，另一位研究者獨立重現同一問題的情形，不向開源專案回報的攻擊者同樣有辦法找到。他也提到近期看過 AI agent 在幾小時內重複找出相同漏洞，因此長期的保密期對攻擊者反而更有利。
結語
如果您不是 Alpine Linux 使用者的話也不用太擔心，Linux 核心沒有問題，OpenSSH 也不是漏洞來源，觸發點是 musl 的 crypt() 在錯誤處理上的設計選擇，與 OpenSSH 為修補使用者名稱枚舉而做的副作用相互交疊。影響範圍限於 musl 生態圈，Debian、Ubuntu、Fedora 等 glibc 系統與所有走 PAM 驗證的環境都不受影響。
但把它輕描淡寫同樣不妥。觸發條件雖然嚴苛，卻涵蓋了 Alpine 這個容器與雲端映像使用極廣的發行版全數版本，而 tiny-cloud 映像內建的 alpine 帳號搭配免密碼 doas，讓攻擊者拿到的是 root 權限。一次連線即成功、無須重試、也不會觸發封鎖機制，這些特性讓它在滲透測試與自動化掃描中格外好用。
修補工作已經完成，OpenSSH 10.6p2 與 Alpine 各分支套件都已就緒，官方並未接到實際攻擊通報。對管理者而言，剩下的是一件不需要猶豫的例行工作：更新套件、重新啟動 sshd、確認 sshd -T 的輸出符合預期。
資料來源： *sshole · sshhole.com
