OpenSSH 緊急修補:長密碼可繞過 Alpine/musl 上的密碼驗證

原始來源: The Hacker News · 2026/11/05

OpenSSH 於 2026/11/05 釋出 10.6p2,修補在部分停用 PAM、採 musl C 函式庫的 Linux(含 Alpine 預設 openssh-server)上,攻擊者可對密碼欄位為「*」的帳號送出 257 至 1,024 位元組長密碼,造成密碼驗證被誤判成功。攻擊另需機上至少有一個具 $5$ 或 $6$ 雜湊的帳號,且 PasswordAuthentication 為 yes。OpenSSH 評為 critical;Alpine 已為 3.16 起各分支提供修補,升級後必須重啟 sshd。公告與報導均表示尚無已知利用;撰文時尚未分配 CVE 編號。

OpenSSH musl 長密碼驗證繞過示意圖

重點先看

在 Alpine 等 musl、且停用 PAM 的 OpenSSH 環境,長密碼可能讓「無密碼」帳號被登入。請立即更新並重啟 sshd;無法更新時先關閉密碼登入。

發生了什麼

依 The Hacker News、Alpine Linux 與 OpenSSH 於 2026/11/05 公布的資訊,部分以 musl 建置、且未透過 PAM 檢查密碼的 OpenSSH 伺服器,存在密碼驗證繞過問題。攻擊者若能連到 SSH 服務、知道目標帳號名稱,並送出長度介於 257 至 1,024 位元組的密碼,可能成功登入密碼欄位為「*」的帳號(常見於僅允許金鑰登入、或以 adduser 建立卻未設密碼的帳號)。 OpenSSH 將此問題評為 critical,並釋出 10.6p2。研究人員將技術細節整理於 sshhole.com。Alpine 預設 openssh-server 套件未啟用 PAM,且密碼登入預設為開啟,因此符合條件的主機風險較高。撰文時官方公告尚未分配 CVE 編號。

OpenSSH 在 musl 環境長密碼驗證繞過與修補步驟示意圖
影響條件與處置步驟 資料來源:Alpine、OpenSSH、The Hacker News、BleepingComputer(2026/11/05)

影響條件與不受影響範圍

Alpine 公告指出,須同時符合下列條件才受影響:執行未含 PAM 的 openssh-server,或 openssh-server-pam 且 UsePAM no;PasswordAuthentication 為 yes;存在密碼欄位為「*」的帳號;且至少另有一個帳號具 $5$ 或 $6$ 開頭的密碼雜湊。官方 tiny-cloud 映像中的 alpine 帳號若具備無密碼 doas,在機上出現 $6$ 雜湊後可能被用來取得 root。 不受影響的情況包括:容器內未執行 sshd、已設定 PasswordAuthentication no、使用 openssh-server-pam 且 UsePAM yes、密碼欄位為「!」的鎖定帳號,以及採 glibc 且透過 PAM 驗證的常見發行版(如 Debian、Ubuntu、Fedora 的一般組態)。OpenWrt 預設使用 Dropbear,研究人員指出 Dropbear 不受影響;僅在另行安裝 OpenSSH 伺服器時才需評估。

建議立即處置

營運 Alpine 或其他 musl 基底、且執行 OpenSSH 的單位,建議依序處理: 1. 立即更新 OpenSSH。Alpine 可執行 apk upgrade -U -a,確認已取得各分支修補版本,並以 rc-service sshd restart 重啟;只升級套件不會自動重啟正在執行的 sshd。 2. 若暫時無法更新,先確認金鑰登入可用並保留現有工作階段,再設定 PasswordAuthentication no、以 sshd -t 檢查組態後重啟 sshd。 3. 自建 OpenSSH 者請升級至 10.6p2。 4. 檢查 /var/log/messages 是否出現對 alpine、root 或其他「無密碼」帳號的 Accepted password 紀錄。 5. 無法排除曾被登入時,應視同可能失陷,檢查 doas 使用、新增帳號、檔案與 authorized_keys。 6. 限制 SSH 對公網暴露,並以網段隔離降低失陷後橫向擴散。

為什麼重要

許多雲端與容器節點採用 Alpine;一旦條件齊備,攻擊者不需知道任何真實密碼,就可能登入本應只能用金鑰進入的帳號。問題根源涉及 musl crypt() 對過長密碼回傳「*」,與儲存欄位「*」比對後被誤判成功;OpenSSH 以 10.6p2 在伺服器端避免此比對。 建議以 DevaEye MDR 託管防護監看異常 SSH 密碼登入與提權行為,並評估 Illumio 微分割限制失陷主機橫向移動。首要工作仍是更新並重啟 sshd,或先關閉密碼登入。

Cloudforce 可以協助哪些?

針對 OpenSSH 驗證繞過與主機可能失陷的風險,可依下列方案對應: 1. DevaEye MDR 託管防護:7×24 監看異常 SSH 登入、可疑提權與後續行為,協助研判是否曾遭未授權進入並進行應變。 2. Illumio:以微分割限制伺服器間不必要連線,降低單一 SSH 主機失陷後的橫向擴散範圍。

常見問題

有 CVE 編號嗎?

Alpine 與 The Hacker News 於 2026/11/05 撰文時均表示尚未分配 CVE。本篇因此不以未核實的編號表述。

Debian/Ubuntu 一般主機會中嗎?

OpenSSH 專案說明:非 Linux、採 glibc 的 Linux,以及透過 PAM 檢查密碼的系統不受影響。Debian、Ubuntu、Fedora 等常見組態通常不在影響範圍;仍應確認是否以非標準方式停用 PAM。

只升級套件就好了嗎?

不夠。Alpine 強調升級套件不會自動重啟正在執行的 sshd,必須重啟後修補才會生效。

有沒有已知攻擊?

OpenSSH、Alpine 與相關報導均表示尚無已知利用。

暫時無法更新怎麼辦?

確認金鑰登入可用後,將 PasswordAuthentication 設為 no 並重啟 sshd,可先關閉此攻擊路徑。