(実稼働中に)シャットダウンできない2つのインスタンスが実行されているアカウントへのAWSコンソールアクセスが与えられました。ただし、これらのインスタンスへのSSHアクセスを取得したいのですが、新しいキーペアを作成し、インスタンスに適用してSSHで接続することは可能ですか?インスタンスが作成されたキーペアの既存のpemファイルを取得することは、現在オプションではありません。
これが不可能な場合、インスタンスにアクセスできる他の方法はありますか?
実行中のインスタンスにキーペアを適用することはできません。新しいインスタンスを起動するためにのみ新しいキーペアを使用できます。
回復のために、それがEBSブートAMIである場合、それを停止し、ボリュームのスナップショットを作成できます。それに基づいて新しいボリュームを作成します。また、それを使用して、古いインスタンスを起動したり、新しいイメージを作成したり、データを回復したりできます。
一時ストレージのデータは失われますが。
この質問と回答の人気のため、ロドニーが彼のコメントに投稿したリンクの情報をキャプチャしたかったです。
クレジットは Eric Hammond for this information になります。
次のような悲惨な状況と考えられる状況にある場合でも、EC2インスタンスのルートEBSボリューム上のファイルを調べて編集できます。
机に座っている物理コンピューターで、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の下で表示および編集できるようになります。たとえば、次のようにできます。
注:2つのインスタンスのuidは同一ではない可能性があるため、非rootユーザーに属するファイルを作成、編集、またはコピーする場合は注意してください。たとえば、インスタンス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がこのプロセスのために一時的に開始された場合は、今すぐ終了することを忘れないでください。
実行中のEC2インスタンスにキーペアを直接追加することはできませんが、Linuxユーザーを作成し、そのユーザー用に新しいキーペアを作成してから、元のユーザーのキーペアと同じように使用できます。
この場合、インスタンスの所有者(作成者)に次のことを依頼できます。したがって、インスタンスの所有者は自分のキーを共有する必要はありませんが、これらのインスタンスにsshすることはできます。これらのステップは、元々Utkarsh Sengar(別名。 @ zengr ) http://utkarshsengar.com/2011/01/manage-multiple-accounts-on-1-Amazon-によって投稿されました。 ec2-instance / 。ほんのわずかな変更を加えました。
ステップ1:デフォルトでログイン「ubuntu」ユーザー:
$ ssh -i my_orig_key.pem [email protected]
ステップ2:新しいユーザーを作成し、新しいユーザーを「john」と呼びます:
[ubuntu@ip-11-111-111-111 ~]$ Sudo adduser john
「john」のパスワードを設定するには:
[ubuntu@ip-11-111-111-111 ~]$ Sudo su -
[root@ip-11-111-111-111 ubuntu]# passwd john
「john」をsudoerのリストに追加します:
[root@ip-11-111-111-111 ubuntu]# visudo
..そして、ファイルの最後に次を追加します。
john ALL = (ALL) ALL
よし!新しいユーザーを作成しました。ステップ1でmy_orin_key.pemがあるように、ログインに必要なキーファイルを生成する必要があります。
ここで、終了して、ルートからubuntuに戻ります。
[root@ip-11-111-111-111 ubuntu]# exit
[ubuntu@ip-11-111-111-111 ~]$
ステップ3:公開鍵と秘密鍵の作成:
[ubuntu@ip-11-111-111-111 ~]$ su john
手順2で「john」用に作成したパスワードを入力します。次に、キーペアを作成します。キーペアのパスフレーズは少なくとも4文字にする必要があることに注意してください。
[john@ip-11-111-111-111 ubuntu]$ cd /home/john/
[john@ip-11-111-111-111 ~]$ ssh-keygen -b 1024 -f john -t dsa
[john@ip-11-111-111-111 ~]$ mkdir .ssh
[john@ip-11-111-111-111 ~]$ chmod 700 .ssh
[john@ip-11-111-111-111 ~]$ cat john.pub > .ssh/authorized_keys
[john@ip-11-111-111-111 ~]$ chmod 600 .ssh/authorized_keys
[john@ip-11-111-111-111 ~]$ Sudo chown john:ubuntu .ssh
上記の手順で、johnは作成したユーザーで、ubuntuはデフォルトのユーザーグループです。
[john@ip-11-111-111-111 ~]$ Sudo chown john:ubuntu .ssh/authorized_keys
ステップ4:「john」というキーをダウンロードするだけです。 scpを使用してEC2からファイルをダウンロード/アップロードします。これを行う方法を次に示します。
ubuntuuserを使用してファイルをコピーする必要があります。これは、そのユーザー名のキーしか持っていないためです。そのため、キーをubuntuフォルダに移動し、777にchmodする必要があります。
[john@ip-11-111-111-111 ~]$ Sudo cp john /home/ubuntu/
[john@ip-11-111-111-111 ~]$ Sudo chmod 777 /home/ubuntu/john
次に、my_orig_key.pemファイルがあるローカルマシンのターミナルにアクセスして、次の操作を行います。
$ cd ~/.ssh
$ scp -i my_orig_key.pem [email protected]:/home/ubuntu/john john
上記のコマンドは、キー「john」をローカルマシンの現在の作業ディレクトリにコピーします。キーをローカルマシンにコピーしたら、「/ home/ubuntu/john」を削除する必要があります。これは秘密キーであるためです。
ここで、ローカルマシンchmod johnを600に変更します。
$ chmod 600 john
ステップ5:キーをテストする時間:
$ ssh -i john [email protected]
したがって、この方法で、1つのEC2インスタンスを使用するように複数のユーザーをセットアップできます!!
ローカルマシンで、次のコマンドを実行します。
ssh-keygen -t rsa -C "SomeAlias"
そのコマンドの実行後、*。pubで終わるファイルが生成されます。そのファイルの内容をコピーします。
Amazonマシンで〜/ .ssh/authorized_keysを編集し、*。pubファイルの内容を貼り付けます(そして既存の内容を最初に削除します)。
その後、ssh-keygenコマンド(秘密鍵)から生成された他のファイルを使用してSSHできます。
これは以前に私に起こり(他の人が作成したEC2インスタンスにはアクセスできなかったが、AWSウェブコンソールにはアクセスできました)、私は答えをブログに書きました: http://readystate4.com/2013/04/09/ aws-gaining-ssh-access-to-an-ec2-instance-you-lost-access-to /
基本的に、EBSドライブを取り外して、アクセスできるEC2に接続できます。この接続されたドライブの~ec2-user/.ssh/authorized_keys
にSSH pubキーを追加します。次に、古いEC2インスタンスに戻します。 Amazon AMIを使用したリンクのステップバイステップ。
スナップショットを作成したり、新しいクローンインスタンスを作成したりする必要はありません。
私の場合、このドキュメントを使用してキーペアをElastic Beanstalkのインスタンスに関連付けました
重要
Elastic BeanstalkでプロビジョニングされたAmazon EC2インスタンスにアクセスする前に、Amazon EC2キーペアを作成し、Amazon EC2キーペアを使用するようにElastic BeanstalkでプロビジョニングされたAmazon EC2インスタンスを設定する必要があります。 AWSマネジメントコンソールを使用して、Amazon EC2キーペアを設定できます。 Amazon EC2のキーペアを作成する手順については、Amazon Elastic Compute Cloud入門ガイドを参照してください。
コンソールから新しいキーペアを追加する簡単な方法は見つかりませんでしたが、手動で追加できます。
既存のキーペアでEC2ボックスにsshするだけです。次に、〜/ .ssh/authorized_keysを編集し、新しい行に新しいキーを追加します。新しいマシンで終了してsshします。成功!
次のコマンドにより、インスタンスに新しいキーを追加するだけです。
ssh-copy-id -i ~/.ssh/id_rsa.pub domain_alias
〜/ .ssh configでdomain_aliasを設定できます
Host domain_alias
User ubuntu
Hostname domain.com
IdentityFile ~/.ssh/ec2.pem
インスタンスが開始されると、メタデータレベルでインスタンスに関連付けられたキーペアを変更する方法はありませんが、インスタンスへの接続に使用するsshキーを変更できます。
stackoverflow.com/questions/7881469/change-key-pair-for-ec2-instance