您不能将密钥对应用于正在运行的实例。您只能使用新密钥对来启动新实例。
对于恢复,如果它是 EBS 启动 AMI,您可以停止它,制作卷的快照。基于它创建一个新卷。并且能够使用它来启动旧实例、创建新映像或恢复数据。
虽然临时存储中的数据会丢失。
由于这个问答很受欢迎,我想在 Rodney 在他的评论中发布的链接中捕获信息。
this information 的信用转至 Eric Hammond。
在 EC2 实例的根 EBS 卷上修复文件
您可以检查和编辑 EC2 实例上根 EBS 卷上的文件,即使您处于您认为的灾难性情况,例如:
- 您丢失了 ssh 密钥或忘记了密码
- 您在编辑 /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 卷上的文件的第二个 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
ssh 到实例 B 并挂载该卷,以便您可以访问其文件系统。
ssh ...instance b...
sudo mkdir -p 000 /vol-a
sudo mount /dev/sdj /vol-a
修复它
此时,您可以在实例 B 上的 /vol-a 下查看和编辑来自实例 A 的整个根文件系统。例如,您可能想要:
- 将正确的 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 上):
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 地址,则需要在重新启动后重新关联它。
记住!如果您的实例 B 只是为此进程临时启动的,请不要忘记现在将其终止。