Alpine LinuxのOpenSSH認証回避を修正 鍵専用アカウントの影響と再起動を確認

Alpine LinuxでSSHサーバーを動かしている場合は、CVE-2026-123158の修正パッケージを適用し、稼働中のsshdを再起動してください。認証条件がそろうと、攻撃者はアカウント名を知っているだけで、鍵専用として作った利用者にパスワード経由でログインできます。すぐに更新できない場合、AlpineはPasswordAuthenticationを無効にし、sshdを再起動する回避策を案内しています。切り替える前に、別接続で使える鍵とコンソールへの退避経路を確認してください。

Alpine Linuxの認証回避に関する告知とOpenSSH 10.6p2のリリースノートは2026年11月5日付です。Alpineの初期告知では番号が未割り当てと記されていましたが、CVE ProgramのCVE-2026-123158レコードでCVE-2026-123158として公開されています。CVEレコードの基本値はCVSS 3.1で8.1です。公開された攻撃実証の情報と、実環境で侵害が確認されたかどうかは分けて扱います。ここで参照した告知は、個々のサーバーが侵害されたことを報告するものではありません。

鍵専用でもサーバーがパスワードを受け付けると影響する

対象は、musl libcを使うLinuxで、OpenSSHのパスワード照合がPAMを経由しない構成です。Alpineの標準openssh-serverはPAMなしでビルドされています。openssh-server-pamを使っていてもUsePAM noで起動していれば対象になり得ます。一方、同じパッケージでUsePAM yesが有効な場合は、Alpineの告知では影響を受けません。パッケージ名だけで判断せず、実際のデーモン設定も調べてください。

加えて、接続元からSSHポートに到達でき、実効設定でPasswordAuthenticationが有効であること、攻撃対象のアカウントのパスワード欄がアスタリスクであること、別のローカルアカウントに$5$または$6$で始まるパスワードハッシュがあることが条件です。たとえば、管理用に鍵しか登録していないユーザーと、コンソール用にパスワードを設定した別ユーザーが一台に同居すると、後者の設定が前者の認証に影響します。鍵の秘密部分が盗まれていなくても成立する経路です。

PAMを通らない照合で使うmuslのcryptは、Alpineの説明では256バイトを超える入力に対し、失敗を示すアスタリスクを返します。sshdがその返り値と保存済みのアスタリスクを同じ値として扱うため、照合に失敗すべき入力が一致として扱われます。Alpineが示す入力の長さは257〜1,024バイトです。長い文字列を実際に本番サーバーへ送らなくても、パッケージ、設定、アカウント欄を確認すれば、どの経路の対応を優先するか判断できます。

パスワード欄のアスタリスクと感嘆符は区別します。Alpineは感嘆符でロックされたアカウントを対象外としています。またrootは、既定のPermitRootLogin prohibit-passwordが有効なら、今回の経路で直接ログインできません。ただし、別のユーザーがログインした後にdoasなどで管理権限へ上がれるなら、rootへの直接ログインを止めているだけでは被害範囲を限定できません。

実行中の環境と次回の起動元を分けて棚卸しする

まず、Webサーバー本体、踏み台、CI用の作業VM、運用ツール用のコンテナを見て、どこでsshdが実際に動いているかを確認します。アプリのベースイメージがAlpineでも、コンテナにsshdがなければ、そのコンテナがこのSSH経路で直接影響を受けるわけではありません。逆に、ホスト側に別のSSHサービスがある場合は、アプリのイメージを更新してもホスト側には反映されません。接続先のIPやポートを、どのプロセスが受けているかにひも付けます。

Alpineのtiny-cloudイメージは特に確認が必要です。公式告知では3.18.11〜3.24.3のイメージに、パスワード欄がアスタリスクで、パスワードなしのdoasが可能なalpineユーザーが含まれます。初回起動時点で条件を満たさなくても、コンソール用のパスワード設定やユーザーデータによるハッシュ追加で条件がそろうことがあります。起動時設定でパスワード認証が無効になる別の構成と混同せず、起動後の設定を見ます。

クラウド運用では、現在動くVMのパッケージ更新と、障害復旧やスケール時に使うイメージの切り替えを別の作業にします。Alpineは3.21.10、3.22.8、3.23.8、3.24.4以降から作ったイメージに修正済みパッケージが入ると案内しています。新しいイメージをテンプレートに登録しただけでは既存VMは更新されません。逆に既存VMだけを直しても、古い起動テンプレートから作り直した場合に問題が戻ります。起動元のイメージIDと稼働中の版を両方記録してください。

上流の版番号ではなくAlpineの修正版を照合する

