OpenSSH 漏洞 CVE-2026-123158｜Alpine 沒設密碼的帳號可被長密碼登入

OpenSSH 在 2026 年 11 月 5 日緊急發布 10.6p2，修補編號 CVE-2026-123158 的密碼驗證繞過漏洞。在 Alpine Linux 這類使用 musl libc、又沒有啟用 PAM 的 Linux 上，攻擊者輸入一段超過 256、最多 1024 字元的任意密碼，就可能登入沒有設定密碼的帳號，CVSS 評分 8.1。

OpenSSH 維護者在得知問題的隔天就公開修補，並呼籲受影響的系統立即關閉密碼登入。這篇會從漏洞影響的元件開始，把繞過的原理、受影響的判斷條件、Alpine 各版本的修補套件、暫時解法與入侵檢查一起整理。

OpenSSH 漏洞 CVE-2026-123158 是什麼

OpenSSH 是 OpenBSD 專案開發的 SSH 實作，Linux 與 macOS 的遠端登入幾乎都用它；其中負責接受連線的伺服器程式叫 sshd。這次的漏洞出在 sshd 的密碼驗證，系統條件是 C 函式庫為 musl libc、而且 sshd 沒有透過 PAM 驗證密碼的 Linux；帳號條件是 /etc/shadow 裡密碼欄位為 * 的帳號。* 代表帳號沒有可用的密碼，常見於 root 與只用金鑰登入的帳號，攻擊者對這類帳號輸入任意的超長密碼就可能登入。

musl 是輕量的 C 函式庫，Alpine Linux 用它取代 Debian、Ubuntu 使用的 glibc；PAM（Pluggable Authentication Modules）是 Linux 的可插拔驗證模組，有 PAM 時 sshd 不會自己比對密碼。Alpine 體積很小，常被用在 Docker 映像檔與小型虛擬機，預設的 openssh-server 套件就沒有 PAM，所以是這次主要的受影響對象。

項目	內容
編號	CVE-2026-123158
CVSS 3.1	8.1（高）
影響範圍	Linux＋musl＋無 PAM
修正版本	OpenSSH 10.6p2
公開日期	2026 年 11 月 5 日

CVE-2026-123158 的基本資料

依 OpenSSH 10.6p2 release notes ，這個漏洞由 Özgün Kültekin 回報，10.6p2 的安全修正只有這一項。OpenSSH 認為根本原因在 sshd 之外，但可以在 sshd 端擋下；依 Alpine 的公告，問題出在 musl 的 crypt() 計算失敗時會回傳 *。

漏洞怎麼繞過密碼驗證

沒有 PAM 時，sshd 會用 C 函式庫的 crypt() 把使用者輸入的密碼加上 salt 算成雜湊，再和 /etc/shadow 裡存的雜湊比對，兩者相同就允許登入。依 Alpine 的安全公告，問題出在三個行為剛好疊在一起：

帳號的密碼欄位是 *：* 太短，不含 salt，sshd 會改用系統上其他帳號的 salt 來計算。
musl 的 crypt() 遇到超長密碼會回傳 *：借來的是 $5$ 或 $6$ （SHA-256、SHA-512）的 salt，而密碼超過 256 位元組時，musl 不計算雜湊，而是回傳 * 表示失敗。
sshd 直接比對字串：回傳的 * 和帳號存的 * 一模一樣，sshd 就當成密碼正確。sshd 本來就限制密碼最長 1024 位元組，所以有效範圍是 257 到 1024 位元組，純英數密碼就是 257 到 1024 個字元。

CVE-2026-123158 繞過流程：攻擊者輸入超過 256 字元的超長密碼；帳號的密碼欄位是星號，sshd 改借其他帳號的 SHA-512 雜湊 salt；musl 的 crypt 遇到超長密碼回傳星號；sshd 比對星號等於星號，當成密碼正確而登入成功；10.6p2 改成儲存的雜湊少於 4 個字元時一律判定密碼錯誤 — 錯誤代碼剛好等於帳號存的值

依修補的 commit ，10.6p2 在 auth-passwd.c 加了一個條件：儲存的密碼雜湊至少要有 4 個字元，比對才會成立。* 只有 1 個字元，無論 crypt() 回傳什麼都會被判定為密碼錯誤。

哪些系統受影響

下面四個條件全部成立才會受影響：Linux 使用 musl libc，例如 Alpine；sshd 沒有使用 PAM，也就是裝的是 openssh-server，或 openssh-server-pam 搭配 UsePAM no；PasswordAuthentication 開著，這是 OpenSSH 的預設值；有密碼欄位是 * 的帳號，而且至少一個本機帳號有 $5$ 或 $6$ 的密碼雜湊。

