OpenSSH緊急修正：Alpine Linuxのログインバイパスの解説と実践例

パスワードが設定されていないサーバーアカウントを想像してみてください。そして、パスワードチェックがエラーメッセージを正解と誤認したために、攻撃者がそのアカウントにログインできてしまう状況を想像してみてください。それが今週のOpenSSH緊急リリースの中核にあるバグです。

本日は2026年11月6日ですが、Portable OpenSSH 10.6p2がプロジェクトからの緊急要請とともに昨日（11月5日）リリースされたばかりであるため、これは今まさに重要な問題です。パスワード認証を有効にしたmuslベースのLinuxサーバーを運用している場合、開発者は対策を講じるまでの間、直ちにパスワードログインを無効化するかSSHを無効化することを求めています。

多くのチームがその見出しを読んでパニックに陥るか、あるいは気に留めないかのどちらかでしょう。どちらも間違いです。大半のLinuxサーバーは影響を受けませんが、影響を受けるサーバーの中には、常に「鍵認証専用」と呼んでいたものが含まれている可能性があります。本ガイドでは、このバグを平易な言葉で説明し、サーバーの確認方法を正確に示し、発見から修正の検証までの一連の実例を順を追って解説します。

何が起きたのか、平易な言葉で

SSHは、管理者がリモートからサーバーにログインするために使用するツールです。OpenSSHはその中で最も広く使用されている実装です。

すべてのLinuxプログラムは、基本的な関数の共有コレクションであるCライブラリに依存しています。大半のLinuxシステムはglibcと呼ばれるライブラリを使用しています。Alpine Linuxはmuslと呼ばれるより小規模なライブラリを使用しており、これがコンテナや小規模なクラウドサーバーでAlpineがこれほど人気を集めている大きな理由です。

このバグは、これら2つのソフトウェアの接点に存在します。OpenSSHの開発者は根本的な原因はOpenSSHの外部にあると考えていますが、SSHサーバーがそれを悪用する経路を提供しており、同時にそれをブロックする現実的な場所であることも認識しています。そのため、10.6p2で回避策が追加されました。この脆弱性はWakefieldのÖzgün Kültekin氏によって発見されました。

エラーがログイン成功に変わる仕組み

悪用の詳細を省き、そのロジックを段階を追って説明します。

サーバーがPAM（Pluggable Authentication Modules：ログイン処理を行う一般的なシステム）を使用せずにパスワードをチェックする場合、単純な処理を実行します。訪問者が入力したパスワードをハッシュ化し、その結果をそのアカウント用に保存されている値と比較します。

ハッシュにはソルト（同一のパスワードでも異なる結果が生成されるように混ぜ合わせる小さなランダム値）が必要です。アカウントの保存値が短すぎてソルトを提供できない場合、OpenSSHは同一マシン上の別のアカウントからソルトを借用することができます。これには正当な理由があります。脆弱性CVE-2016-6210への対策として、2016年以降、攻撃者がどのユーザー名が存在するか推測するのを防ごうとしてきたためです。

ここで衝突が発生します。muslの crypt() 関数に、特定のハッシュ形式に対して長すぎるパスワードが渡されると、処理を拒否して単一の文字 * を返してエラーを示します。

しかし、 * は、多くのシステムにおいて、パスワードを持たせる意図のないアカウントのパスワードフィールドに格納されている値でもあります。

そのため、サーバーは2つの値を比較します：

• サーバーが計算した値： *、これは実際には「エラー」を意味します。
• サーバーが保存している値： *、これは実際には「使用可能なパスワードなし」を意味します。

これらは一致します。ログインが成功します。

名簿と照合して入場者をチェックする警備員を想像してみてください。スキャナーが故障して「ERROR」と表示されます。名簿上のあるエントリ（スタッフ向けメモとして追記されたもの）にも「ERROR」と書かれています。警備員は2つの同一の単語を見て、その人を通します。誰も嘘をついておらず、各コンポーネントはそれぞれの役目を果たしました。危険は、1つの値が2つの異なる意味を持っていたことから生じたのです。

研究者は、この相互作用の原因を2012年のmuslの変更と前述の2016年のOpenSSHの変更に遡ると特定しています。AIエージェントの支援を受けながら、ビルドとログインの組み合わせにわたる約17,600回のテストログインを通じてこれを発見したと報告しています。

影響を受けますか？ 4つの条件

Alpineのアドバイザリには4つの条件が挙げられており、そのすべてが重要です：

1. OpenSSHがPAMなしでパスワードをチェックしている。
2. PasswordAuthentication が有効になっている。
3. 対象アカウントのパスワードフィールドに次が含まれている： *.
4. 別のローカルアカウントが次で始まるパスワードハッシュを持っている： $5$ または $6$.

