TOP>コラム一覧>EC2のLinuxサーバにログインできなくなったときの対処法

EC2のLinuxサーバにログインできなくなったときの対処法

はじめに

こんにちは、CTCの須貝です。

EC2にログインするためのキーペアをなくしてしまった。
OSユーザのパスワードをなくなってしまった。
パスワードの期限が切れてしまった。
そのようなときに、どのような対応が可能か、皆さんご存じでしょうか。

私が直面したケースでは、LinuxOSのセキュリティ強化の検証を行っていたところ、パスワードの有効期限が切れ、ログイン可能なユーザがなくなってしまいました。
ssm-userを利用してリカバリできるように構築していたのですが、そんな時に限ってssm-agentの不具合(※)でSessionManagerでのログインもできず、Run Commandもできず、困ったことがあります。
※EC2を再起動してもssm-agentが起動しない状態

ログインが出来なくなった場合の対処方法としては大きく以下3つの対処方針があるかと思います。

  1. 新しいキーペアをOSに配置する
  2. 既存OSユーザのパスワードをリセットする
  3. 新しいOSユーザを作成する

本記事では上記対応の具体的な手順をご紹介します。

1.ユーザデータを利用する

利点:環境に依存せず実行ができる
欠点:インスタンスの停止が必要

EC2起動時に実行されるユーザデータを利用して、新しいキーペアをOSに配置します。

①新しいキーペアを作成する。

EC2のコンソールで新しいキーペアを作成します。

②新しく作成したキーペアのPublicKeyを取得する。

AWS CLI コマンドからパブリックキーマテリアルを取得する場合は、CloudShellから以下コマンドで取得可能です。

aws ec2 describe-key-pairs --key-names key-pair-name --include-public-key

key-pair-nameは作成したキーペア名に置き換えます。

③対象インスタンスを停止する。

④停止したインスタンスのユーザデータを編集する。

アクション > インスタンス設定 > ユーザーデータを編集から
以下を貼り付けます。

Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0

--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"

#cloud-config
cloud_final_modules:
- [users-groups, once]
users:
    - name: username
    ssh-authorized-keys:
    - PublicKeypair

usernamePublicKeypairはそれぞれユーザ名(ec2-userなど)と②で取得したPublicKeyに置き換えます。

⑤インスタンスを起動し、接続する。

インスタンス起動後、④で指定したユーザ名と②で作成したキーペアを利用してssh接続の確認をします。

⑥インスタンスを停止し、ユーザデータを削除する。

このままだと起動時に毎回ユーザデータが実行されるため、接続確認が取れた後にユーザデータを削除します。

2.Systems Manager を利用する

利点:インスタンス停止が不要
前提:SSM-Agentが導入され、正常に動作している必要がある

SSM-Agentがインストールされており、EC2に適切なIAMロールがアタッチされていれば、Systems Managerを利用した復旧も可能です。
SessionManagerを利用して、パスワードリセットや新しいユーザ作成などの対処が可能な場合は、それでも問題ありません。

ここでは、SSM Run Commandの AWS-RunShellScript を利用し、パスワードを設定した新ユーザを作成と、パスワード認証の有効化を同時に行い、パスワード認証でEC2にログインできるようにします。

①Systems MagagerのコンソールからRun Commandを選択する。

AWS-RunShellScriptを選択する。

コマンドドキュメントからAWS-RunShellScriptを検索しラジオボタンをクリックします。

③コマンドの実行

コマンドのパラメータcommands にコマンドを入力します。

useradd -G wheel USER
echo 'PASS' | passwd --stdin USER

sed -i 's/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
systemctl restart sshd

USERPASSはそれぞれユーザ名とパスワードに置き換えます。

④対象インスタンスを選択し、実行をクリックする。

オプションとして、ログ出力先やタイムアウトを設定することもできます。

⑤作成した新しいユーザでssh接続確認を行う。

⑥接続したユーザでリカバリが完了したら、必要に応じてパスワード認証を無効化する。

sed -i 's/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd

3.EC2 Instance Connect を利用する

利点:インスタンス停止が不要
前提:Instance Connect Agentが導入されている必要がある

EC2 Instance Connectが利用できるのであれば、それを利用した復旧も可能です。
ここでは新しいキーペアをOSに配置する方法を紹介していますが、OSに接続できるため、
新しいOSユーザを作成しても、既存OSユーザのパスワードをリセットしても問題ありません。

