对于Elastic Beanstalk环境，您可以像这样将键值对应用到正在运行的实例:

从EC2 ->密钥对(在网络和安全选项卡下)创建一个键值对 转到Elastic Beanstalk并单击您的应用程序 进入“配置->安全”，单击“编辑” 选择EC2密钥对并单击Apply 单击“确认”确认更新。它将终止环境并将键值应用到您的环境。

不能对正在运行的实例应用对偶。您只能使用新对来启动一个新实例。

对于恢复，如果它是EBS引导AMI，您可以停止它，创建卷的快照。基于它创建一个新卷。并且能够使用它来启动旧实例、创建新映像或恢复数据。

虽然暂时存储的数据将会丢失。

---

由于这个问题和答案的受欢迎程度，我想在Rodney在他的评论中发布的链接中捕获信息。

这一信息要归功于埃里克·哈蒙德。

修复EC2实例的根EBS卷上的文件

您可以在EC2实例上检查和编辑根EBS卷上的文件，即使处于您所认为的灾难性情况，如:

您丢失了ssh密钥或忘记了密码 您在编辑/etc/sudoers文件时犯了错误，不能再编辑了 使用sudo获得根访问权限来修复它 长期运行的实例由于某种原因挂起，不能挂起 联系，无法正常启动 您需要从实例中恢复文件，但无法访问它

在你办公桌上的一台物理计算机上，你可以简单地用CD或u盘启动系统，安装硬盘驱动器，签出并修复文件，然后重新启动计算机以恢复工作。

但是，当您处于其中一种情况时，远程EC2实例似乎很遥远且不可访问。幸运的是，AWS为我们提供了恢复这样的系统的能力和灵活性，前提是我们运行的是EBS引导实例而不是实例存储。

EC2上的方法有点类似于物理解决方案，但是我们将把有故障的“硬盘驱动器”(根EBS卷)移动并挂载到不同的实例，修复它，然后将它移回来。

在某些情况下，启动一个新的EC2实例并扔掉坏的实例可能更容易，但如果你真的想修复文件，这里有一种方法对许多人都有效:

设置

用要查看和编辑的文件标识包含损坏的根EBS卷的原始实例(A)和卷。

instance_a=i-XXXXXXXX

volume=$(ec2-describe-instances $instance_a |
  egrep '^BLOCKDEVICE./dev/sda1' | cut -f3)

确定第二个EC2实例(B)，您将使用它来修复原始EBS卷上的文件。此实例必须运行在与实例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

ssh到实例B并挂载卷，以便访问它的文件系统。

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/…

注意:这两个实例上的uid可能不相同，因此在创建、编辑或复制属于非根用户的文件时要小心。例如，实例A上的mysql用户可能与实例B上的postfix用户具有相同的UID，这可能会导致问题，如果您使用一个名称删除文件，然后将卷移回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时已为其分配了弹性IP地址，则需要在重新启动实例A后重新关联它。

记住!如果您的实例B只是为了这个进程而临时启动的，那么现在不要忘记终止它。

您可以通过以下命令向实例添加一个新密钥:

ssh-copy-id -i ~/.ssh/id_rsa.pub domain_alias

可以在~/目录下配置domain_alias。ssh配置

host domain_alias
  User ubuntu
  Hostname domain.com
  IdentityFile ~/.ssh/ec2.pem

在您的本地机器上，运行命令:

ssh-keygen -t rsa -C "SomeAlias"

运行该命令后，以*结尾的文件。将生成Pub。复制该文件的内容。

在Amazon机器上，编辑~/。Ssh /authorized_keys，并粘贴*. xml文件的内容。Pub文件(并首先删除任何现有内容)。

然后，您可以使用SSH -keygen命令生成的另一个文件(私钥)进行SSH。

我没有找到通过控制台添加新密钥对的简单方法，但您可以手动完成。

只需使用现有密钥对ssh进入EC2盒子。然后编辑~/。Ssh /authorized_keys并在新行中添加新密钥。通过新机器退出并ssh。成功!

我之前也遇到过这种情况(无法访问别人创建的EC2实例，但可以访问AWS web控制台)，我在博客上找到了答案:http://readystate4.com/2013/04/09/aws-gaining-ssh-access-to-an-ec2-instance-you-lost-access-to/

基本上，您可以分离EBS驱动器，将其连接到您可以访问的EC2。将您的SSH pub密钥添加到~ec2-user/。Ssh /authorized_keys。然后将其放回到旧的EC2实例上。使用Amazon AMI逐步链接。

不需要创建快照或创建新的克隆实例。