1980年に「誰も入ってこられないように」と締め出した`*`が46年後に鍵になった理由

1980年、Unixの開発者ビル・ジョイ（Bill Joy）は、誰もログインしてはならない daemon アカウントのパスワード欄にアスタリスク（*）を挿入しました。当時、パスワードハッシュは誰でも読み取れる /etc/passwd に保存されていましたが、 * はハッシュ化されたパスワードではないため、いかなるパスワードとも一致せず、ログインを根本から遮断する仕組みとして機能していました。同じ項目の実名（real name）フィールドには「the devil himself」と記されていました ¹。

しかし、2026年、この * がむしろ「257文字以上1024文字以下の任意の文字を入力すれば通過できる」鍵へと変わってしまいました。この問題を発見した研究者が公開した「sshhole」脆弱性は、サーバーが応答速度の差からアカウント情報を隠蔽しようとするタイミング攻撃防御ロジックと、Linuxライブラリ musl のパスワード長さ制限が偶然にも重なり合った際に発生します ²。特に、PAM（Pluggable Authentication Modules）を使用しないAlpine LinuxやOpenWrtといった軽量な環境で顕在化します。OpenSSH 10.6p2 バージョン（2026年11月5日リリース）で、この問題は修正されています ³。

* が鍵となるまでの過程：3つのルールの衝突

sshhole脆弱性は、異なる時期と目的で導入された3つのセキュリティ対策が、ある1行の比較演算で出会うことで生じます。それぞれの対策は単体では妥当でしたが、組み合わさった際に認証バイパスを許容してしまいました。

1. muslライブラリにおけるエラー戻り値の変更（2012年）： C標準ライブラリの一種である musl は、 crypt() 関数（パスワードハッシュを計算する関数）が失敗した際に、 NULL の代わりに * を返すように修正されました。これは、開発者が NULL の値を処理せずにプログラムがクラッシュすることを防ぐための措置でした。通常のパスワードハッシュは $6$salt$hash のような形式であるため、開発者は * が実際のパスワードと一致することはないと想定していました ²。

2. 256文字長さ制限の導入（2012年）： 同じ時期に musl は、SHA-512ハッシュ計算に対して256バイトという長さ制限を設けました。パスワードが長いほど計算時間が増加するため、極端に長い入力によってサーバーが長時間占有され、他の接続に影響を及ぼすことを防ぐためです。入力が256文字を超えると、計算すら行わずに即時にエラー値である * を返します ²。

3. OpenSSHのタイミング攻撃防御（2016年）： OpenSSH は、「存在しないアカウント」への接続時にレスポンス時間が短くなることで、ハッカーがアカウント情報を推測するタイミング攻撃を防ぐためにロジックを変更しました（CVE-2016-6210）。元来、ハッシュが存在しないアカウント（ * など）にログイン試行が行われた場合は即時に拒否していましたが、修正後は実際のハッシュ計算と同様の挙動を模倣すべく、「他アカウントのソルト（セキュリティ用乱数）」を借用して仮想的にハッシュを計算し、その後失敗させる仕様となりました ²。

衝突ポイント： * で表示されるアカウントに対し、257文字以上（1024文字以下）のパスワードで接続すると、以下の流れで認証が通過します。なお、このバイパスが作動するには、事前に一般的な長さの誤ったパスワードで一度ログインに失敗した履歴が必要です ²。

1. OpenSSH は、保存されている値が * であるため、実際のハッシュ計算が可能でないと判断します。
2. タイミングの一貫性を保つため、他アカウントのソルトを借用し、ユーザーが入力した257文字のパスワードでハッシュ計算を試みます。
3. サーバーが musl ライブラリを使用しているため、256文字を超えた入力に対して計算結果として * を返します。
4. サーバーは「計算結果（ * ）」と「保存されたパスワードフィールド（ * ）」が文字列として一致するため、認証成功として処理します ²。

17,600回のテストで確認された条件

この脆弱性はすべてのサーバーで発生するわけではありません。sshhole.com を運営し、この問題を公開した研究者は、glibcとmuslライブラリ、PAMの有効化設定、shadowファイルの設定を組み合わせて複数のOpenSSHビルドを構築しました。約17,600件の異常なログイン試行を実施した結果、「muslライブラリを使用しながらPAMを無効化したビルド」のみで、この認証バイパスが成功することを確認しました ²。

大半の一般的なLinuxディストリビューション（Debian、Ubuntu、Fedoraなど）はPAM認証モジュールを使用しています。PAMは、パスワードフィールドが * の場合、ハッシュ計算関数（ crypt() ）を呼び出さずに認証を拒否するため、一般的な環境ではこの脆弱性の影響を受けません。OpenSSHプロジェクト自体のテスト環境もOpenBSDとglibcに集中しており、この特殊な「musl ＋ PAM無効化」の組み合わせは長らく検証されていませんでした ²。

Alpineクラウドイメージにおける現実的な脅威

sshholeが特に懸念されるのは、Alpine Linuxの公式クラウドイメージ（AWS、Azureなど）が、この条件をデフォルトで備えているためです。

Alpineは2019年以前のバージョンでは、rootアカウントのパスワードが空欄であり、空パスワードでログイン可能という問題を抱えていました（CVE-2019-5021）。これを防ぐためにパスワードフィールドを ! に変更しましたが、PAMを使用しない環境では、 ! に設定するとSSH鍵認証まで同時に遮断されるという副作用が発生しました。そのため、Alpine 3.16 バージョン（2022年）以降では、鍵認証を維持するためにパスワードフィールドを再び * に戻しています ², ⁴。

デフォルト状態のAlpine公式クラウドイメージには、 PasswordAuthentication yes と UsePAM no が設定されています。さらに、デフォルトで生成される alpine アカウントは、 doas（コマンド権限昇格ツール）をパスワードなしで使用できるよう設定されています。したがって、攻撃者は257〜1024文字の任意の文字列を用いて alpine アカウントにログインした後、 doas コマンドを通じて追加の認証なく即座にroot権限を取得できます ²。

即時対応および点検方法

sshhole脆弱性は、OpenSSH 10.6p2 バージョン（2026年11月5日リリース）にて公式に修正されました ³。

1. アップデート 最も安全な対策は、OpenSSHを10.6p2以上へ更新することです。Alpine Linuxでは以下のコマンドで更新できます。

apk upgrade openssh

2. 設定変更 更新が不可能な環境では、パスワード認証自体を無効化する必要があります。 /etc/ssh/sshd_config.d/00-no-passwords.conf などの設定ファイルに以下の内容を追加します。

PasswordAuthentication no

設定変更後、Alpine Linuxでは rc-service sshd restart コマンドでSSHサービス再起動を行うことで反映されます ²。

3. 侵入有無の確認 すでにサーバーが侵害されているかを点検するには、サーバーログを確認する必要があります。パスワードフィールドが正確に * であるアカウントが、「パスワード認証方式」でログインに成功した記録が残っている場合、この脆弱性が悪用された可能性を検討する必要があります ²。