sshd 是否受影響的判斷流程：Linux 而且用 musl libc；sshd 沒有使用 PAM，openssh-server-pam 要看 UsePAM；PasswordAuthentication 開著；有密碼是星號的帳號，也有 $5$ 或 $6$ 雜湊；任一項為否就不受影響，全部為是就要立即更新 openssh 並重新啟動 sshd — 四個條件都成立才受影響

Alpine 的公告列出幾種密碼欄位是 * 的帳號來源：

root：大約從 Alpine 3.16 起，基本映像檔的 root 就是 *。預設的 PermitRootLogin prohibit-password 會擋住 root 的密碼登入，改成 yes 才會直接受影響；但如果其他能登入的帳號可以用 doas 變成 root，這層保護就沒有用。
只用金鑰登入的帳號：用 adduser 建立時沒有設密碼，或用 usermod -p '*' 清掉密碼的帳號。
目錄服務的帳號：透過 musl-nscd 從 nslcd、winbind、sssd 等目錄服務取得的帳號，因為沒有 shadow 項目，也屬於這種情況。
tiny-cloud 映像檔的 alpine 帳號：官方 3.18.11 到 3.24.3 的 tiny-cloud 映像檔，內建密碼為 *、可免密碼使用 doas 的 alpine 帳號，只要系統上出現任何 $6$ 雜湊就能被利用。

不受影響的情況包括：不跑 sshd 的 Docker 容器、PasswordAuthentication no 的系統、openssh-server-pam 搭配 UsePAM yes、帳號被鎖定成 !、系統上沒有任何 $ 開頭的雜湊，以及由 cloud-init 寫入 PasswordAuthentication no 的雲端映像檔。依 OpenSSH 的公告，非 Linux 系統、使用 glibc 的 Linux，以及用 PAM 驗證密碼的 Linux 都沒有這個問題。

檢查主機是否符合條件

在 Alpine 上以 root 執行下面幾行，可以逐一對照四個條件：

# Alpine 版本
cat /etc/alpine-release
# 裝的是 openssh-server 還是 openssh-server-pam
apk info -e openssh-server openssh-server-pam
# sshd 實際生效的設定
sshd -T | grep -i -E '^(usepam|passwordauthentication) '
# 密碼欄位是 * 的帳號
awk -F: '$2 == "*" {print $1}' /etc/shadow
# 有 $5$、$6$ 雜湊的帳號數量
grep -c -E '^[^:]+:\$[56]\$' /etc/shadow

裝的是 openssh-server，或 openssh-server-pam 但 usepam 是 no；passwordauthentication 是 yes；列出了 * 帳號，而且最後一行的數字大於 0，四項都成立就受影響。其他使用 musl 又不用 PAM 的 Linux，同樣要對照這幾個條件。

更新與暫時解法

Alpine 替 edge 與 3.16 到 3.24 都推出了修補套件，包括 2026 年 11 月 1 日剛結束支援的 3.21，以及更早已停止例行更新的 3.16 到 3.20；對應的點版本是 3.21.10、3.22.8、3.23.8 與 3.24.4。Alpine 是把修補移植到各分支原有的 OpenSSH 版本，例如 3.24 仍是 10.3p1，判斷有沒有修補要看套件的 -rN 修訂號，不是 OpenSSH 的版本號。

Alpine 分支	修正後的 openssh
edge	10.6_p2-r0
3.24	10.3_p1-r2
3.23	10.2_p1-r1
3.22	10.0_p1-r11
3.21	9.9_p2-r1
3.20	9.7_p1-r6
3.19	9.6_p1-r3
3.18	9.3_p2-r4
3.17	9.1_p1-r7
3.16	9.0_p1-r6

各分支修正後的套件版本

以 root 執行 Alpine 公告的更新指令。-a 會升級系統上所有套件，並把版本對不上套件庫的套件換成套件庫裡的版本；只升級套件不會重新啟動執行中的 sshd，所以要再重新啟動，最後兩行確認套件版本與 sshd 狀態：

# 更新套件索引並升級所有套件
apk upgrade -U -a
# 重新啟動 sshd，讓新版生效
rc-service sshd restart
# 確認套件版本與 sshd 狀態
apk list -I openssh-server
rc-service sshd status

暫時關閉密碼登入

還不能更新的主機，先關閉密碼登入。動手前要確認自己的金鑰登入可以用，並保留一個已經登入的連線，設定錯誤時才不會被鎖在外面。以下指令來自 Alpine 公告，註解為補充：它會新增一個設定檔、同時把主設定檔改成關閉密碼登入，並把原本的主設定檔備份成 sshd_config.bak。

