OpenSSHの脆弱性「*sshole」――対象は、AlpineなどのLinuxだけ。確認の方法⁠と⁠対⁠処

2026年11月5日、OpenSSHは、緊急のセキュリティリリース（10.6p2）を出しました。非常に長いパスワードを入力するだけで、パスワードのないアカウントに、SSHでログインできてしまう欠陥（CVE-2026-123158、通称「*sshole」）が見つかったためです（OpenSSHのリリースノー⁠ト⁠）⁠。

日本語の見出しは「OpenSSHの脆弱性」でしたが、影響を受ける範囲は、狭いものです。この記事は、対象になる条件と、確認の方法、対処を、一次情報で整理したものです。情報は、2026年11月6日の時点のもの⁠で⁠す⁠。

日本語で出回っている情報には、原文と異なる訳や要約が、かなり見受けられます。この記事は、一次情報を私たちも原文で確認して書いていますが、読者の皆さんも、各社の原文でのご確認をお勧めし⁠ま⁠す⁠。

要点

• 対象は、musl libcを使い、PAMなしで動かしているLinuxのsshdです。例は、Alpine Linuxです。OpenSSHの開発者は、非Linux、glibcのLinux、PAMでパスワード認証をしているLinuxには、この欠陥はない、と書いています（開発者の告⁠知⁠）⁠。
• Debian、Ubuntu、Fedora、RHELは、glibcなので、対象外⁠で⁠す⁠。
• 4つの条件が、すべてそろったときだけ、成立します（下の⁠表⁠）⁠。
• 修正は、OpenSSH 10.6p2です。Alpineも、各ブランチの修正版を出してい⁠ま⁠す⁠。
• 更新できないときは、パスワード認証を止めます。開発者は「すぐに」と書いてい⁠ま⁠す⁠。
• 実際の攻撃は、11月5日の時点で、報告されていません。ただし、公開の再現環境が、すでに出ています（CVEレコードの参照⁠先⁠）⁠。

見出しと、一⁠次⁠情⁠報

成立す⁠る⁠条⁠件

Ethiackの解説は、次の4つが、すべて必要としています（Ethiac⁠k⁠）⁠。

仕組み

Ethiackの解説によると、仕組みは次のとおりです（Ethiac⁠k⁠）⁠。

1. musl libcのcrypt()は、長すぎるパスワード（256バイトを超える）を受け取ると、エラーの印として「*」を返す。glibcは、NULL⁠を⁠返⁠す
2. Alpineでは、パスワードのないアカウントの欄も、「*」⁠で⁠あ⁠る
3. sshdは、返ってきた「」と、保存された「」を比べ、一致したので、ログインを⁠認⁠め⁠る
4. 「*」には、ソルトがないため、sshdは、ほかのアカウントのハッシュから、ソルトを借りる。条件4が必要なのは、このた⁠め⁠で⁠す

修正は、保存されたハッシュが4文字未満なら、拒否する、というものです。コミットの定義に、最小の長さ4が入っています（コミッ⁠ト⁠）⁠。

root⁠には、届⁠く⁠の⁠か

Ethiackの解説は、次のように書いています（Ethiac⁠k⁠）⁠。

• Alpineのrootは、おおむね3.16から「*」ですが、既定のPermitRootLogin prohibit-passwordが、パスワードでのログインを止めます。設定を変えていなければ、届き⁠ま⁠せ⁠ん
• Alpineのクラウド用のイメージ（3.18.11から3.24.3）には、「*」のalpineユーザーと、パスワードなしのdoasがあります。ほかのアカウントに$6$のハッシュがあれば、そこからrootに届⁠き⁠ま⁠す
• Dockerのコンテナは、sshdをパスワード認証で動かしている場合だ⁠け⁠で⁠す
• OpenWrtや、Buildrootのイメージも、条件がそろえば、対象になり⁠え⁠ま⁠す

対象かどうか⁠の⁠確⁠認

自分のサーバーの上で、次の順に確認します。root権限が必要なものがあり⁠ま⁠す⁠。

