既存のEC2インスタンスにキーペアを追加する


239

AWSコンソールに、2つのインスタンスが実行されているアカウントへのアクセス権が与えられましたが、(本番環境では)シャットダウンできません。ただし、これらのインスタンスへのSSHアクセスを取得したいのですが、新しいキーペアを作成してインスタンスに適用し、SSHで接続できますか?現在、インスタンスが作成されたキーペアの既存のPEMファイルを取得することはできません。

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


ここで解決策を試しましたか:stackoverflow.com/questions/1454629/…ssh-add必要なことを行う必要があります。
Marc Bollinger、2010

ssh-add機能について学ぶのはいいですが、このユーザーは実際に、自分が作成したキーペアを使用してインスタンスを作成したため、役に立ちません。私が参照しているインスタンスは、アクセスできない別のキーペアで作成されました。
Chris Wagner

1
かもしれ方が良いにこの質問をしたいserverfault.com
クロードVedovini

4
実行中のインスタンスにキーペアを適用することはできません。
Rodney Quillo 2010

回答:


172

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

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

ただし、一時ストレージのデータは失われます。


この質疑応答の人気のため、ロドニーがコメントに投稿したリンクの情報をキャプチャしたいと思いました。

クレジットに行くエリック・ハモンドのために、この情報

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

EC2インスタンスのルートEBSボリューム上のファイルは、次のような悲惨な状況にあると考えている場合でも、調査および編集できます。

  • sshキーを紛失したか、パスワードを忘れました
  • / etc / sudoersファイルの編集を間違えたため、sudoでrootアクセスを取得して修正できなくなった
  • 長時間実行されているインスタンスが何らかの理由でハングし、接続できず、正しく起動できません
  • インスタンスからファイルを回復する必要がありますが、アクセスできません

机に座っている物理的なコンピューターで、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)を特定します。このインスタンスは、インスタンスAと同じアベイラビリティーゾーンで実行して、EBSボリュームを接続できるようにする必要があります。まだ実行中のインスタンスがない場合は、一時的なインスタンスを開始します。

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の下で表示および編集できるようになります。たとえば、次のようにすることができます。

  • /vol-a/home/ubuntu/.ssh/authorized_keysに正しいsshキーを配置します
  • / vol-a / etc / sudoersを編集して修正します
  • / vol-a / var / log / syslogでエラーメッセージを探します。
  • / vol-a /から重要なファイルをコピー…

注:2つのインスタンスのuidは同一ではない可能性があるため、非rootユーザーに属するファイルを作成、編集、またはコピーする場合は注意してください。たとえば、インスタンスAのmysqlユーザーはインスタンスBのpostfixユーザーと同じUIDを持っている可能性があり、1つの名前でファイルを変更してからボリュームを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が一時的に開始された場合は、ここで終了することを忘れないでください。


このための段階的なガイドを教えてもらえますか(またはポイントしてください)。私の場合、既存の実行中のインスタンスがあり、秘密鍵を持っていないリモートの場所からインスタンスにログインする必要があります。
Jus12

87

実行中のEC2インスタンスにキーペアを直接追加することはできませんが、Linuxユーザーを作成して新しいキーペアを作成し、元のユーザーのキーペアと同じように使用できます。

