お世話になっております。水木です。
現場業務にて、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 インスタンス初回起動時の初期設定を自動化するツールです。
主な用途：
-
ホスト名設定
-
ネットワーク設定
-
ユーザー作成
-
パッケージインストール
-
SSH 設定制御
今回影響していたのは以下の設定です。
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 の設定は作業手順として実施していましたが、今回の事象を通して、
「自分が設定している値が具体的にどのレイヤーに影響するのか」
を改めて理解することができました。
-
sshd_config（アプリケーションレイヤー）
-
cloud-init（初期化制御レイヤー）
-
OSレベルのパスワードロック
設定は単体ではなく、複数レイヤーで作用することを実感しました。
今後も様々な事象に遭遇しながら、より深い理解を積み重ねていきたいと思います。