ForgeVision Engineer Blog

フォージビジョン エンジニア ブログ

AWSSupport-ResetAccess で Linux インスタンスの SSH 接続を復旧

こんばんは。

夜な夜な失礼します、気になったらいつでもトライしてしまう我慢ができない尾谷です。
(夜な夜なトイレが我慢できずに起きてしまう初老でもありますが。。)

本日 (01/23) の定時後に 「AWS Expert Online for JAWS-UG #25 運用を効率化するためのAWS Systems Manager Automationの紹介」を拝見しました。

jawsugosaka.doorkeeper.jp

ランブックの紹介コーナーで「秘密鍵が分からなくなって SSH ログインできなくなったインスタンスの復旧方法」を紹介されていました。

(失礼ながら) お風呂に入りながら視聴させていただいていたので、メモが取れておらず多分「AWSSupport-ResetAccess」だったと思います。
このランブックの存在は別のセッションでお聞きして以前から知っていましたが試したことはありませんでしたので、風呂上がりのマミーをちびちび呑みながら試してみます。

EC2 インスタンスを起動

最近、自分の中で流行っている c6g.medium を使って EC2 インスタンスを選択しまして

鍵は思い切って「なし」を選択しました。

鍵なしにしてみます

パブリック IP アドレスを有効化して、SSM のロールをアタッチしました。

AWS Systems Manager

Systems Manager のフリートマネージャーにインスタンスが出現しました。

オートメーションから、AWS 所有の AWSSupport-ResetAccess を選択しました。

説明文に以下が記載されています。

This document will use the EC2Rescue tool on the specified EC2 instance to re-enable password decryption via the EC2 Console (Windows), or to generate and add a new SSH key pair (Linux). If you lost your key pair, this automation will create a password-enabled AMI that you can use to launch a new EC2 instance with a key pair you own (Windows).

このドキュメントは、指定した EC2 インスタンスで EC2Rescue ツールを使用して、EC2 コンソール経由でパスワード復号化を再有効化するか(Windows)、新しい SSH キーペアを生成して追加します(Linux)。 鍵ペアを紛失した場合、このオートメーションではパスワードが有効の AMI を作成し、所有している鍵ペアで新しい EC2 インスタンスを起動するのに使用します(Windows)。

Linux の場合は、EC2Rescue ツールという謎のツールを使って、新しい SSH キーペアを生成して追加してくれるようです。

入力パラメータ

入力パラメータは以下がありましたが、とりあえずインスタンス ID だけ指定してランブックを実行しました。

  • InstanceId (必須)
    アクセスをリセットする EC2 インスタンスの ID を入力します。
    重要: AWS Systems Manager Automation はこのインスタンスを停止し、操作を試みる前に AMI を作成します。インスタンスストアボリュームに保存されたデータは失われます。Elastic IP を使用していない場合、パブリック IP アドレスは変更されます。

  • SubnetId (オプション)
    EC2Rescue ツールを起動するサブネット ID を指定します。
    デフォルトでは、AWS Systems Manager Automation は新しい VPC を作成します。
    または、SelectedInstanceSubnet を使用してインスタンスと同じサブネットを使用するか、カスタムサブネット ID を指定します。
    重要: サブネットは InstanceId と同じアベイラビリティーゾーンにある必要があり、SSM エンドポイントへのアクセスを許可する必要があります。

  • EC2RescueInstanceType (必須)
    EC2Rescue ツールの EC2 インスタンスタイプ。推奨サイズ:t2.small。

  • AssumeRole (オプション)
    本ドキュメントを実行する IAM ロール。ロールが指定されていない場合、AWS Systems Manager Automation は、このドキュメントを実行するユーザーのアクセス許可を使用します。

動作確認

1. assertInstanceIsWindows (約 0 分)

AWSSupport-StartEC2RescueWorkflow を呼び出し、EC2Rescue for Windows を利用してオフラインパスワードリセットスクリプトを実行する。

一発目から失敗の文字が表示されて焦りましたが、assertInstanceIsWindows と記載があるので Linux はエラーになって問題なさそうです。

2. runEC2RescueForLinux (約 12 分)

ネストされたオートメーションからバックアップの AMI ID を取得する。

ここがメインの処理のようです。
まず、VPC が起動しました。

t3.small のインスタンス「AWSSupport-EC2Rescue: i-xxxxxxxxx」が起動していました。
どうやら、これが先ほど謎になっていた EC2Rescue ツール (インスタンス) のようです。

マシンイメージの作成に時間がかかっていた印象です。

3. getLinuxBackupAmi (約 0 分)

ネストされたオートメーションからパスワード付きの AMI ID を取得する。

以下、一瞬で終わりました。

Output には、ImageId: ami-0902e4d9efc0xxxxx が出力されていました。

4. getLinuxSSHKeyParameter (約 0 分)

注入された SSH 鍵の SSM パラメータ名を取得する。

chroot が失敗していました。

Locating rescue device
Mounting rescue volume /dev/nvme1n1p1
'/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.6/ec2rl'
Generating new key pair
Starting chroot
Error: execution failure inside chroot environment.
================================================================================
The EC2Rescue execution did not complete successfully.
'/mnt/mount/etc/resolv.conf.back' -> '/mnt/mount/etc/resolv.conf'
umount: /mnt/mount/sys (sysfs) unmounted
umount: /mnt/mount/dev/pts (devpts) unmounted
umount: /mnt/mount/dev/pts (devpts) unmounted
umount: /mnt/mount/dev/shm (tmpfs) unmounted
umount: /mnt/mount/dev (devtmpfs) unmounted
umount: /mnt/mount/proc (/proc) unmounted
umount: /mnt/mount (/dev/nvme1n1p1) unmounted

----------ERROR-------
rm: cannot remove '/mnt/mount/usr/bin/ec2rl': No such file or directory
chroot: failed to run command '/bin/bash': Exec format error

5. getEC2RescueForLinuxResult (約 0 分)

ネストしたオートメーションから EC2Rescue のサマリーを取得する。

こちらも上記 4 と同じエラーが発生していました。 なお、5 の処理のときには既に VPC が無くなっており、EC2 インスタンスも終了済みになっていました。

これ以降の処理は「処理中」となったままで分かりづらかったのですが、完了しておりました。

接続確認

AMI から再度インスタンスを起動したところ、再設定した鍵で SSH ログインができました。 エラーが複数出て不安になるものの、キーペアの修復は成功したようです。

元のインスタンス (35.72.4.12)

% ssh -i Downloads/keypair/ot_test_key.pem ec2-user@35.72.4.12
The authenticity of host '35.72.4.12 (35.72.4.12)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxx
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '35.72.4.12' (ED25519) to the list of known hosts.
ec2-user@35.72.4.12: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
%

復旧したインスタンス (18.181.191.44)

% ssh -i Downloads/keypair/ot_test_key.pem ec2-user@18.181.191.44
The authenticity of host '18.181.191.44 (18.181.191.44)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '18.181.191.44' (ED25519) to the list of known hosts.

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

https://aws.amazon.com/amazon-linux-2/
7 package(s) needed for security, out of 8 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-172-16-0-157 ~]$ 

まとめ

AWSSupport-ResetAccess は EC2 インスタンスのインスタンス ID さえ入力すれば、キーペアを再び設定できる AMI が作成されると理解しました。

インスタンスに SSH ができない問題は、セッションマネージャーで代用できる機会が多くそれほど緊急性は感じませんでしたが、約 12 分程度で復旧できるのは魅力的でした。

本セッションはかなりボリューミーで気になるトピックが多々ありました。
機会をみてまた投稿したいと思います。

最後までお読みくださりありがとうございました。