2026年11月5日、OpenSSHの開発チームは、SSHサーバーのパスワード認証を回避される問題に対処した「Portable OpenSSH 10.6p2」を公開しました。影響を受けるのは、musl libcを使用し、PAMを利用しない構成のLinuxシステムです。Alpine Linuxなどが該当します。
一定の条件が揃ったサーバーでは、攻撃者が本来パスワードでログインできないアカウントに、パスワードを知らなくてもSSHでログインできるおそれがあります。OpenSSHのリリースノートは、この問題への対処を緊急性の高いセキュリティ修正と位置付けています。
対象となるサーバーの管理者は、ディストリビューションが提供する修正済みパッケージを適用し、SSHサーバーを再起動してください。今すぐ更新できない場合は、パスワード認証を無効にすることで問題を回避できます。
影響を受ける環境
SSHは、遠隔のコンピューターに安全にログインしたり、ファイルを転送したりするための仕組みです。今回の問題は、SSH接続を受け付けるサーバー側のプログラム「sshd」で表面化します。
Alpine Linuxのセキュリティ情報によると、Alpine Linuxでは、次の条件がすべて揃うと影響を受けます。
-
- PAMを使用しない
openssh-server、またはUsePAM noに設定されたopenssh-server-pamを使用している。 - SSHのパスワード認証が有効になっている。
- パスワード欄が
*であるアカウントが存在する。 - 別のローカルアカウントに、
$5$または$6$で始まるパスワードハッシュが設定されている。
- PAMを使用しない
PAMは、ログイン時の認証方法を扱うための仕組みです。また、musl libcはLinux向けのC標準ライブラリの一つで、Alpine Linuxなどで使用されています。
パスワード欄が*のアカウントには、パスワードを設定せず、SSH公開鍵でログインする利用者などが含まれます。条件を満たす環境で攻撃者がSSHポートに到達し、対象のアカウント名を知っている場合、本来受け付けないはずのパスワードでログインされるおそれがあります。
一方、Alpine Linuxは、PasswordAuthentication noでパスワード認証を無効にした環境や、openssh-server-pamでUsePAM yesを使用している環境は、この問題の影響を受けないと説明しています。コンテナ内でsshdを実行していなければ、そのコンテナは対象になりません。
発見者の報告では、通常のglibcを使用するDebianやUbuntu、Fedoraなどは対象外とされています。ただし、同じホスト上でAlpine Linuxのコンテナや仮想マシンを運用している場合は、それぞれの環境でsshdの有無と設定を確認してください。
なぜ認証を回避できるのか
PAMを使用しない場合、sshdは入力されたパスワードをcrypt()という関数で処理し、その結果をアカウントに保存された値と比較します。Alpine Linuxによれば、対象となるアカウントの保存値が短すぎてソルトを含まない場合、sshdは別のアカウントからソルトを借りて処理します。
一方、muslのcrypt()は、256バイトを超えるパスワードを受け取ると、エラーを示す文字列として*を返します。この文字列が、パスワード欄に保存された*と一致してしまうため、条件を満たすと認証が成功します。
OpenSSHの開発チームは、問題の根本原因はsshdの外部にあるとしつつ、sshdを通じて悪用できるため、OpenSSH側で回避できるようにしたと説明しています。
今回の脆弱性は「*sshole」とも呼ばれています。この名称は、発見者のÖzgün Kültekin氏が問題の解説サイトで用いている通称です。OpenSSHのリリースノートでは、パスワード認証を回避される問題として説明されています。脆弱性を識別する番号はCVE-2026-123158です。
名前に含まれる「*」は、今回の問題でパスワード欄の値とエラー時の戻り値に共通して現れる記号です。「SSH」と、セキュリティ上の穴を意味する「hole」も連想させます。
さらに「*sshole」は、英語の下品な罵倒語「asshole」の先頭を伏せ字にした表記にも読めます。発見者のサイトでは、侵入した攻撃者を指す文脈でもこの表現が使われています。命名意図の詳細は明示されていませんが、技術的な特徴と言葉遊びを重ねた名前と見ることができそうです。
どのような被害につながるか
影響を受けるサーバーに攻撃者がログインできた場合、そのアカウントがアクセスできるファイルの閲覧・変更や、プログラムの実行につながる可能性があります。さらに、そのアカウントに管理者権限を取得する手段が与えられていれば、サーバー全体が侵害されるおそれがあります。
Alpine Linuxは、公式のtiny-cloudイメージに含まれるalpineユーザーを例として挙げています。このユーザーはパスワードなしでdoasを使える構成であり、ほかのアカウントに対象となるパスワードハッシュが設定されるなど、攻撃条件が揃うと、ログイン後にroot権限を取得される可能性があります。
なお、rootアカウントへの直接ログインはSSH側の設定にも左右されます。Alpine Linuxによると、OpenSSHの既定値であるPermitRootLogin prohibit-passwordは、rootへのパスワードによる直接ログインを防ぎます。ただし、別のアカウントから管理者権限を取得できる場合まで防ぐものではありません。
対応方法
Alpine Linux：修正済みパッケージに更新する
Alpine Linuxは修正済みパッケージを公開しています。OS全体のパッケージを更新する場合、公式案内では次のコマンドを示しています。
sudo apk upgrade -U -a
sudo rc-service sshd restartapk upgrade -U -aはOpenSSH以外のパッケージも更新します。運用中のサーバーでは、更新対象や他のサービスへの影響を確認してください。パッケージを更新するだけでは稼働中のsshdは置き換わらないため、更新後の再起動が必要です。sudoを使用していない環境では、適切な管理者権限で実行してください。
Alpine Linuxの公式情報に掲載された主な修正済みバージョンは次のとおりです。古いOpenSSHのバージョン番号でも、ディストリビューションが修正を移植している場合があります。
| Alpine Linuxの系列 | 修正済み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.16〜3.20向けの修正済みパッケージも掲載されています。ただし、サポートが終了した系列では、今回の修正が提供されても、ほかの問題への継続的な更新は期待できません。サポート中の系列への移行も計画してください。
更新できない場合：パスワード認証を無効にする
すぐに更新できない場合、Alpine Linuxはsshdの設定で次の項目を指定し、設定を確認したうえでsshdを再起動するよう案内しています。
PasswordAuthentication no設定の前に公開鍵認証によるログインが可能であることを確認し、変更後に別の接続でログインを試すまで、現在のセッションを維持してください。リモート接続できなくなると、管理用コンソールなどからの復旧が必要になる場合があります。
sshd_configには複数の設定ファイルやMatch条件が含まれる場合があります。実効設定が接続条件に応じて意図どおりになっているか確認してください。Alpine Linuxの公式案内には、設定変更と構文確認の具体例が掲載されています。
公開されていたサーバー：ログも確認する
Alpine Linuxは、パスワードを設定していないアカウントについて、SSHログにAccepted password forという記録がないか確認するよう勧めています。該当する記録は、想定外のパスワードログインを調査する手掛かりになります。
あわせて、doasの利用履歴や、新たに作られたユーザー・ファイル・公開鍵などを確認します。攻撃者のログインを否定できない場合、Alpine Linuxは侵害されたシステムとして扱うよう求めています。ログが残っていないことだけで、侵害がなかったとは判断できません。
そのほかの変更と今後の非推奨予定
OpenSSH 10.6p2には、今回のセキュリティ対処のほか、耐量子計算機暗号を組み合わせた署名方式ssh-mldsa44-ed25519を、CA署名アルゴリズムとして利用できるようにする修正なども含まれます。
また、リリースノートでは、scp -Rの非推奨化を案内しています。このオプションはリモートホスト上でscpを実行して、リモート間のコピーを行うものです。OpenSSH 10.6では引き続き動作しますが警告が表示され、将来のリリースではオプションが無視され、scpを実行したホストを経由する既定のコピー方式になる予定です。自動化スクリプトでscp -Rを使用している場合は、転送経路や認証方法の変更に備えて確認してください。