①新しいキーペアを作成する。

EC2のコンソールで新しいキーペアを作成します。

②新しく作成したキーペアのPublicKeyを取得する。

③対象インスタンスにInstance Connectで接続する。

④~/.ssh/authorized_keys ファイルを編集する。

新しいPublicKeyを書き込みます。

4.EC2シリアルコンソールを利用する

利点:インスタンス停止が不要
ネットワーク切断時も対応可能
前提:パスワードがわかるOSユーザが必要
NitroベースのEC2である必要がある
アカウントレベルでEC2シリアルコンソールを有効にする必要がある

①新しいキーペアを作成する。

EC2のコンソールで新しいキーペアを作成します。

②新しく作成したキーペアのPublicKeyを取得する。

③対象インスタンスにEC2シリアルコンソールで接続し、OSユーザでログインする。

④~/.ssh/authorized_keys ファイルを編集する。

新しいPublicKeyを書き込みます。

5.EBSのデタッチ&アタッチ

利点:環境に依存せず実行可能
欠点:インスタンスの停止が必要

対象のEC2のEBSを、レスキュー用に立てたEC2にアタッチし、新しいキーペアをOSに配置したあと、EBSを元のEC2にアタッチしなおします。

①新しいキーペアを作成する。

EC2のコンソールで新しいキーペアを作成します。

②新しく作成したキーペアのPublicKeyを取得する。

AWS CLI コマンドからパブリックキーマテリアルを取得する場合は、CloudShellから以下コマンドで取得可能です。 key-pair-nameは作成したキーペア名に置き換えます。

aws ec2 describe-key-pairs --key-names key-pair-name --include-public-key

③対象インスタンスを停止する。

④対象インスタンスのEBSをデタッチ。

⑤レスキュー用に新規インスタンスを作成し、④でデタッチしたEBSをアタッチする。

⑥レスキュー用インスタンスに接続し、アタッチしたEBSをマウントする。

⑦~/.ssh/authorized_keys ファイルを編集する。

新しいPublicKeyを書き込みます。

⑧レスキュー用インスタンスを停止し、EBSをデタッチする。

⑨元のインスタンスにEBSをアタッチし、起動する。

⑩新しいキーペアでの接続確認を行う。

⑪問題が無ければレスキュー用インスタンスを終了する。

まとめ

本記事では、EC2インスタンスにログインできなくなった際の対処方法について5つの手法を紹介しました。 それぞれの方法には、インスタンスの停止が必要かどうか、環境の前提条件など異なる特徴があります。

  1. ユーザデータを利用する
    インスタンスの停止が必要だが、環境に依存せず対応可能。
  2. Systems Manager を利用する
    インスタンスの停止は不要だが、SSM-Agentの導入が必要。
  3. EC2 Instance Connect を利用する
    インスタンスの停止は不要だが、Instance Connect Agentが導入が必要。
  4. EC2シリアルコンソールを利用する
    インスタンスの停止は不要、ネットワーク切断時でも対応可能だが、パスワードのわかるOSユーザが必要。前提としてNitroベースのEC2のみ対応可能。
  5. EBSのデタッチ&アタッチ
    インスタンスの停止が必要だが、環境に依存せず対応可能。手間がかかる。

各方法の前提条件を理解し、皆様の環境にあった方法で対応を把握しておくことが肝要かと思います。
もしトラブルが発生したときには迅速にリカバリができるよう、参考にしていただければ幸いです。

CTCは、AWSのビジネス利活用に向けて、お客様のステージに合わせた幅広い構築・運用支援サービスを提供しています。
経験豊富なエンジニアが、ワンストップかつ柔軟にご支援します。
ぜひ、お気軽にお問い合わせください。

お問い合わせ

【著者プロフィール】

須貝 祐太 (すがい ゆうた)

伊藤忠テクノソリューションズ株式会社 クラウドアーキテクト

オンプレミスの設計業務から構築業務に従事。現在はオンプレミス時代の経験を活用し、エンタープライズ向けのAWSプリセールス並びにAWS案件全般でお客様を支援するアーキテクトとして活躍中。
2023/2024 Japan AWS All Certifications Engineers

TOP>コラム一覧>EC2のLinuxサーバにログインできなくなったときの対処法

pagetop