将密钥对添加到现有 EC2 实例

发布于 2024-09-09 08:03:01 字数 203 浏览 14 评论 0原文

我获得了 AWS 控制台访问权限，该帐户正在运行 2 个实例，但我无法关闭（在生产中）。但是，我想获得对这些实例的 SSH 访问权限，是否可以创建一个新的密钥对并将其应用到这些实例，以便我可以通过 SSH 访问？当前无法获取用于创建实例的密钥对的现有 pem 文件。

如果这不可能，还有其他方法可以进入实例吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

橘和柠 2024-09-16 08:03:02

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

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

You can just add a new key to the instance by the following command:

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

You can configure domain_alias in ~/.ssh config

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

回复收藏 0 原文

生生漫 2024-09-16 08:03:02

实例一旦启动，就无法更改
与元数据级别的实例关联的密钥对，但是您
可以更改用于连接到实例的 ssh 密钥。

stackoverflow.com/questions/7881469/change-key-pair-for-ec2-instance< /a>

回复收藏 0 原文

命比纸薄 2024-09-16 08:03:02

您实际上可以通过 elastic beanstalk 配置页面添加密钥对。然后它会为您重新启动您的实例，一切正常。

回复收藏 0 原文

何其悲哀 2024-09-16 08:03:02

现在可以使用您控制的任何 SSH 密钥临时访问正在运行的实例，甚至无需将其作为密钥对添加到 EC2，使用 EC2 实例连接。它仅在某些 Linux 发行版和 AMI 上受支持，但如果您使用的是相对较新版本的 Amazon Linux 2 或 Ubuntu，则应默认安装并运行它。

使用 EC2 Instance Connect 主要有两种方式：

在 AWS 控制台中，您可以选择 EC2 中的实例详细信息，然后单击右上角的“连接”按钮，然后使用“EC2 Instance Connect”选项卡（当前默认）。
在 AWS CLI 中，您首先使用 aws ec2-instance-connect send-ssh-public-key 将密钥分发到实例，然后照常使用 SSH 连接。

请注意，这只是一个临时允许，您的 SSH 密钥将在短时间内停止被允许，但一旦进入就不会断开连接。这也不会修改 authorized_keys 文件，因此不要指望在那里看到新行。如果您想永久允许您的 SSH 密钥，则在通过 EC2 Instance Connect 进入后，手动编辑 authorized_keys 文件并为您的 SSH 密钥添加相应的行。

您需要能够通过网络访问您的实例才能使用它，并且它需要允许 SSH 连接（设置安全组等）。您可以从实际 SSH 所在的不同位置运行 AWS CLI 命令，例如，您可以使用同一 VPC 中的另一个 EC2 实例来访问当前无法访问的 EC2 实例。

仅对于控制台版本，实例特别需要具有：

公共 IPv4 地址，以及
允许 TCP 端口 22 从其区域的 EC2 Instance Connect 服务 IP 地址范围进入的安全组规则。

服务 IP 地址范围可以从完整的AWS IP 地址范围列表。一些curl和jq可以快速获取正确的范围（将us-west-1替换为所需的区域）：

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | \
jq '.prefixes[] | select(.region == "us-west-1" and .service=="EC2_INSTANCE_CONNECT")'

输出将如下所示：

{
  "ip_prefix": "13.52.6.112/29",
  "region": "us-west-1",
  "service": "EC2_INSTANCE_CONNECT",
  "network_border_group": "us-west-1"
}

ip_prefix的值是您需要允许的 CIDR 块。

It is now possible to temporarily gain access to a running instance using any SSH key you control, without even adding it as a keypair to EC2, using EC2 Instance Connect. It's only supported on some Linux distributions and AMIs but if you're using a relatively recent version of Amazon Linux 2 or Ubuntu it should be installed and running by default.

There's two main ways to use EC2 Instance Connect:

From the AWS Console, you can select the instance detail in EC2 and click the "Connect" button in the upper-right corner, then use the "EC2 Instance Connect" tab (currently the default).
From the AWS CLI, you first distribute your key to the instance with aws ec2-instance-connect send-ssh-public-key then connect with SSH as usual.

