[解決済み】既存のEC2インスタンスにキーペアを追加する。

質問

私は、以下のものを受け取りました。 AWS 私はシャットダウンすることができない2つのインスタンスが実行されているアカウントへのコンソールアクセス（実稼働中）。しかし、私はこれらのインスタンスにSSHアクセスしたいのですが、新しいキーペアを作成し、それをインスタンスに適用してSSHアクセスできるようにすることは可能でしょうか？既存の pem ファイルは、現在のところ、オプションではありません。

これが不可能な場合、インスタンスにアクセスするための他の方法はありますか？

解決方法は？

実行中のインスタンスにキーペアを適用することはできません。新しいキーペアは、新しいインスタンスを起動するときにのみ使用することができます。

リカバリの場合、EBSブートAMIであれば、停止してボリュームのスナップショットを作成することができます。それを元に新しいボリュームを作成します。そして、それを使って古いインスタンスを起動したり、新しいイメージを作成したり、データを回復したりすることができます。

エフェメラルストレージのデータは失われますが。

この質問と回答は人気があるため、Rodneyがコメントに投稿したリンクに情報を取り込みたかったのです。

クレジット表記は エリック・ハモンド について この情報 .

EC2インスタンスのルートEBSボリューム上のファイルを修正する

EC2インスタンスのルートEBSボリューム上のファイルは、以下のような悲惨な状況に陥っていても、調査・編集することができます。

• sshキーを紛失した、またはパスワードを忘れた場合
• etc/sudoersファイルの編集を間違えて、/etc/sudoersが使えなくなった。 sudo で root 権限を取得し、修正する
• 長時間稼働していたインスタンスが何らかの理由でハングアップしてしまい コンタクトが取れない、正常に起動しない
• インスタンスからファイルをリカバリする必要があるが、インスタンスにアクセスできない。

デスクにある物理的なコンピューターでは、CDやUSBメモリでシステムを起動し、ハードディスクをマウントしてファイルをチェックアウトして修正し、コンピューターを再起動すれば元通りになります。

しかし、遠隔地にあるEC2インスタンスは、このような状況に陥ったとき、遠くてアクセスできないように思われます。幸いなことに、AWSは、インスタンスストアではなくEBSブートインスタンスを実行していれば、このようなシステムをリカバリできるパワーと柔軟性を提供してくれています。

EC2でのアプローチは、物理的なソリューションと多少似ていますが、障害のある「ハードドライブ」（ルートEBSボリューム）を別のインスタンスに移動してマウントし、それを修正してから元に戻します。

状況によっては、新しいEC2インスタンスを起動して不良インスタンスを捨てる方が簡単な場合もありますが、本当にファイルを修正したいのであれば、多くの人がうまくいった方法を紹介します。

セットアップ

元のインスタンス（A）と、表示および編集したいファイルがある壊れたルートEBSボリュームを含むボリュームを特定します。

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は同一でない場合があります。したがって、非rootユーザーのファイルを作成、編集、コピーする場合は注意してください。例えば、インスタンス A の mysql ユーザーとインスタンス B の postfix ユーザーが同じ UID を持っている可能性があり、一方の名前でファイルを chown した後、ボリュームを A に戻すと問題が発生する可能性があります。

まとめ

vol-aの下のファイルを確認したら、ファイルシステムをアンマウントします（まだinstance-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を一時的に起動した場合は、忘れずに終了させてください。