上流の修正はOpenSSH 10.6p2ですが、Alpineの安定ブランチでは修正を既存版へ移植しています。Alpine Linuxの修正版リリース告知で配布された更新を適用する際は、OSのブランチとパッケージの改訂番号をセットで確認します。たとえばAlpine 3.24で10.3_p1-r2が動いている場合、10.6p2より数字が小さいことを理由に未修正と判断しないでください。

系列	修正済み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.21は11月1日に通常サポートを終えています。Alpineは今回、3.16までの旧系列にも個別の修正を公開しましたが、そのことは通常サポートの再開を意味しません。旧系列をすぐに置き換えられない場合は公式告知で系列別の改訂番号を確認し、今回の修正とサポート中の系列への移行を別々に進めます。古いブランチのまま修正版だけを拾う目的で、他ブランチのリポジトリを混ぜないようにします。

公式の更新例はapk upgrade -U -aです。運用上は、先に参照するリポジトリが意図した系列であることと、更新対象の範囲を確認します。次にインストール済みパッケージが該当系列の修正版になったことを確認します。独自のイメージから配布している場合は、ビルド時のログだけでなく、配備した実行環境でも確認してください。更新だけでは既に動いているsshdは置き換わらないので、再起動の実施と、新しい接続が通ることまで確認します。

回避策は有効設定と別セッションで確認する

更新までPasswordAuthentication noを使う場合は、設定を変更する前に現在のSSH接続を残し、鍵で別接続できることを確かめます。設定ファイルに一行足しただけで終わらせず、Includeで読み込むファイルと、ユーザーや接続元に応じて設定を変えるMatchも確認します。Alpineによると既定の設定でドロップインを読むのは3.19以降です。古い環境や独自設定で、作ったファイルが実際には読み込まれない可能性があります。

Alpine標準のOpenRC構成を想定した確認例です。権限やサービス管理方式は環境に合わせ、構文チェックで失敗した場合は再起動しません。

sshd -t && rc-service sshd restart
sshd -T | grep -i '^passwordauthentication '

sshd -Tの既定の出力だけでは、特定の接続に適用されるMatchの結果までは判断できません。条件付き設定がある場合は、実際に使うユーザー名と接続元などを指定して確認します。外部向けと踏み台経由の両方を運用しているなら、それぞれで鍵ログインが通り、パスワード認証が提示されないかを調べます。影響がないと判断するために、長い試験用パスワードを本番へ送る必要はありません。

手元のセッションが生きていることは、新規接続を受けるデーモンが意図どおりに起動した証拠にはなりません。接続先のポートに新しいセッションを開き、運用者が必要な管理作業へ進めることを確認してから、元の接続を閉じます。自動配備が後で設定を上書きする環境では、手元のファイルだけでなく構成管理側も直します。回避策を反映した後も、計画した更新と再起動を完了させます。

更新前にあり得たログインを切り分ける

Alpineは、パスワードのないはずのアカウントに対し、sshdがAccepted password forを記録していないか、標準構成では/var/log/messagesを確認するよう案内しています。ログを集約している環境なら、ローカルのファイルだけでなく集約先でも、対象ホストの露出期間を絞って同じ記録を探します。鍵によるログイン成功とパスワードによる成功を分け、当時のアカウント設定と突き合わせます。現在はパスワードがないユーザーでも、過去には設定されていた場合があるためです。

対象サーバーが公開されていた期間と、$5$や$6$のハッシュが存在するようになった時期が分かるなら、両方が重なった期間を優先します。ハッシュ自体は認証情報なので、棚卸し表には対象の有無と設定日など必要な情報だけを残し、内容をチケットへ貼りません。鍵専用アカウントでパスワード成功が見つかった場合は、該当する利用者のdoasの使用、新規ユーザー、変更されたauthorized_keys、想定外のファイルを調べます。

ログが保存されていない期間の侵害を、記録が見当たらないことだけで否定できません。Alpineは不正なログインを否定できない場合、侵害されたものとして扱うよう案内しています。業務上の対応としては、先に接続経路を制限して証跡を保全し、疑わしいユーザーが読めるアプリや配備用の資格情報を調べて、必要な失効・交換や再構築を判断します。更新は今後のログインを防ぐ措置で、既に追加された鍵や改変されたファイルを戻すものではありません。

運用の完了条件は、稼働中の全対象で修正と再起動を確認し、復旧や追加配備で古いイメージに戻らないことです。そこに過去ログをどこまで確認したかを添えると、修正済みかどうかと、調査を続ける必要があるかを別々に引き継げます。