将密钥对添加到现有 EC2 实例 [英] Add Keypair to existing EC2 instance
问题描述
我获得了 AWS 控制台访问权限，该帐户有 2 个正在运行的实例，但我无法关闭(生产中).但是，我想获得对这些实例的 SSH 访问权限，是否可以创建一个新的密钥对并将其应用于实例以便我可以通过 SSH 进入?获取现有的 pem 文件用于创建实例的密钥对，目前不是一种选择.
I was given AWS Console access to an account with 2 instances running that I cannot shut down (in production). I would, however, like to gain SSH access to these instances, is it possible to create a new Keypair and apply it to the instances so I can SSH in? Obtaining the existing pem file for the keypair the instances were created under is currently not an option.
如果这是不可能的，我可以通过其他方式进入实例吗?
If this isn't possible is there some other way I can get into the instances?
推荐答案
您不能将密钥对应用于正在运行的实例.您只能使用新密钥对启动新实例.
You can't apply a keypair to a running instance. You can only use the new keypair to launch a new instance.
对于恢复，如果它是 EBS 启动 AMI，您可以停止它，制作卷的快照.基于它创建一个新卷.并且能够使用它来启动旧实例、创建新映像或恢复数据.
For recovery, if it's an EBS boot AMI, you can stop it, make a snapshot of the volume. Create a new volume based on it. And be able to use it back to start the old instance, create a new image, or recover data.
虽然临时存储中的数据会丢失.
Though data at ephemeral storage will be lost.
由于这个问题和答案很受欢迎，我想获取 Rodney 在评论中发布的链接中的信息.
您可以检查和编辑 EC2 实例上根 EBS 卷上的文件，即使您处于您认为的灾难性情况，例如:
You can examine and edit files on the root EBS volume on an EC2 instance even if you are in what you considered a disastrous situation like:
- 您丢失了 ssh 密钥或忘记了密码
- 您在编辑/etc/sudoers 文件时犯了一个错误，无法再使用 sudo 获得 root 访问权限以修复它
- 您的长时间运行的实例由于某种原因挂起，不能已联系，但无法正常启动
- 您需要从实例中恢复文件，但无法访问它
在办公桌前的物理计算机上，您只需使用 CD 或 U 盘启动系统，安装硬盘驱动器，检查并修复文件，然后重新启动计算机即可恢复工作.
On a physical computer sitting at your desk, you could simply boot the system with a CD or USB stick, mount the hard drive, check out and fix the files, then reboot the computer to be back in business.
然而，当您处于这些情况之一时，远程 EC2 实例似乎遥不可及且无法访问.幸运的是，AWS 为我们提供了能够恢复这样的系统的能力和灵活性，前提是我们运行的是 EBS 启动实例而不是实例存储.
A remote EC2 instance, however, seems distant and inaccessible when you are in one of these situations. Fortunately, AWS provides us with the power and flexibility to be able to recover a system like this, provided that we are running EBS boot instances and not instance-store.
EC2 上的方法有点类似于物理解决方案，但我们要将有故障的硬盘驱动器"(根 EBS 卷)移动并安装到不同的实例，修复它，然后将其移回.
The approach on EC2 is somewhat similar to the physical solution, but we’re going to move and mount the faulty "hard drive" (root EBS volume) to a different instance, fix it, then move it back.
在某些情况下，启动一个新的 EC2 实例并丢弃坏的实例可能更容易，但如果您真的想修复文件，以下方法对许多人都有效:
In some situations, it might simply be easier to start a new EC2 instance and throw away the bad one, but if you really want to fix your files, here is the approach that has worked for many:
设置
识别包含损坏的根 EBS 卷以及您要查看和编辑的文件的原始实例 (A) 和卷.
Identify the original instance (A) and volume that contains the broken root EBS volume with the files you want to view and edit.
instance_a=i-XXXXXXXX
volume=$(ec2-describe-instances $instance_a |
egrep '^BLOCKDEVICE./dev/sda1' | cut -f3)
确定您将用于修复原始 EBS 卷上的文件的第二个 EC2 实例 (B).此实例必须与实例 A 在同一可用区中运行，以便它可以将 EBS 卷附加到它.如果您还没有正在运行的实例，请启动一个临时实例.
Identify the second EC2 instance (B) that you will use to fix the files on the original EBS volume. This instance must be running in the same availability zone as instance A so that it can have the EBS volume attached to it. If you don’t have an instance already running, start a temporary one.
instance_b=i-YYYYYYYY
停止损坏的实例 A(等待它完全停止)，从实例分离根 EBS 卷(等待它分离)，然后将该卷附加到未使用设备上的实例 B.
Stop the broken instance A (waiting for it to come to a complete stop), detach the root EBS volume from the instance (waiting for it to be detached), then attach the volume to instance B on an unused device.
ec2-stop-instances $instance_a
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_b --device /dev/sdj $volume
ssh 到实例 B 并挂载卷，以便您可以访问其文件系统.
ssh to instance B and mount the volume so that you can access its file system.
ssh ...instance b...
sudo mkdir -p 000 /vol-a
sudo mount /dev/sdj /vol-a
修复它
此时，您可以在实例 B 的/vol-a 下查看和编辑来自实例 A 的整个根文件系统.例如，您可能想要:
At this point your entire root file system from instance A is available for viewing and editing under /vol-a on instance B. For example, you may want to:
- 将正确的 ssh 密钥放入/vol-a/home/ubuntu/.ssh/authorized_keys
- 编辑和修复/vol-a/etc/sudoers
- 在/vol-a/var/log/syslog 中查找错误消息
- 从/vol-a/...复制重要文件
注意:两个实例上的 uid 可能不相同，因此在创建、编辑或复制属于非 root 用户的文件时要小心.例如，您在实例 A 上的 mysql 用户可能与您在实例 B 上的 postfix 用户具有相同的 UID，如果您使用同一个名称 chown 文件然后将卷移回 A，这可能会导致问题.
总结
在您完成并对/vol-a 下的文件感到满意后，卸载文件系统(仍在实例 B 上):
After you are done and you are happy with the files under /vol-a, unmount the file system (still on instance-B):
sudo umount /vol-a
sudo rmdir /vol-a
现在，使用 ec2-api-tools 返回您的系统，继续将 EBS 卷移回原始实例 A 上的位置，然后再次启动该实例:
Now, back on your system with ec2-api-tools, continue moving the EBS volume back to it’s home on the original instance A and start the instance again:
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_a --device /dev/sda1 $volume
ec2-start-instances $instance_a
希望你解决了问题，实例 A 出现得很好，你可以完成你最初打算做的事情.如果没有，您可能需要继续重复这些步骤，直到它起作用为止.
Hopefully, you fixed the problem, instance A comes up just fine, and you can accomplish what you originally set out to do. If not, you may need to continue repeating these steps until you have it working.
注意:如果您在停止实例 A 时为其分配了弹性 IP 地址，则需要在重新启动后重新关联它.
记住！如果您的实例 B 只是为了这个过程而临时启动的，请不要忘记立即终止它.
Remember! If your instance B was temporarily started just for this process, don’t forget to terminate it now.
这篇关于将密钥对添加到现有 EC2 实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
