OpenSSH＋musl で「パスワード禁止」のアカウントに長いパスワードが通る（*sshole）
Alpine など musl libc 上で PAM なしの OpenSSH を動かしていると、shadow に * だけが書いてある「ログイン不可」アカウントに、257〜1024 文字の任意のパスワードで入れる。OpenSSH 10.6p2 へ更新するか、パスワード認証を切る。
いつ使うか
- Alpine Linux・OpenWrt・Buildroot・Yocto、および musl ベースの Docker イメージで
openssh-serverを動かしているとき - 公開鍵専用の deploy ユーザーや、Alpine 公式の AWS／Azure イメージの初期ユーザー（
doasがパスワードなし）を置いているとき
何が起きるか
- musl の
crypt()は 256 バイトを超えるパスワードを拒否し、失敗時に"*"を返す。 - パスワード禁止アカウントの shadow 欄も
"*"なので、文字列比較が一致してしまう。 - OpenSSH は「存在しないユーザー」とのタイミング差を埋めるため、別アカウントのソルトでハッシュする処理があり、その結果が
*と比較される経路で上記が認証成功になる。 - 条件はおおむね次のすべて: musl 上の sshd、PAM 未使用（Alpine の既定など）、
PasswordAuthenticationが有効、*のアカウントと本物のパスワードを持つ別アカウントが両方あること。
対応
- まず OpenSSH を 10.6p2 以降へ更新する（Alpine なら
apk upgrade openssh）。 - すぐ更新できない場合はパスワード認証を止める。
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf rc-service sshd restart # 環境に合わせた再起動コマンドで - 侵害の有無は、パスワード欄が
*のアカウントへの「パスワード成功」ログを探す（調査用リポジトリ: github.com/oz9un/sshole ）。該当があれば鍵の入れ替えとセッション確認を行う。
追記（2026-11-10）：国内でも警告、侵入成功を観測
- JPCERT/CC が CyberNewsFlash を出し、悪用の試行、観測用環境での侵入成功（侵入後のコマンド実行や C2 エージェント設置まで）、PoC の公開を伝えた。国内でも Alpine Linux ベースの商用製品が使われていることを確認している。
- 対策は OpenSSH 10.6p2 への更新。ログで、本来パスワードログインできないアカウントへの
Accepted password for記録がないかを確認する。 - 出典: @MalwareBibleJP · 2026-11-09 、@MalwareBibleJP · 2026-11-09
注意
- Debian／Ubuntu／Fedora など glibc＋PAM の一般的な構成、Dropbear、OpenBSD は対象外。
- 「パスワードを無効にしたつもり」の cloud イメージや鍵専用ユーザーが、実は
*でこの穴に当たる。更新かPasswordAuthentication noのどちらかを必ず入れる。