OpenSSH脆弱性の対応｜Alpineで認証回避・悪用確認

2026年11月5日、サーバーへの遠隔ログインに使われる「OpenSSH」の修正版10.6p2が公開されました。一部のLinuxで、パスワードを知らなくてもログインできてしまう問題（CVE-2026-123158）を直したものです。米国CISAは11月9日、この脆弱性を「悪用が確認された脆弱性」の一覧（KEV）に追加しました。

影響を受けるのは、Alpine Linuxのように、OpenSSHを特定の条件で組み立てているシステムです。Red Hat Enterprise LinuxやUbuntuは、各社が「影響なし」としています。この記事では、自社のサーバーが対象かどうかの見分け方、更新の手順、すぐに更新できないときの対策、ログの確かめ方を説明します。

どんな脆弱性？ なぜ危ないの？

sshdは、PAMを使わない設定のとき、パスワードを自分で確かめます。Alpine Linuxの発表によると、そのときに使う部品（muslの暗号化の機能）は、長すぎるパスワードを受け取ると「*」という文字を返します。ところが「*」は、パスワードを設定していないアカウントの印としても使われています。そのため、両方が「*」で一致したと判断され、ログインが通ってしまうのです。

Alpine Linuxは「1回の接続で、毎回成功する」と説明しています。OpenSSHの開発チームは、原因はOpenSSHの外にあるものの、sshdを通して悪用できるため、sshd側で防ぐ修正を入れたとしています。

自社のサーバーは対象？ 見分け方

Alpine Linuxの発表では、次の4つがすべてそろうと影響を受けます。

• PAMを使わないsshdである（Alpineの openssh-server パッケージ、または openssh-server-pam で UsePAM no の場合）
• パスワードでのログインが有効（PasswordAuthentication yes。初期設定は有効）
• パスワード欄が「*」のアカウントがある（Alpine 3.16ごろからのrootや、鍵だけでログインするユーザーなど）
• 同じマシンに、ふつうのパスワード（$5$ や $6$ で始まるもの）を持つアカウントが1つ以上ある

※Alpine Linux以外にも、muslを使いPAMなしでOpenSSHを組み立てた機器やシステムが対象になりえます。家庭用・業務用の機器に入っているOpenSSHの扱いは、メーカーの情報をご確認ください。

サーバーの中で、次のように確かめられます（管理者権限が必要です）。

cat /etc/os-release
sshd -T | grep -i -E 'usepam|passwordauthentication'
awk -F: '$2 == "*" {print $1}' /etc/shadow

1行目でOSの種類、2行目でPAMとパスワードログインの設定、3行目でパスワード欄が「*」のアカウントがわかります。

Alpine Linuxの修正版

Alpine Linuxが公開した、各版の修正済みパッケージ（openssh）です。この版かそれより新しければ修正済みです。

※サポートが終わった3.16〜3.20にもパッケージは出ていますが、ほかの問題は直らないため、新しい版への移行をおすすめします。OpenSSHを自分で組み立てている場合は、本家の修正版10.6p2以降を使います。

対応する5ステップ

1. Alpine Linuxのサーバーやコンテナを洗い出す

   仮想マシン、Dockerのコンテナ、クラウドのイメージを確認します。sshdを動かしているものが対象です。sshdを動かしていないコンテナは影響を受けません。

2. パッケージを更新する

   apk upgrade -U -a で更新し、上の表の版になったことを確かめます。コンテナは、新しいイメージを作り直して入れ替えます。

3. sshdを再起動する

   パッケージを更新しただけでは、動いているsshdは古いままです。rc-service sshd restart で再起動します。

4. パスワードでのログインを止める

   鍵でログインできることを確かめてから、PasswordAuthentication no にします。今回のような問題への備えになります。

5. ログを確かめる

   下の「形跡の調べ方」を見て、あやしいログインがないかを確認します。

すぐに更新できないときは

Alpine LinuxとOpenSSHの案内では、パスワードでのログインを止めることが回避策です。sshdの設定に次の1行を加えて、sshdを再起動します。

PasswordAuthentication no

あわせて、SSHに接続できる場所（IPアドレス）をファイアウォールで絞ることも、危険を減らす一般的な方法です。

攻撃を受けた形跡の調べ方

Alpine Linuxは、次の点を確かめるよう案内しています。

• sshdのログに、パスワードのないアカウントへの「Accepted password for」という記録がないか
• 管理者権限で動かすコマンド（doas）の使われ方に、覚えのないものがないか
• 覚えのないユーザー、ファイル、SSHの鍵（authorized_keys）が増えていないか

Alpine Linuxは、インターネットに公開していて、侵入がなかったと言い切れない場合は、侵入されたものとして扱うようすすめています。その場合は、マシンを作り直すことも検討してください。Linuxサーバーの点検の考え方は「Linuxカーネル脆弱性の対応」でも説明しています。

コンテナやクラウドで見落としやすい点

Alpine Linuxは軽いため、Dockerのコンテナや、クラウドの小さな仮想マシンでよく使われます。開発のときに一時的に入れたsshdが、そのまま本番で動いていることもあります。

• だれが作ったかわからない古いコンテナイメージが、本番で動いていないか
• コンテナの中でsshdを動かしていないか（ふつうは不要です）
• SSHのポート（22番など）がインターネットに開いていないか

担当者が辞めた、作った会社と連絡がとれないといった場合は「システム保守の引き継ぎ」もご覧ください。

放っておくと？ 対応すると？

Digi Dinosにおまかせください

Digi Dinos（デジダイノス）は、DX、セキュリティ、システムの運用・保守を支援する会社です。ISO 27001の認証を取得しており、サーバーやクラウドの運用、24時間365日の監視（NOC）にも対応しています。日本語ができるチームがご案内します。

• サーバーとコンテナの棚卸し：どのOSとソフトが、どの版で動いているかを整理します。
• 更新と設定の見直し：SSHの設定や、鍵でのログインへの切り替えを、止められないシステムでも手順を決めて進めます。
• 監視と運用の引き継ぎ：ほかの会社が管理していたサーバーの運用も引き継げます。

よくある質問