Note that this is only a temporary allowance, your SSH key will cease to be allowed after a short period of time, though once in you won't be disconnected. This also doesn't modify the authorized_keys file so don't expect to see a new line there. If you want to allow your SSH key permanently, once you get in through EC2 Instance Connect, manually edit the authorized_keys file and add the appropriate line for your SSH key.

You need to be able to reach your instance over the network to use this and it needs to allow SSH connections (set up security groups, etc.). You can run the AWS CLI command from a different place than wherever you actually SSH from, so for example you can use another EC2 instance in the same VPC to reach your currently unreachable EC2 instance.

For the Console version only, the instance specifically needs to have:

a public IPv4 address, and
a security group rule that allows TCP port 22 ingress from the EC2 Instance Connect service IP address range for its region.

The range of service IP addresses can be obtained from the full list of AWS IP address ranges. Some curl and jq can fetch the right range quickly (replace us-west-1 with the desired region):

curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | \
jq '.prefixes[] | select(.region == "us-west-1" and .service=="EC2_INSTANCE_CONNECT")'

the output will look something like this:

{
  "ip_prefix": "13.52.6.112/29",
  "region": "us-west-1",
  "service": "EC2_INSTANCE_CONNECT",
  "network_border_group": "us-west-1"
}

The value of ip_prefix is the CIDR block that you need to allow.

回复收藏 0 原文

欢烬 2024-09-16 08:03:01

您无法将密钥对应用于正在运行的实例。您只能使用新的密钥对来启动新实例。

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

尽管临时存储中的数据将会丢失。

由于这个问题和答案很受欢迎，我想捕获罗德尼在其评论中发布的链接中的信息。

信用转到Eric Hammond 此信息。

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

即使您处于您认为的灾难性情况，例如

您丢失了 ssh 密钥或忘记了密码，
您也可以检查和编辑 EC2 实例上的根 EBS 卷上的文件编辑 /etc/sudoers 文件时出错，无法再使用
使用 sudo 获得 root 访问权限来修复它
您长时间运行的实例由于某种原因挂起，无法修复
已联系，但无法正常启动
您需要从实例中恢复文件，但无法访问它

在办公桌上的物理计算机上，您只需使用 CD 或 USB 记忆棒启动系统，安装硬盘驱动器，然后查看并修复文件，然后重新启动计算机以恢复正常工作。

然而，当您处于其中一种情况时，远程 EC2 实例似乎很遥远并且无法访问。幸运的是，AWS 为我们提供了恢复此类系统的能力和灵活性，前提是我们运行的是 EBS 启动实例而不是实例存储。

EC2 上的方法有点类似于物理解决方案，但我们要将有故障的“硬盘驱动器”（根 EBS 卷）移动并安装到不同的实例，修复它，然后将其移回。

在某些情况下，启动一个新的 EC2 实例并扔掉坏的实例可能会更容易，但如果您确实想修复文件，以下是对许多人有效的方法：

设置

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

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

修复它

此时，实例 A 中的整个根文件系统可在实例 B 上的 /vol-a 下查看和编辑。例如，您可能需要：

将正确的 ssh 密钥放入 / vol-a/home/ubuntu/.ssh/authorized_keys
编辑并修复 /vol-a/etc/sudoers
在 /vol-a/var/log/syslog 中查找错误消息
将重要文件复制出 /vol-a/...

< em>注意：两个实例上的 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 地址，则需要在再次启动实例 A 后重新关联它。

请记住！如果您的实例 B 只是为了此过程而临时启动的，请不要忘记立即终止它。

You can't apply a keypair to a running instance. You can only use the new keypair to launch a new instance.

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.

Due to the popularity of this question and answer, I wanted to capture the information in the link that Rodney posted on his comment.

Credit goes to Eric Hammond for this information.

Fixing Files on the Root EBS Volume of an EC2 Instance

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:

You lost your ssh key or forgot your password
You made a mistake editing the /etc/sudoers file and can no longer
gain root access with sudo to fix it
Your long running instance is hung for some reason, cannot be
contacted, and fails to boot properly
You need to recover files off of the instance but cannot get to it

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.

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.

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.

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:

Setup

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)

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

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

Fix It

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:

Put the correct ssh keys in /vol-a/home/ubuntu/.ssh/authorized_keys
Edit and fix /vol-a/etc/sudoers
Look for error messages in /vol-a/var/log/syslog
Copy important files out of /vol-a/…

Note: The uids on the two instances may not be identical, so take care if you are creating, editing, or copying files that belong to non-root users. For example, your mysql user on instance A may have the same UID as your postfix user on instance B which could cause problems if you chown files with one name and then move the volume back to A.

Wrap Up

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

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

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.

Note: If you had an Elastic IP address assigned to instance A when you stopped it, you’ll need to reassociate it after starting it up again.

Remember! If your instance B was temporarily started just for this process, don’t forget to terminate it now.

回复收藏 0 原文

你的他你的她 2024-09-16 08:03:01

虽然您无法直接向正在运行的 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 [电子邮件受保护]

第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”添加到 sudoer 列表：
[root@ip-11-111-111-111 ubuntu]# visudo
.. 并将以下内容添加到文件末尾：
约翰全部 = (全部) 全部
好吧！我们已经创建了新用户，现在您需要生成登录所需的密钥文件，就像我们在步骤 1 中创建的 my_orin_key.pem 一样。
现在，退出并返回 ubuntu，脱离 root。
[root@ip-11-111-111-111 ubuntu]# 退出 [ubuntu@ip-11-111-111-111 ~]$

第 3 步：创建公钥和私钥：

[ubuntu@ip-11-111-111-111 ~]$ su 约翰

