EC2インスタンスにログインできなくなったら……。〜Linux編〜

はじめに

こんにちは、望月です。

キーペアの管理をしっかりしてますか?担当者が変わり、行方不明になっていませんか?

実際にそのようなことにならないよう、しっかりと管理運用をしていきたいところですが、万が一、キーペアを紛失してしまって、EC2 にログインできなくなった場合、AWS Systems Managerを有効にしていれば、新しい SSH キーを生成できるらしいのでやってみました。

今回は Linux でやってみましたが、Windows でも同じようにローカル管理者パスワードの生成ができるらしいので、こちらも別途試してみたいと思います。

やってみた

キーペアなしでインスタンス作成

キーペアを紛失した状況を作るため、インスタンスをキーペアなしで作成しました。

もちろん、インスタンスへのログインは行なえません。

$ ssh ec2-user@<global IP>
Warning: Permanently added '<global IP>' (ECDSA) to the list of known hosts.
ec2-user@<global IP>: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Systems Managerの有効化

ポリシー「AmazonEC2RoleforSSM」を割り当てたIAMロールを、インスタンスに割り当てます。

「EC2 サービスページ」→「マネージドインスタンス」を確認し、IAMロールを割り当てたインスタンスが表示されることを確認しましょう。

※エージェントにリトライ間隔で表示されない可能性もあるので、表示されない場合は再起動を行いましょう。

ドキュメントの実行

Systems Managerのサービスページから、オートメーションを選択します。

下記ドキュメントを選択し、ドキュメントのバージョンはそのままで「次へ」をクリックします。

  • ドキュメント名:AWSSupport-ResetAccess

入力パラメーターに以下を入力し、「実行」をクリックします。

  • SubnetId
    • 対象インスタンスと同じAZの既存VPCのサブネットを指定します
      • SSMエンドエンドポイントへ通信できるサブネットであること
    • デフォルトでは新しいVPCを作成する設定となっています
  • InstanceId
    • ログインできなくなったインスタンスIDを指定します
  • EC2RescueInstanceType
    • レスキュー用に一時的に立ち上がるインスタンスのタイプを指定します
  • AssumeRole

しばらくし、実行ステータスが「成功」になったことを確認します。

SSHプライベートキーの確認

パラメータストアを確認すると、SSHプライベートキーが保存されているのが確認できます。

SecureStringで保存されているため、値の「Show」をクリックし、中身を表示します。

SSH ログインする

パラメータストアに保存されたSSHプライベートキーを使い、キーペアを紛失したインスタンスにログインできるようになったことを確認します。

$ vim ec2recovy.pem
<パラメータストアに保存されたSSHプライベートキーを記載>

$ chmod 600 ec2recovy.pem

$ ssh -i ec2recovy.pem ec2-user@<public IP>
Warning: Permanently added '<public IP>' (ECDSA) to the list of known hosts.
Last login: Thu May 30 11:45:48 2019 from fs276ec90a.tkyc004.ap.nuro.jp

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

https://aws.amazon.com/amazon-linux-2/
1 package(s) needed for security, out of 1 available
Run "sudo yum update" to apply all updates.

出力されたログをみる

出力されたログの一部を見てみると、レスキュー用に立ち上げたインスタンスにログインできないインスタンスのEBSをマウントし、鍵の再設定をしているみたいです。

この方法は手動でも実行可能な手段で、それをSSMで自動化したという感じですね。

getEC2RescueForLinuxResult.Output
Locating rescue device
Mounting rescue volume /dev/xvdf1
'/mnt/mount/etc/resolv.conf' -> '/mnt/mount/etc/resolv.conf.back'
'/etc/resolv.conf' -> '/mnt/mount/etc/resolv.conf'
'/mnt/mount/usr/bin/ec2rl' -> '/usr/local/ec2rl-1.1.4/ec2rl'
Generating new key pair
Starting chroot
Running EC2 Rescue for Linux

EBSをマウントしているということは暗号化したEBSを使ってるとうまく動かさそうだなと思い、EBSの暗号化が簡単になった(下記ブログを参照)こともあり、試してみましたがやはり失敗しました。

[アップデート] これは簡単!EC2 起動時にルートボリュームを1ステップで暗号化できるようになりました!

まとめ

このようにユーザーが頑張っていた部分がどんどんSSMで自動化されていくのは、大変うれしいですね。

もし、Systems Managerを有効化していない場合は、ぜひ有効化を検討しましょう!!!

また、この方法ではSSHプライベートキーがパラメータストアに保存されますが、ファイルでSSHプライベートキーを管理せずに、パラメータストアで管理するのも良さそうだなと感じました。