InfraAcademy Blog

長いパスワードだけでSSHに入れてしまう？OpenSSH 10.6p2で直ったAlpine Linuxの問題と、sshd_configで確認したい設定

公開日: 2026-11-07 更新日: 2026-11-07 著者: ryu | #Linux #LPIC #セキュリティ

Linux・ネットワーク・AWSを、環境構築なしで実践学習できます

こんにちは、インフラエンジニアのryuです。

2026年11月5日に、OpenSSHの移植版（portable）の 10.6p2 が公開されました。リリースノートでは、musl libcを使い、PAMを無効にしているLinuxに影響する重要なセキュリティ上の修正と説明されています。

報道では、Alpine Linuxの標準的な構成で、ロックされているはずのアカウントに、とても長いパスワードを送るだけでログインできてしまう問題として紹介されています。

この記事では、どんな条件で問題が起きるのか、自分の環境が当てはまるかをどう確かめるのかを順番に整理します。SSHや /etc/shadow を勉強中の人にとっても、仕組みを知るよい題材になるニュースです。

OpenSSH 10.6p2で何が修正された？¶

まず、ニュースの中身を整理しておきましょう。

問題が起きるのは、次の条件がそろったときだと報告されています。

条件	内容
Cライブラリ	glibcではなく、musl libcを使っている（Alpine Linuxなど）
PAM	sshdがPAMなしでビルドされている、または `UsePAM no` で動いている
パスワード認証	`PasswordAuthentication yes` になっている（OpenSSH本体の既定値）
対象のアカウント	`/etc/shadow` のパスワード欄が `*` で、ログインできないようにロックされている

この条件がそろうと、256バイトを超える長いパスワードを送ったときに、ロックされたアカウントへのログインが通ってしまうと報告されています。報道では、257バイトから1024バイトほどのパスワードで成功したとされています。

Alpine LinuxのOpenSSHのパッケージは、PAMを使わない構成が標準です。そのため、Alpineが主な影響対象として名前が挙がっています。ほかにも、muslを使いPAMなしでOpenSSHを入れている環境が当てはまります。

逆に、次の環境は影響を受けないと報告されています。

環境	理由
glibcを使うLinux（Ubuntu、Debian、RHEL系など）	muslの動きが関係しないため
`UsePAM yes` で動いているsshd	パスワードの確認をPAMが行うため
Dropbear（別のSSHサーバー）	OpenSSHではないため
OpenBSD	muslを使っていないため

なお、この問題のCVE番号については、CVE-2026-123158 として扱う記事がある一方で、最初の告知の時点ではCVE番号が付いていなかったとする記事もあります。この記事では番号を断定せず、OpenSSH 10.6p2で修正された問題として扱います。

なぜ長いパスワードでログインできてしまうのか¶

ここからは、仕組みを見ていきます。少し難しく感じるかもしれませんが、/etc/shadow の役割が分かっていれば理解できる内容です。

Linuxでは、ユーザーのパスワードはそのままの形では保存されません。/etc/shadow には、パスワードをハッシュ化した値が入っています。

# /etc/shadow の1行の形（ユーザー名:パスワード欄:最終変更日:...）
alice:$6$ソルト$ハッシュ値:20400:0:99999:7:::
daemon:*:20400:0:99999:7:::

ログインのときは、入力されたパスワードを同じ方法でハッシュ化し、その結果が /etc/shadow の値と一致するかを比べます。このハッシュ化に使われるのが、Cライブラリの crypt() という関数です。

/etc/shadow のパスワード欄が * や ! になっているアカウントは、どんなパスワードを入れてもハッシュ値と一致しないため、パスワードではログインできません。システムが使うアカウントをロックしておく、よくある書き方です。

今回の問題は、この比較のところで起きました。

報告によると、musl libcの crypt() は、長すぎるパスワードを受け取ると処理を行わずに * という文字列を返します。PAMを使わないsshdは、その返り値を /etc/shadow の値とそのまま比べていました。

ロックされたアカウントのパスワード欄も * です。つまり、長すぎるパスワードを送ると、* と * を比べることになり、一致したと判断されてしまう、という流れです。

musl側の不具合というより、crypt() の返り値の扱い方の問題だとする見方もあります。OpenSSH 10.6p2では、この組み合わせで誤ってログインが通らないように修正されています。

/etc/shadow の各項目の意味は、LPIC-1のユーザー・グループ管理の練習問題で詳しく扱っているので、あわせて読んでみてください。

ニュースを読む前に知っておきたい、PAMとsshdの設定¶

今回のニュースには、PAMやsshdの設定項目など、学習を始めたばかりだと聞き慣れない言葉がいくつか出てきます。ここで一度整理しておきましょう。

PAMとは？¶

PAM（Pluggable Authentication Modules）は、Linuxでユーザーの認証をまとめて扱う仕組みです。

sshdやログイン画面などのプログラムは、パスワードの確認を自分で行う代わりに、PAMに任せることができます。PAMを使う構成では、パスワードの確認はPAMのモジュールが担当するので、今回のようにsshdが crypt() の結果を直接比べることはありません。