Alpineの標準 openssh-server パッケージはPAMを使用しません。 openssh-server-pam をインストールしても解決にはなりません。なぜなら、 UsePAM no が設定されていれば、依然として脆弱性に晒されるからです。

以下は明記された対象範囲外（影響を受けない環境）です：

• Linux以外のプラットフォーム。
• glibcを使用しているLinuxシステム。
• PAM経由でパスワードをチェックしているLinuxシステム。
• SSHサーバーが稼働していないコンテナ。
• パスワード認証が無効化されているシステム。
• アカウントが次でロックされている場合： ! （次ではなく）： *.

最後の項目こそが、「Alpineを使用している」ことが「脆弱性がある」ことと同じではない理由です。大半のAlpineコンテナではSSHサーバーが一切稼働していません。同様に、「OpenSSHがインストールされている」という情報だけではほとんど何もわかりません。Cライブラリ、パッケージ、稼働中の設定、そしてアカウントデータを把握する必要があります。

危険なケース：公式クラウドイメージ

Alpineは特に1つのシナリオを挙げています。バージョン3.18.11から3.24.3までの公式tiny-cloudイメージには、 alpine アカウントが含まれており、パスワードフィールドが * で、パスワードなしの doas 権限を持っています。 doas は小規模なツールであり、 sudoと同様に、ユーザーがrootとしてコマンドを実行できるようにするものです。

これらのイメージは、第4の条件が満たされていないため、初期状態では安全です。マシン上に条件に該当するパスワードハッシュが存在しないからです。

その後、誰かがコンソールアクセスなどの目的で通常のパスワードを持つユーザーを追加します。その日常的な1つの変更によって、条件のセットが揃ってしまう可能性があります。攻撃者は alpine として侵入し、rootになることができます。

デフォルトの PermitRootLogin prohibit-password 設定はここでは役に立ちません。これはrootへの直接のパスワードログインを阻止しますが、この経路では間接的にrootに到達してしまいます。

実践例：Acmeの踏み台サーバー（ジャンプホスト）

架空の企業を例に見てみましょう。Acmeは小規模なAlpineサーバー、 bastion.example.comを運用しており、スタッフは内部システムにアクセスするためにこれを経由して接続しています。誰もがこのサーバーは「鍵認証専用」だと言っています。新任のエンジニアであるRohitは、それを証明するよう依頼されました。

ステップ1：プラットフォームを確認する

Rohitはログインしてシステムを確認します：

cat /etc/alpine-release
ldd --version
apk info -e openssh-server openssh-server-pam

最初のコマンドはAlpineのバージョンを表示します。2番目はmuslを示します。3番目は2つのパッケージのうちどちらがインストールされているかを一覧表示します。Acmeのサーバーでは、 openssh-server のみが表示されるため、PAMは存在しません。

もし ldd --version が代わりにglibcを示している場合、あるいはマシンでSSHサーバーが稼働していない場合は、確認を終了して次のシステムに進むことができます。

ステップ2：sshdが実際に適用している設定を読み取る

これは多くのチームが見落としがちなステップです。設定ファイルを読んで勝手に判断しないでください。サーバー自身に有効な設定を問い合わせます：

sshd -T | grep -iE '^(passwordauthentication|usepam|permitrootlogin|authenticationmethods)'

Rohitには以下のように表示されます：

permitrootlogin prohibit-password
passwordauthentication yes
authenticationmethods any

ここに予想外の事実があります。パスワードログインが有効になっているのです。スタッフは常に鍵認証を使用していたため、誰も気づきませんでした。PAMなしのビルドでは usepam が一切出力されない場合があり、そのためこの出力には該当する行がありません。

設定は Match ルールによって接続ごとに変わることもあるため、特定のユーザーとアドレスに対する表示設定をテストします：

sshd -T -C user=deploy,host=bastion.example.com,addr=203.0.113.10 | grep -i '^passwordauthentication'

ステップ3：アカウントデータを確認する

rootとして実行すると、これら2つのコマンドはアカウント名のみを出力し、ハッシュを出力することは決してありません：

awk -F: '$2 == "*" {print "star: " $1}' /etc/shadow
awk -F: '$2 ~ /^\$[56]\$/ {print "hash: " $1}' /etc/shadow

Rohitの結果：

star: deploy
hash: backup-admin

したがって、 deploy（「鍵認証専用」のアカウント）のパスワードフィールドには * が設定されています。そして backup-admin（コンソールアクセスのために昨年作成されたアカウント）には、条件に該当するハッシュが存在します。4つの条件がすべて満たされました。このサーバーは脆弱性に晒されています。

ステップ4：まず侵入経路を遮断し、その後にパッチを適用する

