OpenSSH 在 11 月 5 日發布 10.6p2，修了一個密碼登入繞過漏洞 CVE-2026-123158（發現者叫它 sshole，CVSS 8.1）。11 月 9 日，美國網路安全和基礎設施安全局（CISA）以已有在野利用證據為由把它列入已知被利用漏洞目錄（KEV）。它只影響使用 musl C 函式庫、且不走 PAM 的 Linux，典型的就是 Alpine。Ubuntu 的安全頁面把所有版本的 openssh 都標為「Not affected」，Debian 把它的緊急程度標為 unimportant，所以裝著 Ubuntu 或 Debian 的 VPS 本身不用為這個漏洞動手。要查的是 Alpine 系統，以及你在 Alpine 容器裡自己裝的 sshd。上一次 OpenSSH 的版本變化見我們 10 月的報導。
四個條件同時成立才會中招
- 執行的是 Alpine 的 openssh-server 套件（它編譯時不帶 PAM），或者用了 openssh-server-pam 但設定成
UsePAM no。 PasswordAuthentication是 yes。這是 OpenSSH 的預設值，沒改過就是開著的。- 機器上有密碼欄位是
*的帳號，也就是沒設密碼、只打算用金鑰登入的帳號。Alpine 從 3.16 前後起基礎映像裡的 root 就是root:*；官方 tiny-cloud 雲端映像裡的 alpine 使用者也是，而且它能免密碼 doas 到 root。root 自己受預設的PermitRootLogin prohibit-password保護，但只要有別的帳號能提權到 root，這層保護就不夠。 - 機器上至少還有一個帳號存著
$5$或$6$開頭的真實密碼雜湊。四條都滿足時，攻擊者只要知道帳號名稱，發一個 257 到 1024 位元組的超長密碼（NVD 的寫法是 256 到 1024 個字元）就能登入，一次連線就成功。原因是 musl 的 crypt() 在密碼超過 256 位元組時回傳*表示出錯，而這些帳號存的恰好也是*，sshd 一比較就當成密碼正確。
哪些情況不受影響
- 容器裡沒有執行 sshd 的，絕大多數 Docker 容器屬於這一類。
- 已經設了
PasswordAuthentication no的；用 cloud-init 設定的雲端映像會寫上這一條。用 openssh-server-pam 並且UsePAM yes的也不受影響。 - 發現者另外點名了 OpenWrt、Buildroot、Yocto 這幾類用 musl 的系統，它們只有裝了 OpenSSH 的 sshd 才相關，修復看各自的更新。
怎麼修
- 升級後重啟 sshd：
apk upgrade -U -a，再執行rc-service sshd restart。升級套件不會替你重啟正在執行的 sshd。Alpine 3.21.10、3.22.8、3.23.8、3.24.4 帶著修好的套件，各分支的套件版本是 3.24 的10.3_p1-r2、3.23 的10.2_p1-r1、3.22 的10.0_p1-r11、3.21 的9.9_p2-r1和 edge 的10.6_p2-r0，更老的分支一直回補到 3.16。 - 暫時升級不了，就關掉密碼登入：在 sshd 設定裡寫
PasswordAuthentication no並重啟 sshd，再用sshd -T | grep -i passwordauthentication確認輸出是 no。動手前先確認金鑰能登入，並保留目前的連線工作階段不要斷開。 - 自己寫 Dockerfile、在 Alpine 映像裡裝了 openssh-server 的，要拉新的基礎映像重新建置並重啟容器。只升級宿主機沒有用。
怎麼判斷有沒有被登入過
Alpine 的說法是看 /var/log/messages 裡 sshd 的 Accepted password for 記錄：如果登入成功的是一個根本沒設密碼的帳號（alpine、root 或只用金鑰的使用者），那就是被利用了；再查 doas 的使用記錄、新建的使用者和 authorized_keys，排除不了就按已被入侵處理，步驟見入侵排查與安全加固。據 BleepingComputer 11 月 9 日報導，GreyNoise 記錄到的第一次成功利用發生在 11 月 7 日 00:46 UTC，離修復發布大約 40 小時；攻擊者得手後會偵察系統和容器、查詢雲端平台的中繼資料端點、嘗試讀取密碼雜湊和 root 的 SSH 金鑰，並改寫 authorized_keys 留後門。容器的基本用法見Docker 入門；不管用哪個發行版，把 SSH 改成只用金鑰登入都是最省心的做法，見ufw 防火牆與 SSH 金鑰登入。