UbuntuやRHEL系のディストリビューションでは、OpenSSHのパッケージがPAMを使う設定になっているのが一般的です。一方でAlpine Linuxは、軽さを重視してPAMを使わない構成を標準にしています。この違いが、今回の影響範囲の差につながりました。

`*` と `!` の違い¶

/etc/shadow のパスワード欄でロックを表す書き方には、* と ! の2つがよく出てきます。

パスワード欄	よく使われる場面
`*`	システムが使うアカウントなど、最初からパスワードを設定しないアカウント
`!` で始まる値	`passwd -l` や `usermod -L` で、一時的にロックしたアカウント（元のハッシュ値の前に `!` が付く）
`$6$...` など	SHA-512などでハッシュ化された、通常のパスワード

今回の問題で名前が挙がっているのは、パスワード欄が * のアカウントです。システムが使うアカウントの多くはこの形なので、普段ログインしないアカウントだからといって安心できない、という点に注意が必要です。

覚えておきたいsshdの設定項目¶

/etc/ssh/sshd_config には多くの設定がありますが、認証に関係するものとして、まず次の4つを押さえておくとよいと思います。

設定項目	何を決めるか
`PasswordAuthentication`	パスワードでのログインを許可するか
`PubkeyAuthentication`	公開鍵でのログインを許可するか
`PermitRootLogin`	rootで直接ログインできるか。OpenSSHの既定値は `prohibit-password`（パスワードでのrootログインは不可）
`UsePAM`	認証などをPAMに任せるか

インターネットに公開するサーバーでは、パスワード認証を止めて公開鍵認証だけにする構成がよく使われます。今回の問題も、パスワード認証を止めていれば条件に当てはまらなくなります。

自分の環境が当てはまるか確かめる方法¶

次に、自分のサーバーが条件に当てはまるかを確かめる方法です。ここで紹介するのは、どれも状態を表示するだけのコマンドです。

ディストリビューションとCライブラリを確認する¶

最初に、どのディストリビューションで、どのCライブラリを使っているかを確認します。

cat /etc/os-release            # ディストリビューションの名前とバージョンを表示する
ldd "$(command -v sshd)"       # sshd がどのライブラリを使っているかを表示する
ssh -V                         # OpenSSH のバージョンを表示する（クライアント側）

ldd の結果に musl を含むライブラリが出てくれば、muslの環境です。UbuntuやRHEL系のように libc.so.6 が出てくる環境はglibcなので、今回の問題の条件からは外れます。

ssh -V が表示するのはクライアントのバージョンですが、同じパッケージから入れている場合は、サーバー側の目安になります。

sshdの設定と、ロックされたアカウントを確認する¶

続いて、sshdの設定を確認します。sshd -T は、設定ファイルを読み込んだ結果、実際に使われる値を一覧で表示するコマンドです。

sudo sshd -T | grep -iE 'usepam|passwordauthentication'  # 実際に使われる値を確認する
sudo grep -E '^[^:]+:\*:' /etc/shadow                     # パスワード欄が * のアカウントを表示する

passwordauthentication yes になっていて、PAMを使っていないmuslの環境であれば、今回の修正の対象です。2つ目のコマンドで表示されるのが、パスワード欄が * でロックされているアカウントです。

Alpine Linuxでは、PAMを使わない openssh-server と、PAMを使う openssh-server-pam の2つのパッケージがあります。どちらが入っているかは、次のように確認できます。

apk list --installed | grep openssh   # 入っている OpenSSH のパッケージを表示する

openssh-server-pam を入れていても、UsePAM no にしている場合は条件に当てはまると報告されているので、sshd -T の結果とあわせて見てください。

対策は2つ。更新と、パスワード認証の停止¶

条件に当てはまる場合の対策は、大きく分けて2つです。

1つ目は、OpenSSHを修正済みのバージョンに更新し、sshdを再起動することです。Alpine Linuxでは、開発版のedgeだけでなく、安定版のブランチにも修正済みのパッケージが出ていると報告されています。

sudo apk update && sudo apk upgrade openssh   # Alpine で OpenSSH を更新する
sudo rc-service sshd restart                  # Alpine（OpenRC）で sshd を再起動する

Alpineは標準の起動の仕組みがsystemdではなくOpenRCなので、再起動には rc-service を使います。systemdの環境なら systemctl restart sshd です。systemdのコマンドはLPIC-1のsystemd・systemctlの練習問題で整理しています。

2つ目は、すぐに更新できない場合に、パスワード認証そのものを止めることです。/etc/ssh/sshd_config で次のように設定し、sshdを再起動します。

# /etc/ssh/sshd_config
PasswordAuthentication no

この設定にすると、パスワードでのログインができなくなり、公開鍵認証だけになります。設定を変える前に、公開鍵でログインできることを必ず別の端末で確認してください。 確認しないまま切り替えると、自分もサーバーに入れなくなります。

対策	すぐできるか	注意点
OpenSSHを更新して再起動	パッケージが出ていればすぐできる	再起動の前に、今の接続を閉じずにおく
パスワード認証を止める	設定の変更だけでできる	公開鍵でログインできることを先に確かめる