この記事でわかること
- Alpine Linuxが公表した、OpenSSHのパスワード認証を回避される問題「*sshole」の中身と、影響を受ける条件
- ブランチごとの修正済みopensshと、更新後にsshdの再起動が欠かせない理由
- すぐに更新できないときの回避策と、侵入されていないかを確かめる方法
条件がそろうと、パスワードのないアカウントへ長いパスワードでログインされる
Alpine Linuxは2026年11月5日、同ディストリビューションのOpenSSHサーバー（sshd）にパスワード認証を回避される問題があるとして、セキュリティ勧告を出しました。PAM（Linuxでログイン時の認証処理を受け持つ仕組み）を使わず、パスワード認証が有効になっているなど、いくつかの条件が重なったサーバーが対象です。その場合、SSHのポートに接続できる攻撃者が、パスワードを知らないまま特定のアカウントへログインできます。勧告によると、必要なSSH接続は1回で、条件がそろっていれば毎回成功するとされています。
狙われるのは、パスワードが設定されていないアカウントです。鍵認証だけで使うユーザーなどは、パスワード欄に「*」が入っています。攻撃者はそうしたアカウント名を指定し、極端に長いパスワードを送ります。その長さは、Alpineの勧告によると257〜1,024バイト。同じマシンにSHA-256／SHA-512形式（$5$／$6$）のパスワードハッシュを持つアカウントが1つでもあれば、パスワードのないアカウントのうち、SSHでのログインが許可されているものが入り口になります。
原因は、軽量なCライブラリ「musl」のcrypt()関数の動きでした。PAMを使わないsshdは、入力されたパスワードをcrypt()でハッシュ化し、保存されている値と比べて認証します。パスワード欄が「*」のように短く、ハッシュ化に必要な情報（ソルト）を含まないアカウントでは、sshdは別のアカウントのハッシュからソルトを借ります。$5$や$6$のハッシュを持つアカウントが攻撃の条件に入るのは、このためです。muslのcrypt()は256バイトを超える入力に対し、エラーの印として「*」を返します。それがパスワードのないアカウントの「*」と一致してしまい、ログインが通っていました。
OpenSSHは同日に修正版の「OpenSSH 10.6p2」を公開し（リリースノート）、Alpineも各ブランチ向けに修正済みパッケージを配布しています。問題を見つけたのはWakefieldのÖzgün Kültekin氏で、同氏はこれを「*sshole」と名付けました。同氏の公開資料によると、2016年ごろのOpenSSHから続いていた問題です。Alpineの勧告を出した時点ではCVE番号が割り当てられていませんでしたが、その後CVE-2026-123158として登録されています。
影響を受けるのは、条件がすべてそろったsshdだけ
OpenSSHを使っていれば誰でも危ない、という問題ではありません。Alpineの勧告では、次の条件がすべて当てはまる場合に影響を受けるとしています。
- インストールされているopensshが、後述の修正済みバージョンより前である（openssh-serverとopenssh-server-pamのどちらでも共通）
- Alpine標準のopenssh-serverパッケージ（PAMなしでビルド）を使っている。またはopenssh-server-pamを「UsePAM no」で使っている
- PasswordAuthenticationが「yes」になっている（OpenSSHの初期値）
- パスワード欄が「*」のアカウントがある
- $5$または$6$形式のパスワードハッシュを持つローカルアカウントが1つ以上ある
4つ目の条件には、Alpine 3.16ごろから基本イメージで「*」になっているrootも含まれます。ただしrootへの直接のログインは、OpenSSHの初期設定「PermitRootLogin prohibit-password」でパスワードによるログインが禁止されているため、「PermitRootLogin yes」にしていなければ成り立ちません。注意したいのは別の経路です。ログインできた別のアカウントからdoas（一般ユーザーが管理者権限でコマンドを実行するためのツール）でrootになれる構成なら、最終的にroot権限を取られます。adduserでパスワードを付けずに作った鍵認証専用のユーザーや、musl-nscd経由でディレクトリサービスから来るユーザーも対象です。
対象のリリースは、サポート中の3.22〜3.24とedgeに加え、サポートが終わった3.16〜3.21です。3.21は2026年11月1日にサポートを終えたばかりですが、Alpineは3.16までさかのぼって修正済みパッケージを公開しています。
一方、次のケースは影響を受けません。
- コンテナ内でsshdを動かしていないDockerなどの利用
- PasswordAuthenticationを「no」にしている
- openssh-server-pamを「UsePAM yes」で使っている
- パスワード欄が「!」のロックされたアカウント
- $で始まるパスワードハッシュを持つアカウントが1つもない
- cloud-initで設定し、実際にパスワード認証が無効になっているクラウドイメージ（cloud-initは「PasswordAuthentication no」を書き込みます）
Alpine以外については、OpenSSHが対象を「muslを使い、PAMを無効にしたLinux」としています。glibcを使う一般的なLinuxディストリビューションや、PAMでパスワード認証をしているシステムは対象外です。普段使いのWindowsやMac、スマートフォンに直接関わる話ではなく、Alpineでサーバーや仮想マシンを動かしている人、muslベースの環境でsshdを外部に公開している人が確かめるべき問題です。
対処は更新とsshdの再起動、すぐできなければパスワード認証を止める
発見者は、自分の環境が当てはまるかを調べるスクリプトや再現用の環境をGitHubで公開しています。手口が知られた以上、条件に当てはまるサーバーは更新を後回しにできません。
対処の基本は、opensshを修正済みのバージョンへ更新し、sshdを再起動することです。Alpineが示している手順は、「apk upgrade -U -a」で更新したあと、「rc-service sshd restart」でsshdを再起動するもの。パッケージを更新しただけでは、動いているsshdは古いままです。Alpineも、更新後の再起動を必ず行うよう求めています。
ポイントリリースでは、Alpine 3.21.10、3.22.8、3.23.8、3.24.4に修正済みパッケージが入っています。ブランチごとの修正済みバージョンは次のとおりです。
| ブランチ | 修正済みの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 |
edge以外の修正版は、10.6p2へ上げずに修正だけを取り込んだパッケージです。OpenSSHのバージョン番号が10.6p2より古いかどうかだけで判断すると、修正済みのAlpineまで未対策に見えてしまいます。確かめるときは、自分のブランチの修正済みバージョンと比べてください。
すぐに更新できない場合は、パスワード認証を止めることでもこの問題はふさげます。作業の前に、鍵認証でログインできることを確かめてください。設定を誤ると自分もサーバーへ入れなくなるため、今のSSHセッションは最後まで閉じずに残しておきます。
設定は、/etc/ssh/sshd_configのPasswordAuthenticationを「no」にします。Matchブロックの中に「PasswordAuthentication yes」があると、その条件に合う接続だけパスワード認証が残るため、ブロック内の設定も書き換えが必要です。3.19以降は/etc/ssh/sshd_config.d/に置いた設定ファイルも読み込まれるので、そちらも確認します。具体的なコマンドはAlpineの勧告に載っています。
書き換えたら「sshd -t」を実行し、エラーが出ないことを確かめてからsshdを再起動します。再起動が成功したことも確認してください。続けて「sshd -T | grep -i passwordauthentication」を実行します。「passwordauthentication no」と表示されれば、Matchの条件に当てはまらない接続での既定値は無効です。Matchで接続条件ごとに設定を分けている場合は、この既定値だけでは判断できません。実際のMatchで使っている条件（ユーザー名、接続元のアドレス、接続先のアドレスやポートなど）を「sshd -T -C」に指定し、パスワード認証が残りうる接続ごとに結果を確かめます。たとえば「sshd -T -C user=ユーザー名,addr=接続元のIPアドレス,laddr=サーバー側のIPアドレス,lport=22」のように指定します（sshdのマニュアル、Matchの説明）。最後に、別の端末から新しく接続して鍵認証でログインできることを確かめてから、残していたセッションを閉じます。
クラウドイメージは要注意、侵入の痕跡も確かめておく
Alpineの勧告によると、3.18.11〜3.24.3の公式tiny-cloudイメージ（qcow2、VHD、AMI）は、パスワード欄が「*」のalpineユーザーを含み、このユーザーはパスワードなしでdoasを使えます。起動した直後は安全です。ただし、opensshが修正前でパスワード認証が有効なまま、SSHのポートに外部から接続できる状態で、管理者がコンソール用のパスワードを設定したり、ユーザーデータでハッシュ付きのユーザーを追加したりして$6$のハッシュが1つでもできると、攻撃が成り立ちます。攻撃者はalpineとしてログインし、doasでrootになれる状態です。
イメージに修正済みパッケージが入っているのは、3.21系なら3.21.10、3.22系なら3.22.8、3.23系なら3.23.8、3.24系なら3.24.4以降です。各系列でこれより前のイメージと、3.18〜3.20系のイメージから起動したインスタンスは、修正前のopensshを含んでいます。1台ずつopensshを更新するか、パスワード認証を無効にする必要があります。
条件に当てはまるサーバーをSSHで公開していたなら、侵入の痕跡も見ておきたいところ。Alpineは、/var/log/messagesに、パスワードを持たないアカウント（alpineやroot、鍵認証専用のユーザーなど）への「Accepted password for」というsshdの記録がないかを確認するよう勧めています。あわせて、doasの使用状況や、最近追加されたユーザー、ファイル、登録された公開鍵も見直します。ログインがなかったと言い切れない場合、Alpineはそのマシンを侵害されたものとして扱うよう求めています。