Rohitは現在のセッションを開いたままにして、2つ目のターミナルから自身の鍵認証が機能することを確認します。ここでのミスは全員を締め出してしまう可能性があるため、開いたままのセッションが命綱となります。

次の設定を以下に追加します： /etc/ssh/sshd_config:

PasswordAuthentication no

1つの落とし穴として、OpenSSHはほとんどの設定において最初に読み取った値を使用します。ファイル内の上部近くに Include 行があるか、あるいは下の方に Match ブロックがある場合、新たに追加した行が有効にならない可能性があります。編集の直後に確認を行うのはそのためです：

sshd -t
sshd -T | grep -i '^passwordauthentication'

sshd -t によって設定のエラーをテストします。テストに合格したら、公開されたAlpineの修正を適用します。Alpineは3.21.10、3.22.8、3.23.8、3.24.4をリリースしており、OpenRCシステムでの修正手順は次のとおりです：

apk upgrade -U -a
rc-service sshd restart

再起動は必須です。パッケージをインストールしても、メモリ上で既に実行されているSSHサーバーは置き換えられません。

ステップ5：外部から検証する

次にRohitは、外部の第三者と同じように、別のマシンから自身のサーバーに対してテストを行います：

ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password [email protected]

期待される結果は、以下のような拒否メッセージです： Permission denied (publickey)。これはサーバーがパスワード認証を一切提供しなくなったことを意味します。その後、新しいターミナルで通常の鍵ベースのセッションを開き、スタッフが引き続きアクセスできることを確認します。

ステップ6：過去の不正アクセスの有無を確認する

パッチ適用は侵入経路を塞ぎますが、すでに誰かがそこを通ったかどうかについては何も教えてくれません。Alpineは、ログでまさに次のエントリを確認することを推奨しています：

grep 'Accepted password for' /var/log/messages

スタッフが鍵認証のみを使用しているサーバーにおいて、パスワードログインの成功は徹底的に追跡すべき兆候です。認証失敗の繰り返しを監視するモニタリングではこれを見完全に逃してしまう可能性があります。なぜなら、ここでは攻撃者の試行が成功として記録されるからです。

Rohitは該当するログを見つけませんでした。もし deployに対するログインが見つかっていた場合、作業はパッチ適用からインシデント対応へと変わっていたはずです。Alpineは、権限昇格、新規ユーザー、新規ファイル、およびauthorized_keysの変更を確認し、不正ログインを否定できない場合はホストが侵害されたものとして対処することを推奨しています。保存された認証情報やデプロイシークレットを含め、そのアカウントがアクセスできた可能性のあるすべての対象について見直しと差し替えが必要になります。

不審なログインがあった時点のアカウントの状態も確認してください。現在のアカウント状態は、後からの変更が反映されている可能性があるからです。

ステップ7：製品だけでなく製造元（大元）を修正する

Acmeは保存されたイメージからサーバーを構築しています。Rohitがステップ6で作業を止めていた場合、次回のサーバー再構築やオートスケーリングの発生時に古い設定がそのまま元に戻ってしまう可能性があります。彼らはテンプレートを更新し、そこで PasswordAuthentication no を設定し、そもそもなぜ backup-admin にパスワードが必要なのかを問い直します。

スキャナーの結果の読み方

今週はノイズの多いスキャンレポートが予想されます。2つの考え方を明確に区別してください。

アップストリームのバージョン文字列とディストリビューションのパッチ適用状況は異なる証拠です。ベンダーは主要なバージョン番号を変更せずに修正をバックポートすることがあるため、使用しているディストリビューションのパッケージ案内を参考にしてください。OpenSSHをご自身でコンパイルしている場合は、10.6p2のリリースノートを参照してください。

サーバーごとに4つの独立した事実を追跡してください：脆弱なパッケージの特定、代替パッケージのインストール、サービスの再起動、設定の検証です。チケットに記載される「パッチ適用済み」は、往々にして2番目の事実のみを意味していることがよくあります。

なぜ修正がこれほど迅速に提供されたのか

Damien Miller氏は、OpenSSHチームが回避策をリリースする前日にこの問題を認識したと述べています。同氏は、AIエージェントが数時間以内に脆弱性を独自に再発見する最近の事例を指摘し、情報公開の猶予期間（エンバーゴ）を長く設けることは攻撃者を利する可能性があると主張しました。

リリースノートでは、定期リリースまで変更を保留するのではなく、より頻繁に修正を提供する方針への移行についても説明されています。同時に、AIによって生成されたレポートの多くは現実的なセキュリティ上の影響を示しておらず、人間の分析が依然として重要であることも強調されています。

多くの人にとって、実際の影響はシンプルです。重大な修正が通常のメンテナンス期間外にリリースされる可能性があります。ベンダーのアナウンスを直接確認し、誰が緊急変更を行う権限を持つかを事前に決定しておいてください。