ldd --version 2>&1 | head -1
sshd -T | grep -i -E "passwordauthentication|usepam"
grep -E '^[^:]+:\*:' /etc/shadow | cut -d: -f1
grep -E '^[^:]+:\$[56]\$' /etc/shadow | cut -d: -f1

1行目は、muslかどうか（出力に「musl」とあれば該当）。2行目は、パスワード認証が有効か、PAMの設定です（PAMなしのビルドでは、usepamの行が出ないことがあります）。3行目は、「*」のアカウントの一覧。4行目は、$5$か$6$のハッシュを持つアカウントの一覧⁠で⁠す⁠。

3行目と4行目の両方に、アカウントが出て、1行目がmusl、2行目でパスワード認証が有効なら、条件に当てはまり⁠ま⁠す⁠。

修正版

OpenSSHの修正版は、10.6p2です（2026年11月5日。リリースノー⁠ト⁠）⁠。

Alpineの修正版は、Alpineの追跡ページでは、次のとおりです（Alpin⁠e⁠）⁠。

3.18以前は、この追跡ページに記載がありません。Ethiackの解説にも、ブランチごとの表がありますが、Alpineの追跡ページとは、一つずつずれています。この記事は、Alpineの追跡ページに従いま⁠し⁠た⁠。

Alpineの修正版は、古いバージョンの番号のまま、修正を取り込んでいます。バージョンの番号だけで調べるスキャナーは、修正済みでも、脆弱と表示することがあります（Ethiac⁠k⁠）⁠。

いま、や⁠る⁠こ⁠と

1. 更新して、sshd⁠を再起⁠動⁠す⁠る

Alpineでは、次のとおりです。再起動するまで、動いているsshdは、古いまま⁠で⁠す⁠。

apk update && apk upgrade
rc-service sshd restart

2. すぐに更新できな⁠い⁠と⁠き

パスワード認証を止めます。OpenSSHの開発者は、PasswordAuthentication noにするか、これらのシステムのSSHを、すぐに止めるよう、書いています（開発者の告知）。公開鍵でログインできることを確認してから、切り替えてくだ⁠さ⁠い⁠。

3. 対象外⁠の⁠環⁠境

DebianやUbuntuなど、glibcの環境と、PAMでパスワード認証をしている環境は、この欠陥の対象外です。特別な対応は、要りま⁠せ⁠ん⁠。

報告⁠の⁠経⁠緯

報告したのは、Wakefieldの Özgün Kültekin 氏です（リリースノート）。OpenSSHは、リリースの前日に、この問題を知りました。そして、禁輸期間を置かずに、翌日、修正版を出してい⁠ま⁠す⁠。

開発者のDamien Miller氏は、長い禁輸期間は、危険な慣行だと考える、と書いています。理由は、AIのエージェントが、数時間で、同じバグを再発見する例を見ているからです（開発者の告知）。リリースノートも、AIが見つけたバグが、別の研究者に、独立に見つけられる例が多い、と書いています。このため、OpenSSHは、当面、リリースを増やす、としています（リリースノー⁠ト⁠）⁠。

未確⁠認⁠の⁠点

• 実際の攻撃は、11月5日の時点で、報告されていません（Ethiack）。その後の状況は、確認できてい⁠ま⁠せ⁠ん
• 「約10年」は、Ethiackの解説によるもので、OpenSSHの告知には、書かれてい⁠ま⁠せ⁠ん
• 「256バイト」と「257バイト」⁠の⁠違⁠い
• OpenWrt、Buildroot、コンテナのイメージで、実際に条件がそ⁠ろ⁠う⁠か
• Alpineの追跡ページには、説明文があり⁠ま⁠せ⁠ん

関⁠連⁠記⁠事

• Linuxカーネルの深刻度9.8の欠陥――AIが実証した攻撃の条件と、ディストリビューションごとの修正状況：同じ週の、Linuxカーネルの欠陥。ディストリビューションごとの修⁠正⁠状⁠況
• 不正アクセスが相次ぐ今、経営者が先に決めておくこと――ゼロトラストとAI時代のセキュリティ対策：不正アクセスが相次ぐ今の、経営者向けの⁠考⁠え⁠方

自社のサーバーの、設定の確認や、更新の計画でお困りの方は、お問い合わせくだ⁠さ⁠い⁠。