サイトアイコン 協栄情報ブログ

EC2（RHEL）複製時に発生したパスワード認証不可事象について

mizuki.j

お世話になっております。水木です。

現場業務にて、AWS EC2 上の Linux Server（RHEL）を複製する機会がありました。
Linux サーバーの複製自体は複数回経験していましたが、今回初めて遭遇した事象があったため、備忘としてまとめます。

同様の状況に直面した方の参考になれば幸いです。

作業内容

既存の Linux Server をもとに、検証用（ダミー）のテストサーバーを複製・作成する。

発生した問題

複製元サーバーではユーザーのパスワード認証が可能でしたが、複製先ではパスワード認証ができない状態になりました。

さらに、

という状況で、完全にログイン不能となりました。

原因

調査の結果、原因は cloud-init の設定にありました。

複製元サーバーの /etc/ssh/sshd_config では、

PasswordAuthentication yes

と設定されていました。

しかし、cloud-init の設定ファイル内に

lock_passwd: true

が指定されており、OSレベルでデフォルトユーザーのパスワードがロックされていました。

つまり、

sshd 設定上はパスワード認証が有効

しかし OS 側でパスワードがロックされている

という状態になっていたのが原因でした。

補足：cloud-init とは

cloud-init は、AWS や Azure などのクラウド環境で Linux インスタンス初回起動時の初期設定を自動化するツールです。

主な用途：

今回影響していたのは以下の設定です。

lock_passwd: true

これは、

セキュリティ上の理由により、デフォルトユーザーのパスワードログインを無効化する

という意味になります。

対応手順

① AMI からインスタンス起動時に、自身で管理しているキーペアを選択

（未作成の場合は新規作成）

② キーペアでログイン

③ SSH 設定確認・修正

/etc/ssh/sshd_config

内の

PasswordAuthentication yes

を確認（環境によって複数箇所ある場合あり）

④ ユーザーパスワード再設定

passwd ユーザー名

⑤ 必要に応じて /etc/shadow のロック状態確認

passwd -S ユーザー名

余談：なぜ今まで今回の事象に直面しなかったか

現在私が担当している業務は OS バージョンアップ対応であり、新規で EC2 を構築する際には共通設定として

lock_passwd: false ※デフォルトは trueを指定しています（デフォルトは true）。

そのため、普段複製しているサーバーは既にパスワードロックが無効化されており、今回のような問題には遭遇したことがありませんでした。

しかし今回の複製元は OS VerUP 前の既存リソース であり、
lock_passwd: true のままだったことが原因でした。

まとめ

これまで cloud-init の設定は作業手順として実施していましたが、今回の事象を通して、

「自分が設定している値が具体的にどのレイヤーに影響するのか」

を改めて理解することができました。

設定は単体ではなく、複数レイヤーで作用することを実感しました。

今後も様々な事象に遭遇しながら、より深い理解を積み重ねていきたいと思います。

モバイルバージョンを終了