これらの点は影響範囲と適切な対応について説明したものです。これらは確認された攻撃キャンペーンの証拠ではありません。

真の教訓：同一ではない3つの表現

「SSH鍵を使用している」「パスワードが設定されていない」「パスワードで認証できない」という3つの表現は似ているように聞こえますが、それぞれ異なる事柄を表しています。1つ目は習慣です。2つ目はデータの一時的な状態です。3つ目のみが強制された統制（制御）であり、これは稼働中のサーバーをテストすることによってのみ確認できます。

結論

これは影響範囲は狭いものの深刻な危険を伴うバグです。ほとんどのLinuxシステムは対象外ですが、4つの条件すべてに合致するmuslベースのサーバーでは、パスワードを持たせる意図のなかったアカウントへのログインを許可してしまう可能性があります。アップデートし、再起動し、 PasswordAuthentication noを設定し、外部から検証し、ログを確認してテンプレートを修正してください。そして、組織において「鍵認証専用」が何を意味するのかを明確に定義し、テストを実施してください。

メリット

• 影響を受ける条件が特定されているため、チームは大部分のシステムを迅速に対象から除外できます。
• 修正済みのAlpineリリースとシンプルな一時的緩和策がすでに利用可能です。
• 確認には標準的なツールを使用し、サーバー1台あたり数分しかかかりません。
• ログイン状況とアカウントデータを見直すことは、この単一のバグへの対策を越えてセキュリティの向上につながります。

デメリット

• 「OpenSSHインストール済み」としか記載されていない資産リストでは、影響の有無を判断できません。
• パスワードを持つユーザーの追加など、日常的な変更によって安全だったマシンが脆弱性に晒される可能性があります。
• SSH設定の誤りにより、管理者が締め出される恐れがあります。
• パッチ適用を行っても、それ以前に行われた不正アクセスが判明したり取り消されたりすることはありません。

注意点

この記事は教育目的のものであり、執筆時点で入手可能な公開アドバイザリおよび報道に基づいています。Acme、Rohit、 deploy, backup-admin、ホスト名、およびIPアドレスは架空のプレースホルダーであるため、ご自身の値に置き換えてください。SSH設定を変更する際はアクティブなセッションを開いたままにしておき、テストが許可されているシステムのみをテストし、それらに依拠する前に最新のOpenSSHおよびAlpineのアドバイザリ、またはご利用のベンダーのガイダンスと照らし合わせて詳細を確認してください。

よくある質問

• OpenSSH 10.6p2とは何ですか？ — 2026年11月5日にリリースされたPortable OpenSSHの緊急リリースであり、特定のmuslベースのLinuxシステムに影響を与えるログインバイパスの回避策が含まれています。
• すべてのAlpine Linuxシステムが脆弱ですか？ — いいえ。システムが影響を受けるには、PAMを使用せずにパスワードを検証する稼働中のSSHサーバー、有効化されたパスワード認証、パスワードフィールドが * である対象アカウント、および $5$ または $6$ ハッシュを持つ別のローカルアカウントが必要です。
• Ubuntu、Debian、その他のglibcシステムは影響を受けますか？ — glibcを使用するLinuxシステムは対象外であり、非LinuxプラットフォームやPAM経由でパスワードを検証するLinuxシステムも同様に対象外です。
• Alpine Dockerコンテナにはリスクがありますか？ — 稼働中のSSHサーバーがないコンテナはこの攻撃経路の対象外であるため、問題はコンテナが実際にsshdを実行しているかどうかです。
• PermitRootLogin prohibit-passwordで保護されますか？ — rootへの直接のパスワードログインはブロックされますが、tiny-cloudの alpine アカウントのシナリオのように、攻撃者が別のアカウント経由で侵入して権限を昇格させるのを防ぐことはできません。
• パッケージを更新するだけで十分ですか？ — いいえ。再起動するまで古いサーバーがメモリ内で実行され続けるため、SSHサービスも再起動する必要があります。
• 本日中に更新できない場合はどうすればよいですか？ — PasswordAuthentication noを設定し、 sshd -Tで有効な設定を確認した上で、既存のセッションを開いたまま鍵によるアクセスをテストしてください。
• 誰かがすでにこれを悪用したかどうかを確認するにはどうすればよいですか？ — /var/log/messages 内で、パスワードを使用すべきではないアカウントの Accepted password for エントリを検索し、不正なログインの可能性を排除できない場合はホストが侵害されたものとして対処してください。

タグ

#OpenSSH #AlpineLinux #LinuxSecurity #SSH #AuthenticationBypass #Musl #DevSecOps #CloudSecurity #PatchManagement #IncidentResponse