输入您在步骤 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
[约翰@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 下载/上传文件，以下是您的操作方法。
您仍然需要使用 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 [电子邮件受保护]:/home/ubuntu /约翰·约翰
上述命令会将密钥“john”复制到本地计算机上的当前工作目录。将密钥复制到本地计算机后，您应该删除“/home/ubuntu/john”，因为它是私钥。
现在，将您的本地计算机 chmod john 更改为 600。
<前><代码>$ chmod 600 约翰
第 5 步：测试您的密钥：
```
$ ssh -i john [电子邮件受保护]
```

因此，通过这种方式，您可以设置多个用户使用一个 EC2 实例！

Though you can't add a key pair to a running EC2 instance directly, you can create a linux user and create a new key pair for him, then use it like you would with the original user's key pair.

In your case, you can ask the instance owner (who created it) to do the following. Thus, the instance owner doesn't have to share his own keys with you, but you would still be able to ssh into these instances. These steps were originally posted by Utkarsh Sengar (aka. @zengr) at http://utkarshsengar.com/2011/01/manage-multiple-accounts-on-1-amazon-ec2-instance/. I've made only a few small changes.

Step 1: login by default “ubuntu” user:

$ ssh -i my_orig_key.pem [email protected]

Step 2: create a new user, we will call our new user “john”:
```
[ubuntu@ip-11-111-111-111 ~]$ sudo adduser john
```
Set password for “john” by:
```
[ubuntu@ip-11-111-111-111 ~]$ sudo su -
[root@ip-11-111-111-111 ubuntu]# passwd john
```
Add “john” to sudoer’s list by:
```
[root@ip-11-111-111-111 ubuntu]# visudo
```
.. and add the following to the end of the file:
```
john   ALL = (ALL)    ALL
```
Alright! We have our new user created, now you need to generate the key file which will be needed to login, like we have my_orin_key.pem in Step 1.
Now, exit and go back to ubuntu, out of root.
```
[root@ip-11-111-111-111 ubuntu]# exit
[ubuntu@ip-11-111-111-111 ~]$
```

Step 3: creating the public and private keys:

[ubuntu@ip-11-111-111-111 ~]$ su john

Enter the password you created for “john” in Step 2. Then create a key pair. Remember that the passphrase for key pair should be at least 4 characters.

[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

In the above step, john is the user we created and ubuntu is the default user group.

[john@ip-11-111-111-111 ~]$ sudo chown john:ubuntu .ssh/authorized_keys

Step 4: now you just need to download the key called “john”. I use scp to download/upload files from EC2, here is how you can do it.
You will still need to copy the file using ubuntu user, since you only have the key for that user name. So, you will need to move the key to ubuntu folder and chmod it to 777.
```
[john@ip-11-111-111-111 ~]$ sudo cp john /home/ubuntu/
[john@ip-11-111-111-111 ~]$ sudo chmod 777 /home/ubuntu/john
```
Now come to local machine’s terminal, where you have my_orig_key.pem file and do this:
```
$ cd ~/.ssh
$ scp -i my_orig_key.pem [email protected]:/home/ubuntu/john john
```
The above command will copy the key “john” to the present working directory on your local machine. Once you have copied the key to your local machine, you should delete “/home/ubuntu/john”, since it’s a private key.
Now, one your local machine chmod john to 600.
```
$ chmod 600 john
```
Step 5: time to test your key:
```
$ ssh -i john [email protected]
```

So, in this manner, you can setup multiple users to use one EC2 instance!!

回复收藏 0 原文

↘紸啶 2024-09-16 08:03:01

对于 Elastic Beanstalk 环境，您可以将键值对应用于正在运行的实例，如下所示：

从 EC2 创建键值对 ->密钥对（在“网络和安全”选项卡下）
转至 Elastic Beanstalk 并单击您的应用程序
转至 Configuration -> 安全，然后单击编辑
选择您的 EC2 密钥对，然后单击应用
单击确认以确认更新。它将终止环境并将密钥值应用到您的环境。

回复收藏 0 原文

苄①跕圉湢 2024-09-16 08:03:01

在本地机器上，运行命令：

ssh-keygen -t rsa -C "SomeAlias"

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

在 Amazon 计算机上，编辑 ~/.ssh/authorized_keys 并粘贴 *.pub 文件的内容（并首先删除任何现有内容）。

然后，您可以使用 ssh-keygen 命令生成的其他文件（私钥）进行 SSH。

On your local machine, run command:

ssh-keygen -t rsa -C "SomeAlias"

After that command runs, a file ending in *.pub will be generated. Copy the contents of that file.

On the Amazon machine, edit ~/.ssh/authorized_keys and paste the contents of the *.pub file (and remove any existing contents first).

You can then SSH using the other file that was generated from the ssh-keygen command (the private key).

回复收藏 0 原文

泛泛之交 2024-09-16 08:03:01

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

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

回复收藏 0 原文

-柠檬树下少年和吉他 2024-09-16 08:03:01

我之前就发生过这种情况（无法访问其他人创建的 EC2 实例，但可以访问 AWS Web 控制台），我在博客中发布了答案：http://readystate4.com/2013/04/09/aws-gaining- ssh-access-to-an-ec2-instance-you-lost-access-to/

基本上，您可以分离 EBS 驱动器，将其连接到您有权访问的 EC2。将您的 SSH 公钥添加到此附加驱动器上的 ~ec2-user/.ssh/authorized_keys 中。然后将其放回旧的 EC2 实例上。链接中使用 Amazon AMI 的分步说明。

无需制作快照或创建新的克隆实例。

回复收藏 0 原文

你与昨日 2024-09-16 08:03:01

就我而言，我使用此文档将密钥对与我的 Elastic Beanstalk 实例关联

重要
您必须创建 Amazon EC2 密钥对并将您的 Elastic Beanstalk 预置的 Amazon EC2 实例配置为使用 Amazon EC2 密钥对，然后才能访问您的 Elastic Beanstalk 预置的 Amazon EC2 实例。您可以使用 AWS 管理控制台设置 Amazon EC2 密钥对。有关为 Amazon EC2 创建密钥对的说明，请参阅 Amazon Elastic Compute Cloud 入门指南。

配置具有 Elastic Beanstalk 的 Amazon EC2 服务器实例

回复收藏 0 原文

~没有更多了~