SSHole 波及特定 musl 部署：OpenSSH 管理員應即時核查
OpenSSH 已發布 10.6p2 緊急更新，修補 SSHole（CVE-2026-123158）身分驗證繞過漏洞。iThome 報道指出，問題並不涵蓋所有 OpenSSH 或所有 Linux server；受影響部署須同時符合使用 musl C 函式庫、OpenSSH 未啟用 PAM，以及 SSH 密碼驗證仍然開啟等條件。
在這個組合下，攻擊者以 SSH 連線時提交特定長度的任意密碼，有機會登入原本未設定密碼的帳號。報道稱，部分 Alpine Linux 雲端環境更可能牽涉 root 權限。因此，使用 Alpine Linux、OpenWrt、postmarketOS，或以這些系統為基礎的 Docker 映像檔的管理員，應優先檢查實際部署設定，而非只按作業系統名稱判斷風險。
問題為何出現？
iThome 引述通報者 Wakefield 指出，SSHole 是多項原本為改善安全或相容性而作出的改動交疊所致：musl 曾調整密碼雜湊錯誤回報及密碼長度限制；OpenSSH 其後修改部分帳號的密碼驗證流程，以減少時間差異洩漏資訊；Alpine Linux 又調整 root 帳號的密碼欄位設定，讓 SSH 金鑰登入可正常運作。
這宗事件的意義，在於單看任何一項改動都未必顯得異常，但在特定函式庫、認證架構與帳號設定下，卻形成驗證邊界的缺口。iThome 指出，受影響範圍可追溯至 2016 年的 OpenSSH 7.3p1；不過，這不等於所有近十年版本或所有 Linux 主機均可被利用，部署條件才是排查重點。
管理員應先做甚麼
建議把處置分成「確認條件、修補、查核痕跡」三步：
- 盤點對外提供 SSH 的主機及容器，確認是否採用 musl，並核對 OpenSSH 套件版本、PAM 啟用狀態及
PasswordAuthentication設定。 - 儘快按所用發行版的安全更新渠道安裝已修補的 OpenSSH 套件。iThome 報道稱，OpenSSH 已推出 10.6p2，而 Alpine Linux 亦已發布完成修補的套件。
- 若更新未能即時完成，可在 SSH server 設定中停用密碼登入，即設定
PasswordAuthentication no，然後重新啟動服務。這項緩解措施會影響仍依賴帳號密碼登入的用戶，實施前應確認管理團隊已有可用的 SSH 金鑰登入途徑，避免把自己鎖在系統外。 - 檢查 SSH 登入紀錄。Wakefield 的指引指出，若日誌出現密碼欄位為
*，同一帳號卻有Accepted password紀錄，應視為潛在 SSHole 利用跡象，繼而調查帳號活動、權限變更及主機是否已遭入侵。
對香港開發團隊與 IT 管理員而言，雲端 VM 未必是唯一要看的地方；輕量化容器基底、網絡設備及內部管理用映像檔同樣可能帶有相關組合。下一步值得觀察的是各發行版及映像檔維護者如何標示已修補版本，讓依賴基底映像檔的團隊可更快完成供應鏈盤點。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- iThome — OpenSSH發布緊急更新，修補可利用長密碼繞過身分驗證的資安漏洞SSHole — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
