OpenSSH 於 2026 年 11 月 5 日發布 10.6p2，處理一項可透過 SSH 觸發的密碼驗證繞過問題。受影響的是採用 musl libc、且密碼驗證未經 PAM 的特定 Linux 環境；OpenSSH 官方將此次防護更新列為 critical。企業若使用 Alpine Linux 或以 musl 建置的設備，應優先確認是否執行受影響的 SSH 服務。[1]
這項問題被研究者稱為 sshhole，漏洞資料庫已收錄為 CVE-2026-123158。部分早期公告仍記載「尚未分配 CVE」，屬公告時間差。真正需要注意的是實際驗證流程：並非所有 OpenSSH 主機、所有帳號都能以長密碼登入，也不能把「平常只使用金鑰」當成已關閉密碼驗證的證明。[2][3][4]
攻擊成立需要哪些條件
在未修補的環境中，攻擊者除了能連到 SSH 服務、知道目標帳號名稱，還需要同時符合下列條件：[3][4]
• 執行 OpenSSH sshd 的系統使用 musl libc，且驗證未經 PAM；包含未編入 PAM 的版本，或支援 PAM 卻設定 UsePAM no 的情況。
• 該連線實際適用的設定允許 PasswordAuthentication yes。
• 目標帳號的密碼欄位為單一星號 *，而且其他存取控制也允許該帳號登入。
• 系統另有本機帳號使用 $5$ 或 $6$ 密碼雜湊，提供可被選用的雜湊參數。
依 Alpine 公告，符合上述條件時，257 至 1,024 位元組的密碼可觸發繞過。這裡的單位是位元組，不宜直接寫成字元數；目標的 * 也不是空白密碼。[4] 若另以 AuthenticationMethods 強制多種驗證，攻擊者仍須滿足其他驗證要求，不能據此認定所有驗證因素都被繞過。[9]
OpenSSH 維護者明確指出，採用 glibc 的 Linux、非 Linux 系統，以及透過 PAM 執行密碼驗證的環境，不受此漏洞影響。因此，應依 sshd 實際使用的函式庫與設定盤點，不能只看到 Linux 或 OpenSSH 名稱就判定受影響。[5]
長密碼為何會變成驗證成功
未使用 PAM 時，sshd 會把輸入密碼交給 crypt() 計算，再與帳號儲存的密碼欄位比對。當欄位只有 *、不足以提供正常的雜湊參數時，程式會借用其他帳號的參數執行運算。這項處理與過去降低帳號枚舉時間差的設計有關。[3]
musl 的相關 SHA-crypt 實作對過長輸入設有限制；以 SHA-512 crypt 原始碼為例，密碼超過 256 位元組會失敗，對外回傳 * 作為錯誤值。當這個值恰好等於目標帳號儲存的 *，舊版驗證流程便可能把運算失敗誤判為密碼相符。[6][7]
從這個流程可知，問題出在錯誤值與帳號標記的比對，並不代表 SSH 加密或使用者私鑰遭到破解。OpenSSH 修補加入儲存雜湊的最小長度檢查，避免此類短標記被當成有效雜湊比對成功；這也不是要求使用者把自己的密碼改短。[7]
金鑰登入與最高權限的兩個關鍵差別
帳號沒有可用的密碼雜湊，與伺服器禁止 password 驗證方法，是不同控制。有效設定 PasswordAuthentication no 可以阻斷本漏洞，musl 維護者也將其列為無法立即更新時的處置方式。不能把這起事件描述為「即使已關閉密碼驗證仍可繞過」。[8]
同樣地，取得某個帳號的登入權限，不代表必然直接取得 root。預設 PermitRootLogin prohibit-password 會禁止 root 的密碼及鍵盤互動驗證，但不會替其他帳號移除既有的管理權限。[9]
Alpine 官方指出，部分舊版 tiny-cloud 映像的 alpine 帳號具有免密碼 doas 權限；當主機後來新增可觸發條件的密碼雜湊，攻擊者可能先登入該帳號，再取得 root。反之，沒有執行 sshd 的 Alpine 容器，不會因這條 SSH 攻擊路徑而受影響。[4]
更新之後還要確認服務與設定生效
企業應優先安裝所屬發行版或設備廠商提供的修補套件。上游 OpenSSH 10.6p2 已加入防護；Alpine 亦發布 3.21.10、3.22.8、3.23.8、3.24.4 等更新，並在穩定分支套件回補修正。因此，不能僅憑 SSH 顯示的上游版本小於 10.6p2，就判定仍未修補，應核對完整套件版本與廠商公告。[1][4][10]
Alpine 更新套件後，必須重新啟動 sshd；單純完成套件升級，不會替換既有運行中的服務程序。使用 OpenRC 的環境可依官方公告執行 rc-service sshd restart。[4]
若暫時無法更新，可先確認 SSH 金鑰登入正常，保留現有管理連線，再將 PasswordAuthentication 設為 no。完成設定檢查並重新啟動服務後，另開連線驗證管理存取仍正常。[8]
設定檢查應使用 sshd -t 驗證語法，以 sshd -T 查看解析後的有效設定。若有 Match 區塊，須搭配 -C 帶入實際帳號、來源位址等條件；服務使用自訂設定檔或啟動參數時，也應帶入相同條件。僅在設定檔找到一行 PasswordAuthentication no，並不足以證明所有連線都套用該值。[9][11]
檢查異常成功登入並降低後續風險
Alpine 建議檢查 /var/log/messages 中的 Accepted password for，特別注意本來沒有正常密碼的帳號，並檢視 doas 使用、新增帳號及 authorized_keys 變更。[4]
光盾資訊建議將成功登入事件與當時的帳號狀態、來源位址及管理作業交叉比對，不要只搜尋大量登入失敗。若發現未授權成功登入，應保全日誌、限制受影響主機的連線，並調查憑證、持久化設定與內網存取情形；只有更新套件，無法撤銷攻擊者可能已完成的操作。
這起事件也提醒企業，SSH 安全盤點應涵蓋執行中的服務、作業系統函式庫、驗證設定及帳號權限。光盾資訊建議在每次修補後驗證實際生效狀態，並將管理服務限制於必要來源，讓資產清單與設定基準反映真正可被存取的環境。
參考資料:
[1] OpenSSH 10.6p2 發布說明
[2] GitHub Advisory Database 所收錄的 CVE-2026-123158 紀錄
[3] 原始研究者說明 sshhole
[4] Alpine Linux 官方安全公告
[5] OpenSSH 維護者緊急發布通知
[6] musl SHA-512 crypt 原始碼
[7] OpenSSH 官方修補 commit 4353fdc
[8] musl 維護者安全公告
[9] OpenSSH sshd_config 官方手冊
[10] Alpine Linux 修補版本發布公告
[11] OpenSSH sshd 官方手冊
