OpenSSH 修補 SSHole：長密碼或繞過部分帳戶驗證

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-11-07

OpenSSH 開發團隊發布 10.6p2 緊急更新，處理被稱為 SSHole 的身分驗證繞過漏洞（CVE-2026-123158）。iThome 報道指出，攻擊者可透過 SSH 連線，在密碼欄輸入長度介乎 257 至 1,024 字元的任意字串，嘗試登入原本沒有設定密碼的帳戶；報道列出的 CVSS 評分為 8.1。

不過，這並不代表所有使用 SSH 的 Linux 主機都會受同一方式影響。iThome 指出，問題涉及 OpenSSH 與 musl C 程式庫之間的密碼驗證處理，通報漏洞的 Wakefield 亦認為，其成因與 OpenSSH、musl 及 Alpine Linux 專案採用的防護機制調整有關。因此，伺服器管理員不應只看 OpenSSH 版本便判定風險，也要核對系統是否採用 musl，以及帳戶的密碼設定和所用發行版的安全公告。

對自架 server 的實際含意

SSH 往往是 Linux server、NAS、開發環境及雲端主機最直接的管理入口。一旦受影響主機存在未設密碼而仍可經 SSH 嘗試登入的帳戶，原本看似不應通過的密碼登入流程可能成為暴露面。這類情況尤其提醒管理員：帳戶政策、SSH 設定與底層函式庫的組合，比單一套件名稱更影響實際風險。

基於 iThome 所述條件，可優先處理以下事項：

檢查運行中的 OpenSSH 版本，並按發行版提供的安全更新升級至已修補版本或其已回移修補的套件版本。
確認主機是否使用 musl；Alpine Linux 或其他採用 musl 的部署，應優先比對供應商安全公告。
審視可透過 SSH 登入的帳戶，特別是未設定密碼的帳戶，以及現行密碼驗證政策。
在完成更新前，收窄 SSH 的可達範圍，例如只容許受信任管理來源連線；同時檢視登入紀錄有否異常嘗試。

更新以外，先釐清觸發條件

這宗事件的重點不是把「長密碼」視為一般密碼安全建議的反面，而是特定長度輸入在特定驗證處理路徑可能造成意外結果。從營運角度看，停用不需要的密碼登入、限制管理介面來源，以及移除閒置帳戶，均可在補丁部署前降低 SSH 對外暴露帶來的風險；但它們不能取代安全更新。

iThome 的報道屬彙整資訊，未在文中列出各 Linux 發行版的實際受影響版本或修補時間表，也沒有提供已出現大規模在野利用的證據。較穩妥的做法，是由維護 OpenSSH 的發行版套件公告確認本身映像檔、容器及 NAS／server 系統的修補狀態。接下來值得留意的是，各採用 musl 的發行版如何界定受影響範圍，以及託管平台和自架環境能否快速完成更新。