2026年11月5日、OpenSSHの修正バージョン10.6p2が公開されました。
対象は、musl libcを使い、PAMを使わないLinuxのsshdです。
glibcを使うRHEL系・Ubuntu・Debianは、対象外です。
ただ、Alpine Linuxは、musl libcを使っています。
OpenWrtなどの組込み向けのLinuxや、
Alpineベースのコンテナも同じです。
自分が管理している機器に対象が無いか、
一度確認しておく必要があります。
この記事では、20年以上Linuxサーバーの現場に携わってきた立場から、
問題の仕組みと確認の手順を解説します。
想定環境はAlpine Linuxで、RHEL系とUbuntuにも触れます。
内容は、2026年11月6日時点で一次情報と照合したものです。
この記事のポイント
・対象はmusl libcのsshd。glibcのRHEL系は対象外
・条件はPAMなし・パスワード認証あり・「*」の欄
・ldd と sshd -T で、対象かどうかを確認する
・Alpineは apk upgrade openssh-server で更新
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
OpenSSH 10.6p2で修正された「*sshole」とは
公式リリースノートには、次のように書かれています。「musl libcを使い、PAMを無効にしたLinuxに影響する、
重大なセキュリティ上の回避策を含む」
中身は、パスワード認証の迂回です。
OpenSSHの開発チームは、原因はsshdの外にあると考えています。
ただ、sshd経由で悪用でき、sshd側で避けられるので、
対策したとしています。
報告したのは、Wakefieldの Özgün Kültekin 氏です。
発見者の公開ページでは、この問題を「*sshole」と呼んでいます。
発見者は、libcの種類（glibc・musl）やPAMの有無を変えて、
sshdを何通りも作りました。
そこへ、およそ17,600回のログインを試しています。
結果が食い違ったのは、「musl libcでPAMなし」の組み合わせだけです。
通してはいけないログインを通した、と書かれています。
2026年11月6日時点で、リリースノートにも、
発見者のページにも、CVE番号はありません。
確認は、パッケージのバージョンで行ってください。
なぜパスワード欄が「*」のアカウントに、ログインできてしまうのか
/etc/shadow のパスワード欄が「*」なら、パスワードではログインできない、と考える方は多いと思います。
これは正しいです。
でも、それだけでは足りない場面がありました。
「*」はハッシュ値ではないので、どんなパスワードを計算しても、
本来は一致しません。
発見者の説明では、次の3つの変更が重なって、
この前提が崩れていました。
| 時期 | 変更 | 起きたこと |
|---|---|---|
| 2012年8月9日 | musl libcのcrypt() | 計算に失敗したとき、NULLではなく「*」を返すようになった |
| 2012年8月29日 | musl libcのSHA-512方式 | 256バイトを超えるパスワードは計算に失敗する |
| 2016年 | OpenSSHのCVE-2016-6210への対策 | 使えるハッシュが無いアカウントでも、別のアカウントのソルトで計算するようになった |
CVE-2016-6210は、応答時間の差から、
存在するユーザー名を推測できる問題でした。
この3つがそろうと、次の順番で判定が通ります。
・パスワード欄が「*」のアカウントに、256バイトを超えるパスワードが送られる
・sshdが、別のアカウントのソルトでcrypt()を呼ぶ
・muslのcrypt()は計算に失敗し、「*」を返す
・返ってきた「*」と、パスワード欄の「*」が一致する
発見者の公開ページでは、
257～1,024文字のパスワードが通ると書かれています。
発見者は、glibcの環境では同じことが起きないとしています。
PAMを使う構成も、「*」の欄でcrypt()を呼ばないので、対象外です。
OpenSSHの修正のコミットでは、パスワード欄が4文字未満なら、
一致しても認証を通しません。
自分のサーバーは対象か｜5つの条件を順番に確認する
発見者は、対象になる条件を5つ挙げています。5つがそろったときに、「*」のアカウントが長いパスワードを受け付けます。
| 条件 | 補足 |
|---|---|
| sshdがmusl libcで動いている | Alpine・OpenWrt・Buildroot・Yoctoなど |
| PAMを使っていない | Alpineのopenssh-serverは、既定でPAMを使わない |
| パスワードでのログインが有効 | OpenSSHの既定では有効 |
| パスワード欄が「*」だけのアカウントがある | 鍵認証だけのユーザー、LDAPのユーザー、Alpineのroot |
| 本物のパスワードを持つ別のアカウントがある | そのアカウントのソルトが計算に使われる |
発見者は、Alpineの公式のAWS・Azureイメージにも触れています。
既定のalpineユーザーが、この条件に当たると書かれています。
このユーザーはパスワードなしでdoasを使えるので、
rootまで届くとしています。
なお、発見者は、Alpine 3.16でrootの欄が「*」に変わったとしています。
aportsでは、minirootfs（ミニルートファイルシステム）を作るスクリプトが、
rootの欄を「*」にしています。
ただ、OpenSSHの既定（PermitRootLogin prohibit-password）では、
rootはパスワードでログインできません。
sshd -T の permitrootlogin で確認できます。
1. sshdが使っているlibcを確認する
# OSの種類とバージョンを確認する cat /etc/os-release # sshdがつながっているlibcを確認する ldd /usr/sbin/sshd
# Alpine（musl libc）の例（libcの行だけを抜粋） /lib/ld-musl-x86_64.so.1 (0x7f3c2a1b4000) libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f3c2a1b4000) # RHEL系（glibc）の例（libcの行だけを抜粋） libc.so.6 => /lib64/libc.so.6 (0x00007f8e6c400000)
libc.so.6 が表示されれば、glibcなので対象外です。
2. sshdのPAMとパスワード認証の設定を確認する
sshdが実際に使っている設定は、sshd -T で表示できます。root権限で実行してください。
# PAMとパスワード認証の設定を確認する sshd -T | grep -iE '^(usepam|passwordauthentication) '
大文字が混ざって表示されます。
出力例（OpenSSH 10.3以前。環境により異なります）は、次のとおりです。
passwordauthentication yes
usepam（10.4以降は UsePAM）の行が表示されないときは、
PAMに対応せずに作られたsshdです。
OpenSSHのソースでは、PAM対応で作ったときだけ、
usepam の行を出力しています。
usepam no と表示された場合も、PAMを使っていません。
sshd -T の使い方は、
sshd -Tで原因を特定する記事で解説しています。
3. パスワード欄が「*」のアカウントを確認する
/etc/shadow の2つ目の欄を確認します。これもroot権限で実行してください。
# パスワード欄が「*」だけのアカウントを表示する awk -F: '$2 == "*" {print $1}' /etc/shadow # 本物のパスワード（$で始まるハッシュ）を持つアカウントを表示する awk -F: '$2 ~ /^\$/ {print $1}' /etc/shadow
1と2の条件にも当たれば、対象です。
手元に潜むmusl libcの環境を洗い出す
サーバーがRHEL系だけでも、musl libcの環境はほかにあることがあります。
洗い出すのは、musl libcの上でsshdが動いているものです。
1. Alpineベースのコンテナを確認する
コンテナのOSは、中の /etc/os-release で確認できます。# 動いているコンテナを一覧にする（Dockerなら podman を docker に置き換える） podman ps # コンテナのOSを確認する podman exec コンテナ名 cat /etc/os-release # コンテナの中でsshdが動いているかを確認する podman exec コンテナ名 ps
今回の問題の入口はありません。
sshdを動かしているコンテナは、
前の章の1～3を、中で確認してください。
2. ルーターや組込み機器のSSHサーバーを確認する
OpenWrtなどの機器も、musl libcを使っていることがあります。ただ、発見者は、dropbearというSSHサーバーは対象外としています。
# 機器のSSHサーバーの名前とバージョンを、管理用のPCから確認する ssh-keyscan 機器のIPアドレス 2>&1 | grep '^#'
# 192.168.1.1:22 SSH-2.0-OpenSSH_10.3
表示からは、libcの種類までは分かりません。
機器のファームウェアの更新は、メーカーや配布元の案内を確認してみてください。
更新とsshd再起動の段取り
Alpineは11月5日に、3.16～3.24とedgeへ修正を入れました。v3.21以降の修正済みバージョンは、次のとおりです。
v3.16～v3.20は、参考のAlpine Linux packagesで確認してください。
| ブランチ | 修正済みのバージョン |
|---|---|
| edge | 10.6_p2-r0 |
| v3.24 | 10.3_p1-r2 |
| v3.23 | 10.2_p1-r1 |
| v3.22 | 10.0_p1-r11 |
| v3.21 | 9.9_p2-r1 |
安定版のブランチは、10.6p2に上げずに、修正だけを取り込んでいます。
OpenSSHのバージョン番号ではなく、
パッケージのバージョンで確認してください。
1. パッケージを更新する
# 更新前のバージョンを確認する apk policy openssh-server # パッケージの一覧を更新して、OpenSSHをアップデートする apk update apk upgrade openssh-server # 更新後のバージョンを確認する apk policy openssh-server
発見者のページの apk upgrade openssh の openssh は、
openssh-server などをまとめるパッケージです。
apk upgrade は、指定したパッケージと必要な依存パッケージを更新するので、
sshd本体の openssh-server を指定します。
コンテナの場合は、動いているコンテナの中で更新しても、
作り直すと元に戻ります。
イメージを作り直してから、コンテナを入れ替えてください。
2. 設定を確認してから、sshdを再起動する
パッケージを更新したら、sshdを再起動します。再起動の前に、設定ファイルに誤りが無いかを確認します。
# 設定ファイルの文法を確認する（何も表示されなければ問題なし） sshd -t # sshdを再起動する（AlpineのOpenRC） rc-service sshd restart
別の端末から新しく接続できることを確認してから、
元のセッションを閉じます。
3. すぐに更新できない場合は、パスワード認証を止める
発見者は、更新できない場合の回避策も挙げています。パスワードでのログインを止める方法です。
# パスワードでのログインを止める設定を追加する echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/00-no-passwords.conf # 文法を確認してから、sshdを再起動する sshd -t rc-service sshd restart # 設定が反映されたことを確認する sshd -T | grep -i '^passwordauthentication '
yes のままなら、sshd_config に
sshd_config.d を読む Include の行があるかを確認してください。
Alpineの3.18以前の既定の設定には、この行がありません。
その場合は、sshd_config 本体で PasswordAuthentication no にします。
注意点が1つあります。
パスワードだけでログインしているユーザーは、ログインできなくなります。
先に、鍵認証でログインできることを確認してください。
鍵の作り方は、
ssh-keygenで公開鍵認証を設定する記事で解説しています。
鍵認証だけで運用できるなら、この設定は更新した後も残しておく方が安全です。
sshd_configのほかの設定は、
sshd_configの設定ガイドにまとめています。
「*」のアカウントへのログインが無いかを確認する（見つかった場合の対処）
すでにログインされていないかも確認します。パスワードでのログインに成功すると、sshdは次の行をログに残します。
「Accepted password for ユーザー名」
# パスワードでのログイン成功を表示する（ログの場所は環境に合わせて変える） grep 'Accepted password for' /var/log/messages
/var/log/messages が無いときは、
syslogの設定で出力先を確認してみてください。
表示された行のユーザー名が、
3の手順で表示した「*」のアカウントなら、侵入を疑います。
その場合は、機器をネットワークから切り離し、
ほかに変更されたファイルやアカウントが無いかを調べてください。
ログに無くても、侵入されていないとは言い切れません。
古いログは、保存期間を過ぎると消えます。
更新は、ログの確認とは別に必ず行ってください。
まとめ｜対象かどうかを確認してから、更新する
今回の問題は、glibcのRHEL系・Ubuntu・Debianでは起きません。| 確認すること | コマンド |
|---|---|
| sshdが使っているlibc | ldd /usr/sbin/sshd |
| PAMとパスワード認証の設定 | sshd -T | grep -iE '^(usepam|passwordauthentication) ' |
| パスワード欄が「*」のアカウント | awk -F: '$2 == "*" {print $1}' /etc/shadow |
| openssh-serverのバージョン | apk policy openssh-server |
まず対象かどうかを確認し、
対象なら更新して、sshdを再起動してください。
参考（一次情報）
・OpenSSH Release Notes（OpenSSH 10.6p2、2026年11月5日）
・発見者の公開ページ「*sshole」
・OpenSSHの修正コミット「avoid password authn bypass」
・Alpine Linux packages（openssh-server）
・NVD CVE-2016-6210
自分の管理する機器のsshdが、どのlibcで動いているか答えられますか？
sshdの設定も更新の段取りも、実機で手を動かして初めて現場で使える知識になります。
ネットの切れ端の情報をコピペするだけでなく、現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、サーバーの守り方を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
＜PR＞手元に置いて学びを深める1冊
Linuxサーバーセキュリティ徹底入門 オープンソースによるサーバー防衛の基本
まずは上の無料メルマガで学ぶのが第一歩です。加えて手元に置くなら、本書がサーバー防御の基本を学ぶ土台になります。2013年刊なので、コマンドは今のOSのマニュアルと照らして読んでください。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：OpenAIのLinuxカーネル脆弱性948件の読み方｜管理者が確かめるアカウントと更新
- この記事の属するカテゴリ：Linux情報・技術・セキュリティへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます