觀點 · 資訊分享

OpenSSH 緊急發布 10.6p2：Alpine 上的 SSH 可被一個超長密碼直接登入，CVSS 8.1

OpenSSH 在 11 月 5 日發布 10.6p2，修補 CVE-2026-123158：用 musl libc、又沒開 PAM 的 Linux（最常見的就是 Alpine）上，攻擊者不用知道密碼，送一個超長密碼就能登入沒設密碼的帳號。Alpine 已替 3.16 以後的版本出修補套件。

一句話看懂：OpenSSH 緊急發布 10.6p2，修補 Alpine 這類 musl 系統上的漏洞：攻擊者不用知道密碼，送一個超長密碼就能登入「沒設密碼」的帳號。

OpenSSH 密碼驗證可被繞過資訊圖卡：Alpine 等 musl 系統上，超長密碼能登入沒設密碼的帳號

先用白話講：這個漏洞怎麼發生的？

想像公司門禁是這樣比對的：把你輸入的密碼丟進一台「加密機」，再把結果跟檔案裡存的密文比，一樣就開門。

有些員工帳號沒有密碼，檔案裡就只寫一個 *，意思是「這個人不能用密碼進來」。

問題出在加密機：遇到太長的輸入時，它不會報錯停下，而是吐出一個 * 代表「出錯了」。結果門禁一比對：加密結果是 *，檔案裡也是 *，一模一樣，門就開了。

這裡的加密機就是 C 函式庫裡的 crypt()，門禁就是 SSH 伺服器 sshd。

OpenSSH 在 11 月 5 日發布 10.6p2，修補一個密碼驗證繞過漏洞，編號 CVE-2026-123158（NVD 在同一天公開），CVSS 3.1 分數 8.1（高）。

影響範圍：用 musl libc、而且沒有啟用 PAM 的 Linux。最典型的就是 Alpine Linux，它預設的 openssh-server 套件就是不帶 PAM 編譯
觸發方式：密碼長度在 257～1024 位元組之間時，musl 的 crypt() 會回傳 *，剛好等於沒設密碼帳號存的內容
回報者：Wakefield 的 Özgün Kültekin
Alpine 回應：同日發布安全公告，替 3.16 到 3.24 與 edge 都出了修補套件，連已經停止支援的舊版也補

依 Alpine 公告整理：

條件	說明
用 Alpine 的 openssh-server	或用 openssh-server-pam 但設了 UsePAM no
密碼登入有開	PasswordAuthentication yes，這是 OpenSSH 預設值
有密碼欄位是 `*` 的帳號	例如只用金鑰登入的帳號、官方雲端映像檔裡的 alpine 帳號
機器上有人設過密碼	至少一個帳號有 $5$ 或 $6$ 開頭的密碼雜湊

不受影響的情況：容器裡沒跑 sshd、已經關掉密碼登入、用 PAM、帳號被鎖住（密碼欄位是 !），以及用 cloud-init 設定的雲端映像檔（它會寫入 PasswordAuthentication no）。

要特別注意：root 預設不能用密碼登入，但如果被登入的帳號能用 doas 免密碼變 root，整台機器一樣會被拿下。Alpine 公告點名，官方 tiny-cloud 映像檔裡的 alpine 帳號就是這種情況。

apk upgrade -U -a
rc-service sshd restart

sshd -T | grep -i passwordauthentication

上面這行應該要顯示 passwordauthentication no。

檢查有沒有被登入過：翻 /var/log/messages，找沒有密碼的帳號（alpine、root 或只用金鑰的帳號）出現「Accepted password」的紀錄；無法排除的話，Alpine 建議把機器當成已被入侵處理

修補 commit 在 auth-passwd.c 加了 MIN_PASSWORD_HASH_LEN 4：儲存的密碼欄位長度不到 4 個字元時，一律不算比對成功
OpenSSH 在 commit 訊息裡說，他們不認為根本原因在 OpenSSH 內，但 sshd 有能力擋下來
10.6p2 同時把 ssh-mldsa44-ed25519 後量子混合簽章加入允許的 CA 簽章演算法，並修正 ChannelTimeout 造成的短暫 CPU 空轉
OpenSSH 也在版本說明提到，最近收到大量由 AI 找到的安全回報，而且常有不同研究者各自找到同一個漏洞，因此暫時會更頻繁地發版，不再累積到下一個大版本

Alpine 在自架圈很常見：小、快、映像檔省空間，NAS 上的容器、便宜的 VPS 都很常用到它。好消息是，大部分網站容器根本沒跑 sshd，不受影響；真正要擔心的，是「為了方便管理而在 Alpine 主機上開 SSH、又沒關密碼登入」的機器。

我自己的原則很簡單：對外的 SSH 一律只用金鑰、關掉密碼登入，能放在 VPN 或內網後面就不直接對外。這次的漏洞剛好證明，就算帳號「沒有密碼」，只要密碼登入開著，就還有被繞過的機會。趁這次把手上的主機都跑一次 sshd -T 檢查，花不到幾分鐘。

我用 Ubuntu / Debian，會受影響嗎？

依 NVD 與 Alpine 公告，問題出在 musl libc 而且沒有用 PAM 的組合。Ubuntu、Debian 這類用 glibc、預設走 PAM 的發行版不在描述範圍內；但用 Alpine 當基底、容器裡又有跑 sshd 的映像檔，就要檢查。

我的 Docker 容器用 Alpine 映像檔，要緊張嗎？

Alpine 公告寫明，容器裡沒有跑 sshd 就不受影響。大部分網站容器只跑應用程式，不會開 SSH；如果你有在容器裡開 sshd 方便連線，就要升級或關掉密碼登入。

升級完就安全了嗎？

還要重啟 sshd。Alpine 特別提醒，升級套件不會替換正在執行的 sshd 程式，必須執行 rc-service sshd restart。之後可用 sshd -T 確認設定，並檢查 /var/log/messages 有沒有沒密碼的帳號出現「Accepted password」紀錄。

官方說這不是 OpenSSH 的錯？

OpenSSH 的修補說明寫，他們認為根本原因不在 sshd 本身，但漏洞可以透過 sshd 被利用，所以由 sshd 這端擋下：10.6p2 會拒絕長度不足 4 個字元的儲存密碼欄位。

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。