AMIから起動したRHEL系インスタンスで、SSHのパスワードログインができなくなった。
ネットワークは到達している。
OSも起動している。
sshd も動いているように見える。
それでも入れない。
原因は、/etc/ssh/sshd_config そのものではなく、起動時に動作する cloud-init 側の設定でした。
今回の記事で伝えたいのは、パスワード認証の是非ではありません。
クラウド環境では、OSの設定ファイルだけを見ても、起動後の状態を正しく判断できないことがある。
ここがポイントです。
事象：AMIから起動したらSSHパスワードログインできない
あるRHEL系のEC2環境で、SSHのパスワードログインを有効にした状態でAMIを作成しました。
元のEC2インスタンスでは、SSHのパスワード認証が有効になっていました。
そのため、AMIから新しいEC2インスタンスを起動しても、当然同じようにSSHログインできるだろうと考えていました。
ところが、実際にAMIからインスタンスを起動すると、SSHのパスワードログインができません。
OSは起動している。
インスタンスのステータスチェックも通っている。
ネットワーク的にも到達できている。
でも、SSHのパスワード認証が通らない。
この状態になると、非常に困ります。
障害調査をしたい。
ログを見たい。
設定を戻したい。
サービスを再起動したい。
そう思っても、そもそもサーバに入れなければ作業できません。
SSHログイン不可は、単なる接続ミスではありません。
復旧作業の入口を塞いでしまう、かなり重いトラブルです。
最初に疑いたくなるポイント
SSHログインできない場合、まず疑うのは、だいたい次のような箇所です。
セキュリティグループ
ネットワークACL
ルートテーブル
鍵の指定ミス
ユーザー名の誤り
/etc/ssh/sshd_config の設定
sshd サービスの状態
OS側のファイアウォール
もちろん、これらを確認すること自体は正しいです。
SSH接続不可の調査では、ネットワーク、認証、OS設定、サービス状態を順番に切り分ける必要があります。
ただ、今回の事象では、単純に /etc/ssh/sshd_config だけを見ていても原因にたどり着きにくいものでした。
なぜなら、SSHの設定を起動時に別の仕組みが変更していた可能性があるからです。
原因：cloud-initがSSH設定を上書きしていた
原因は、cloud-init の設定でした。
cloud-init は、クラウド環境でインスタンス起動時に初期設定を行う仕組みです。
EC2でLinuxインスタンスを起動するとき、ホスト名、ユーザー、SSH関連設定、ユーザーデータなど、起動時にさまざまな初期処理が行われます。
今回問題になったのは、次の設定です。
/etc/cloud/cloud.cfg
ssh_pwauth: 0
この `ssh_pwauth: 0` は、SSHのパスワード認証を無効にするための設定です。
クラウド環境では、パスワード認証よりも鍵認証、IAM、SSM Session Managerなどで接続経路を管理する方が、セキュリティ上のベストプラクティスに沿いやすいため、このような初期設定になっていることがあります。
問題は、その設定自体ではありません。
運用上の理由でパスワード認証を使う設計にしている場合、`cloud-init` 側の設定を理解していないと、AMIから起動したときに想定外のログイン不可につながる、という点です。
この状態でAMIからインスタンスを起動すると、起動時に cloud-init が動作し、SSHの設定を反映することがあります。
その結果、/etc/ssh/sshd_config が次のような状態になる場合があります。
/etc/ssh/sshd_config
PasswordAuthentication no
つまり、AMI取得前に手作業で /etc/ssh/sshd_config を変更していたとしても、AMIから起動したタイミングで cloud-init 側の設定が再度反映されることがあります。
ここが落とし穴です。
AMIから新しいEC2インスタンスを作成した場合、cloud-init はそれを新しいインスタンスの初回起動として扱い、初期設定を再実行することがあります。
そのため、
元サーバではログインできていた
ことと、
AMIから起動した新インスタンスでも同じようにログインできる
ことは、必ずしも同じではありません。
クラウド環境では、ここを混同するとトラブルにつながります。
図で見るとこういう流れ
この事象を図で整理すると、流れはこうです。
AMI取得前は、sshd_config 上ではパスワード認証が有効
しかし、cloud.cfg には ssh_pwauth: 0 が残っている
AMIから新しいインスタンスを起動すると、cloud-init が実行されることがある
cloud-init が設定を反映し、sshd_config が書き換えられることがある
結果として、PasswordAuthentication no になり、SSHパスワードログインできなくなる
見るべきポイントは、
今のsshd_configがどうなっているか
だけではありません。
起動時に誰がsshd_configを書き換える可能性があるか
まで見る必要があります。
クラウド環境では、ある時点の設定ファイルだけを見ても不十分です。
その設定が、いつ、誰によって、どのタイミングで反映されるのか。
ここまで見ないと、起動後の状態を正しく予測できません。
対策：cloud-init側の設定も確認する
対策は、/etc/ssh/sshd_config だけではなく、cloud-init 側の設定も確認することです。
今回の例では、SSHパスワード認証を有効にする必要がある場合、次のように設定します。
ssh_pwauth: 1
これにより、AMIからインスタンスを起動した際に、SSHパスワード認証を有効にする設定として扱われます。
結果として、/etc/ssh/sshd_config 側も次のようになります。
PasswordAuthentication yes
ただし、新しめのRHEL系OSや最近のAMIでは、/etc/cloud/cloud.cfg 本体を直接編集するよりも、
追加設定ファイルとして管理する方が望ましい場合があります。
たとえば、次のようなファイルです。
/etc/cloud/cloud.cfg.d/99_custom_ssh.cfg
中身は、たとえば次のようにします。
ssh_pwauth: 1
cloud.cfg 本体は基本設定として残し、環境ごとの差分や個別設定は cloud.cfg.d 配下のファイルで管理する、という考え方です。
ただし、どの方法を使うべきかは、利用しているOS、AMI、cloud-init のバージョン、運用ルールによって変わります。
重要なのは、見えている設定だけを直すことではありません。
それを後から上書きする仕組みが残っていないかを見ることです。
起動後に確認するコマンド例
実際のトラブルシューティングでは、
「起動後に本当に sshd_config がどうなっているのか」
「cloud-init が動いていた形跡はあるのか」
を確認したくなります。
まず、起動後のSSH設定は、次のように確認できます。
grep -i '^PasswordAuthentication' /etc/ssh/sshd_config
パスワード認証が有効であれば、次のように表示されます。
PasswordAuthentication yes
逆に、意図せず無効化されている場合は、次のようになります。
PasswordAuthentication no
また、cloud-init が起動時に動作していたかを確認するには、ログを見る方法があります。
sudo grep -i 'ssh\|pwauth\|PasswordAuthentication' /var/log/cloud-init.log
ただし、ログの出方は、OS、AMI、cloud-init のバージョンによって異なります。
このコマンドで必ず原因が一発で分かる、というものではありません。
重要なのは、起動後の /etc/ssh/sshd_config だけでなく、起動時に cloud-init が何を実行したのかも確認することです。
RHEL 8/9/10でも考え方は同じ
ここまでの話は、特定の古いRHEL環境だけの話ではありません。
RHEL 8、RHEL 9、RHEL 10などのRHEL系OSでも、cloud-init がインスタンス起動時の初期設定に関与するという考え方は同じです。
そのため、AMIから新しいインスタンスを起動したときに、cloud-init の設定に基づいてSSH関連設定が反映される可能性があります。
ただし、OSバージョン、AMIの提供元、cloud-init のバージョンによって、デフォルト値や設定ファイルの構成は異なります。
つまり、見るべきポイントは、RHELのバージョン名だけではありません。
cloud-init が何を管理しているか
cloud.cfg や cloud.cfg.d に何が書かれているか
AMIから新規起動したときに何が再実行されるか
sshd_config が最終的にどうなっているか
SSHログインできなくなった場合の復旧経路があるか
最新版でも見るべき本質は変わりません。
「SSH設定ファイルを直したから終わり」ではなく、起動時にその設定を上書きする仕組みが残っていないかを見る。
これが重要です。
もし実際に入れなくなったら
実際にSSHログインできなくなった場合でも、環境によっては救出手段が残っていることがあります。
たとえば、EC2 Instance Connectが利用できる条件であれば、別経路で接続できる可能性があります。
また、SSM Agentが動作しており、必要なIAMロールやネットワーク経路が用意されている場合は、SSM Session Managerから接続できる可能性があります。
さらに、NitroベースのインスタンスでEC2シリアルコンソールが有効化されていれば、ネットワーク経由のSSHに依存せずにトラブルシュートできる場合もあります。
ただし、これらは万能ではありません。
事前の有効化、IAM権限、対応OS、インスタンスタイプ、ネットワーク条件、SSM Agentの状態などに左右されます。
障害が起きてから初めて使おうとしても、すぐに使えるとは限りません。
最低限、AMIを作成する前に、EC2 Instance ConnectやSSM Session Managerなど、SSH以外の接続経路が使える状態かを確認しておくことが、現実的な保険になります。
「入れなくなったら考える」では遅い場合があります。
ただし、パスワード認証を推奨する話ではない
ここで誤解してはいけないのは、この記事はSSHのパスワード認証を推奨する話ではない、ということです。
本番環境では、SSH接続方式は慎重に設計すべきです。
鍵認証を使うのか。
踏み台サーバを経由するのか。
SSM Session Managerを使うのか。
IAMやMFAと組み合わせるのか。
運用者のアクセス経路をどう制限するのか。
障害時の緊急ログイン手段をどうするのか。
これらは、セキュリティ要件や運用要件に応じて決めるべきものです。
今回伝えたいのは、
パスワード認証を有効にしましょう
という話ではありません。
そうではなく、
AMIから起動したとき、OS設定がそのまま維持されるとは限らない
という話です。
もっと言えば、
起動時に設定を書き換える仕組みを知らないと、
設計したつもりの状態でサーバが起動しない
という話です。
まとめ
今回の事象は、RHEL系のEC2環境でAMIからインスタンスを起動した際、SSHのパスワードログインができなくなったというものです。
原因は、cloud-init 側にSSHパスワード認証を無効化する設定が残っていたことでした。
ssh_pwauth: 0
この設定により、AMI起動時に cloud-init がSSH設定を反映し、PasswordAuthentication no になることがあります。
対策としては、必要に応じて cloud.cfg または cloud.cfg.d 配下の設定を確認し、SSHパスワード認証をどう扱うかを明示します。
ssh_pwauth: 1
そして、起動後の sshd_config が期待どおりになっているか確認します。
PasswordAuthentication yes
ただし、重要なのはパスワード認証を有効にすることではありません。
本質は、クラウド環境では、OSの設定ファイルだけを見ても不十分だということです。
AMI、cloud-init、ユーザーデータ、Launch Template、Auto Scaling、構成管理ツール、起動後スクリプト。
こうした仕組みが、サーバ起動時や再作成時に設定を書き換えることがあります。
AMIを使う設計では、最低限、次の観点を確認しておくべきです。
cloud.cfg や cloud.cfg.d にSSH関連設定が残っていないか
AMI起動後に cloud-init が何を実行するか把握しているか
起動後に sshd_config が期待値になっているか確認したか
SSHログインできなくなった場合の復旧経路があるか
「設定したはずなのに、なぜか反映されていない」。
そういう事象に当たったとき、OSの設定ファイルだけでなく、起動時に何が動いているかを問う習慣が、現場での対応速度を変えます。
これは、基盤SEやインフラエンジニアだけでなく、クラウド上で動くシステムに関わるアプリケーションエンジニアにとっても大事な視点だと思います。
関連記事
今回の話は、単なるSSH設定の話ではなく、詳細設計・運用設計で「起動時に何が反映されるか」を見落とさない、という話でもあります。
この考え方については、以下の記事でも整理しています。
【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程
シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。
コメント