☰

Amazon EC2 实例上丢失 sudo/su

tag-icon • tag-icon sudo amazon-ec2 amazon-web-services sudoers
Amazon EC2 实例上丢失 sudo/su

我有一个 Amazon EC2 实例。我可以正常登录，但现在“su”和“sudo”都不起作用（它们以前都正常工作）：

  • “su”要求输入密码，但我使用 ssh 密钥登录，而且我认为 root 用户甚至有密码。

  • “sudo <anything>”的作用是：


sudo: /etc/sudoers is owned by uid 222, should be 0 
sudo: no valid sudoers sources found, quitting

我可能确实执行了“chown ec2-user /etc/sudoers”（或者更可能是“chown -R ec2-user /etc”，因为我厌倦了 rsync 失败），所以这是我的错。

我该如何恢复？我停止了实例并尝试了 AWS EC2 控制台上的“查看/更改用户数据”选项，但这没有帮助。

编辑：我意识到我可以终止这个实例并创建一个新的实例，但希望避免极端的情况。

答案1

在这种情况下，我认为您应该能够使用第二个实例来解决问题：

  • 分离包含损坏系统的 EBS 磁盘
  • 创建另一个 EC2 实例
  • 将磁盘附加并安装到新实例
  • 修复权限
  • 卸载、分离并重新连接到原始实例

答案2

  1. 停止当前实例
  2. 分离现有卷
  3. 创建新卷
  4. 将新卷作为“/dev/xvda”附加到您的实例
  5. 启动您的实例
  6. 将旧卷（具有 sudo 权限问题的卷）重新附加到以“/dev/sdf”形式运行的实例
  7. 使用 putty 登录到您的实例

  8. 使用该lsblk命令查看可用的磁盘设备及其挂载点（如果适用），以帮助您确定要使用的正确设备名称。

      ec2-user ~$ lsblk
  NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
  xvdf 202:80 0 100G 0 disk
  xvda1 202:1 0 8G 0 disk /

lsblk 的输出会从完整设备路径中删除 /dev/ 前缀。在此示例中，/dev/xvda1被挂载为根设备（请注意，MOUNTPOINT 列为 /，即 Linux 文件系统层次结构的根），并且/dev/xvdf已连接，但尚未挂载。

  1. 使用以下命令为卷创建挂载点目录。挂载点是卷在文件系统树中的位置，也是挂载卷后读取和写入文件的位置。用 mount_point 替换位置，例如 /data。

    sudo su
cd /mnt
mkdir other
mount /dev/xvdf other
cd /
chown -R root:root /mnt/other/etc/
exit

  2. 返回 AWS 并停止实例

  3. 分离两个卷并将旧卷（现已修复）重新附加为 /dev/xvda
  4. 启动您的实例，现在您的权限应该恢复到原来的状态

答案3

我遇到了同样的问题，因为太难了，所以我制作了一个视频来解释解决方案。这与 Rekee 以视频教程的形式提供的解决方案几乎相同。

http://youtu.be/gh5CDtRX7Ho

希望能帮助到你。 ：）

答案4

看起来你自己已经回答了这个问题......

我可能确实执行了“chown ec2-user /etc/sudoers”（或者更可能是“chown -R ec2-user /etc”，因为我厌倦了 rsync 失败），所以这是我的错。

无论如何，我认为如果不获得 root shell，您就无法解决这个问题。 (我不确定在 ec2 上可以使用哪些恢复方法？)

如果您确实以递归方式 chown /etc 那么我认为重建服务器是最好的方法。

相关内容