シャットダウンできない 2 つのインスタンスが稼働しているアカウントへのAWSコンソール アクセスが付与されました(本番環境)。ただし、これらのインスタンスへの SSH アクセスを取得したいのですが、新しいキーペアを作成してインスタンスに適用し、SSH で接続することは可能ですか? インスタンスの作成に使用されたキーペアの既存のpemファイルを取得することは、現時点ではオプションではありません。
これが不可能な場合、インスタンスに入る他の方法はありますか?
ベストアンサー1
実行中のインスタンスにキーペアを適用することはできません。新しいキーペアは、新しいインスタンスを起動するためにのみ使用できます。
リカバリについては、EBS ブート AMI の場合は、それを停止し、ボリュームのスナップショットを作成できます。それに基づいて新しいボリュームを作成します。そして、それを使用して古いインスタンスを起動したり、新しいイメージを作成したり、データをリカバリしたりできるようになります。
ただし、一時ストレージのデータは失われます。
この質問と回答は人気があったため、ロドニーがコメントに投稿したリンクの情報を取り込もうと思いました。
EC2 インスタンスのルート EBS ボリューム上のファイルの修正
次のような悲惨な状況にある場合でも、EC2 インスタンスのルート EBS ボリューム上のファイルを調べて編集できます。
- SSHキーを紛失したか、パスワードを忘れました
- /etc/sudoersファイルの編集を間違えたため、sudoでルートアクセスできなくなり、修正できなくなりました。
- 長時間実行中のインスタンスが何らかの理由でハングし、接続できず、正常に起動できない
- インスタンスからファイルを回復する必要があるが、アクセスできない
デスクに置かれた物理的なコンピューターでは、CD または USB スティックを使用してシステムを起動し、ハード ドライブをマウントし、ファイルをチェックアウトして修正し、コンピューターを再起動するだけで、作業を再開できます。
ただし、このような状況では、リモート EC2 インスタンスは遠く離れており、アクセスできないように見えます。幸いなことに、インスタンス ストアではなく EBS ブート インスタンスを実行している限り、AWS はこのようなシステムを回復できるパワーと柔軟性を提供します。
EC2 でのアプローチは物理的なソリューションと多少似ていますが、障害のある「ハードドライブ」(ルート EBS ボリューム) を別のインスタンスに移動してマウントし、修復してから元に戻します。
状況によっては、新しい EC2 インスタンスを起動して問題のあるインスタンスを破棄する方が簡単な場合もありますが、本当にファイルを修正したい場合は、多くの場合に有効なアプローチを次に示します。
設定
表示および編集するファイルを含む、破損したルート EBS ボリュームを含む元のインスタンス (A) とボリュームを特定します。
instance_a=i-XXXXXXXX
volume=$(ec2-describe-instances $instance_a |
egrep '^BLOCKDEVICE./dev/sda1' | cut -f3)
元の EBS ボリューム上のファイルを修正するために使用する 2 番目の EC2 インスタンス (B) を特定します。このインスタンスは、EBS ボリュームを接続できるように、インスタンス A と同じアベイラビリティーゾーンで実行されている必要があります。まだインスタンスが実行されていない場合は、一時的なインスタンスを起動します。
instance_b=i-YYYYYYYY
壊れたインスタンス A を停止し (完全に停止するまで待機)、インスタンスからルート EBS ボリュームをデタッチし (デタッチされるまで待機)、未使用のデバイス上のインスタンス B にボリュームをアタッチします。
ec2-stop-instances $instance_a
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_b --device /dev/sdj $volume
インスタンス B に ssh し、ボリュームをマウントして、そのファイル システムにアクセスできるようにします。
ssh ...instance b...
sudo mkdir -p 000 /vol-a
sudo mount /dev/sdj /vol-a
修理する
この時点で、インスタンス A のルート ファイル システム全体をインスタンス B の /vol-a で表示および編集できるようになります。たとえば、次の操作を実行できます。
- 正しいsshキーを/vol-a/home/ubuntu/.ssh/authorized_keysに置きます
- /vol-a/etc/sudoersを編集して修正する
- /vol-a/var/log/syslogでエラーメッセージを探す
- 重要なファイルを /vol-a/ からコピーします…
注意: 2 つのインスタンスの uid は同一ではない可能性があります。そのため、非ルート ユーザーに属するファイルを作成、編集、またはコピーする場合は注意してください。たとえば、インスタンス A の mysql ユーザーがインスタンス B の postfix ユーザーと同じ UID を持つ場合、ある名前でファイルを chown してからボリュームを A に戻すと問題が発生する可能性があります。
まとめ
完了し、/vol-a の下のファイルに満足したら、ファイル システムをアンマウントします (まだインスタンス B 上)。
sudo umount /vol-a
sudo rmdir /vol-a
次に、ec2-api-tools を使用してシステムに戻り、EBS ボリュームを元のインスタンス A のホームに戻し、インスタンスを再起動します。
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_a --device /dev/sda1 $volume
ec2-start-instances $instance_a
うまくいけば、問題は解決し、インスタンス A は問題なく起動し、当初の目的を達成できます。そうでない場合は、正常に動作するまでこれらの手順を繰り返す必要がある場合があります。
注意: インスタンス A を停止したときに Elastic IP アドレスが割り当てられていた場合は、再起動後に再度関連付ける必要があります。
覚えておいてください! インスタンス B がこのプロセスのためだけに一時的に起動された場合は、今すぐ終了することを忘れないでください。