# 新增設定檔關閉密碼登入
mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
# 主設定檔也改成 no，並備份成 sshd_config.bak
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
# 設定檢查通過才重新啟動
sshd -t && rc-service sshd restart
# 應該輸出 passwordauthentication no
sshd -T | grep -i passwordauthentication

Alpine 3.19 起預設會讀取 /etc/ssh/sshd_config.d/ 底下的設定檔。sed 這一段只要執行一次，重複執行會用已修改的檔案蓋掉 sshd_config.bak。要還原時，刪除新增的設定檔，把 sshd_config.bak 複製回 sshd_config，再重新啟動 sshd。

Docker 容器

以 Alpine 為基礎、在容器裡跑 sshd 的映像檔，要用更新後的套件重建映像檔，再重新建立容器；只重新啟動舊容器不會換掉裡面的套件。重建時加上 docker build --pull --no-cache，避免沿用舊的基礎映像檔與已快取的 apk add 層。執行中的容器可以用 docker exec 容器名稱 apk list -I openssh-server 查看套件版本，沒有輸出代表容器沒有安裝 sshd。 Gitea rootless 版使用 Gitea 內建的 SSH 伺服器，不是 OpenSSH 的 sshd。

入侵跡象的檢查方法

符合受影響條件、而且 sshd 對外開放的主機，要檢查是否有人用密碼登入了沒有密碼的帳號。Alpine 預設把 sshd 的紀錄寫在 /var/log/messages，舊紀錄會輪替成 messages.0 等檔案，以 root 執行：

# 所有用密碼成功登入的紀錄，包含已輪替的舊檔
grep -a 'Accepted password for' /var/log/messages*
# 密碼欄位是 * 的帳號
awk -F: '$2 == "*" {print $1}' /etc/shadow

兩者有交集，例如 alpine、root 或只用金鑰的帳號出現在密碼登入紀錄裡，就代表漏洞可能已被利用；目錄服務的帳號不在 /etc/shadow，要另外對照。Alpine 的公告也建議檢查 doas 的使用紀錄、新建立的帳號與檔案，以及 authorized_keys 有沒有被加入陌生的金鑰；無法排除被登入時，應該把主機當成已被入侵處理。

為什麼漏洞隔天就公開

OpenSSH 維護者認為，漏洞經常在幾小時內就被 AI agent 重新發現，長時間保密主要讓攻擊者受益，所以得知問題的隔天就發布。Damien Miller 在發布公告中說明，他們在前一天才得知這個問題，近期多次看到漏洞被 AI agent 很快重新發現，有時只隔幾個小時，因此認為長時間的保密期是危險的做法。一般的資安漏洞則會先保密一段時間，讓各發行版準備好修補再一起公開。

這和 Linux 核心社群的做法一致：核心的安全漏洞通報規則要求，用 AI 協助找到的漏洞必須當成已公開的資訊處理。OpenSSH 的建議是，在能更新之前先關閉密碼登入。2026 年 10 月的其他基礎軟體漏洞，整理在 10 月資安事故整理。

常見問答

Ubuntu、Debian 或 RHEL 會受影響嗎？

不會。這些發行版使用 glibc，sshd 也透過 PAM 驗證密碼，OpenSSH 的公告寫明這兩種情況都沒有這個漏洞。

macOS 的遠端登入會受影響嗎？

不會。漏洞只存在於 Linux，非 Linux 系統都不受影響。

平常只用金鑰登入，還需要處理嗎？

在受影響的 Alpine 系統上需要。只要 PasswordAuthentication 沒有關閉，sshd 仍然接受密碼登入，只用金鑰的帳號密碼欄位通常正是 *；用金鑰登入的伺服器，建議更新後也保持 PasswordAuthentication no。

ssh -V 顯示 10.3p1，代表還沒修補嗎？

不一定。Alpine 把修補移植到各分支原有的版本，要用 apk list -I openssh-server 查看套件的修訂號，和上面的表格對照。

參考來源

CVE: CVE-2026-123158 (CVE 紀錄)
OpenSSH: Release Notes (OpenSSH 10.6p2 更新說明)
MARC: urgent security release: 10.6p2 (OpenSSH 緊急發布公告)
GitHub: openssh-portable avoid password authn bypass (修補的 commit)
Alpine Linux: Security advisory: openssh-server password authentication bypass (Alpine 安全公告)
The Linux Kernel documentation: Security bugs (核心安全漏洞通報規則)

Post Views: 14