あなたの場合、インスタンスの所有者(作成者)に次のことを依頼することができます。したがって、インスタンス所有者は自分のキーをあなたと共有する必要はありませんが、これらのインスタンスにSSHで接続することができます。これらの手順は、もともとUtkarsh Sengar(別名。@zengr)によってhttp://utkarshsengar.com/2011/01/manage-multiple-accounts-on-1-amazon-ec2-instance/に投稿されました。ほんの少しの変更を加えました。

  1. ステップ1:デフォルトの「ubuntu」ユーザーでログインする

    $ ssh -i my_orig_key.pem ubuntu@111.111.11.111
    
  2. ステップ2:新しいユーザーを作成します。新しいユーザーを「john」と呼びます

    [ubuntu@ip-11-111-111-111 ~]$ sudo adduser 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. ステップ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. ステップ4:次に、「john」というキーをダウンロードする必要があります。私はscpを使用してEC2からファイルをダウンロード/アップロードします。これを行う方法を次に示します。

    そのユーザー名のキーしか持っていないため、ubuntuユーザーを使用してファイルをコピーする必要があります。したがって、キーをubuntuフォルダーに移動し、chmodで777に移動する必要があります。

    [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 ubuntu@111.111.11.111:/home/ubuntu/john john
    

    上記のコマンドは、キー「john」をローカルマシンの現在の作業ディレクトリにコピーします。鍵をローカルマシンにコピーしたら、「/ home / ubuntu / john」は秘密鍵なので削除する必要があります。

    ここで、ローカルマシンの1つであるchmod johnを600にします。

    $ chmod 600 john
    
  5. ステップ5:キーをテストする時間

    $ ssh -i john john@111.111.11.111
    

したがって、この方法で、1つのEC2インスタンスを使用するように複数のユーザーを設定できます。


4
これは便利ですが、最後のステップとして、リモートマシンの秘密キーも削除しないでください。インスタンスへのアクセス権を持つ他の人もそれをコピーし、ログインするためにあなたのキーを使用することはできませんこの方法。
culix

これは私にとってはうまくいきます。しかし、ここで作業するファイルはubuntuユーザーディレクトリにあるので、ここからubuntuユーザーに移動するにはどうすればよいですか。これにより、johnユーザーグループに移動します。Ubuntu 14.04.4 LTS
olyjosh 2017

これは私にはうまくいきませんでした。それは無効な権限を与えました。ec2コンソールからキーペアを作成する必要があり、それが機能し始めました
ダークナイト

11

ローカルマシンで、次のコマンドを実行します。

ssh-keygen -t rsa -C "SomeAlias"

このコマンドを実行すると、末尾が* .pubのファイルが生成されます。そのファイルの内容をコピーします。

Amazonマシンで、〜/ .ssh / authorized_keysを編集して* .pubファイルの内容を貼り付けます(最初に既存の内容を削除します)。

その後、ssh-keygenコマンドから生成された他のファイル(秘密鍵)を使用してSSHを実行できます。


したがって、@ Danが述べたように、このファイルを編集するインスタンスへのアクセスを変更することは可能ですが、メタデータレベルでインスタンスに関連付けられたキーペアを変更することはできません。publicKeyの最後に.pemファイル名を追加することを忘れないでください。例:ssh-rsa AAAAB3NzaC1yc2EA...DsGt66 my-key-pair
Ricardo Mutti

7

これは、以前の私に起こった(他の誰かが作成したが、AWSのWebコンソールへのアクセスを持っていたEC2インスタンスへのアクセス権を持っていなかった)と私は答えブログ: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 公開鍵を追加します。次に、それを古いEC2インスタンスに戻します。Amazon AMIを使用してリンクを段階的に説明します。

スナップショットを作成したり、新しい複製インスタンスを作成したりする必要はありません。


6

私の場合、このドキュメントを使用して、キーペアをElastic Beanstalkのインスタンスに関連付けました

重要

Elastic BeanstalkでプロビジョニングされたAmazon EC2インスタンスにアクセスする前に、Amazon EC2キーペアを作成し、Amazon EC2キーペアを使用するようにElastic BeanstalkでプロビジョニングされたAmazon EC2インスタンスを設定する必要があります。AWSマネジメントコンソールを使用して、Amazon EC2キーペアを設定できます。Amazon EC2のキーペアを作成する手順については、Amazon Elastic Compute Cloud入門ガイドを参照してください。

Elastic Beanstalkを使用したAmazon EC2サーバーインスタンスの設定


1
ありがとう、@ kamal-essajidi!EBを使用する他のユーザーの場合:キーペアを取得したら、[設定]> [インスタンス]> [EC2キーペア]でElastic Beanstalkに追加できます。
スコット

4

次のコマンドで、インスタンスに新しいキーを追加できます。

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

4

コンソールから新しいキーペアを追加する簡単な方法は見つかりませんでしたが、手動で追加できます。

既存のキーペアを使用してEC2ボックスにSSH接続するだけです。次に〜/ .ssh / authorized_keysを編集し、新しいキーを新しい行に追加します。新しいマシンで終了してsshします。成功!



2

Elasticbeanstalk環境の場合、次のようにキーと値のペアを実行中のインスタンスに適用できます。

  • EC2->キーペアからキーと値のペアを作成します([ネットワークとセキュリティ]タブの下)
  • Elasticbeanstalkに移動し、アプリケーションをクリックします
  • 構成ページに移動して、セキュリティ設定を変更します
  • EC2キーペアを選択し、[適用]をクリックします
  • 確認をクリックして更新を確認します。環境を終了し、キー値を環境に適用します。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.