Потерянный sudo/su на экземпляре Amazon EC2

Question

У меня есть экземпляр 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, но это не помогло.

РЕДАКТИРОВАТЬ: Я понимаю, что мог убить этот экземпляр и создать новый, но надеялся избежать чего-то такого экстремального.

Answer 1

В такой ситуации я думаю, что вы должны использовать второй экземпляр для решения проблемы:

• Отсоедините диск EBS, содержащий сломанную систему
• Создать другой экземпляр EC2
• Присоедините и смонтируйте диск к новому экземпляру
• Исправьте разрешения
• Размонтировать, отсоединить и подключить к исходному экземпляру

Answer 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 присоединен, но еще не смонтирован.

9. Используйте следующую команду для создания каталога точки монтирования для тома. Точка монтирования - это место, где том находится в дереве файловой системы, и куда вы читаете и записываете файлы после монтирования тома. Подставьте место для точки монтирования, например /data.

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

10. Вернитесь в AWS и остановите экземпляр

11. Отключите оба тома и заново подключите старый (теперь исправленный) том как /dev /xvda
12. Запустите свой экземпляр, и теперь ваши разрешения должны вернуться к тому, что было

Answer 3

У меня была та же самая проблема, и потому что это было так трудно, я сделал видео, чтобы объяснить решение. Это почти то же самое, что и решение Rekee в виде видеоурока.

http://youtu.be/gh5CDtRX7Ho

Надеюсь, поможет. :)

Answer 4

Похоже, вы сами на это ответили ...

Я, вероятно, сделал «chown ec2-user /etc /sudoers» (или, более вероятно, «chown -R ec2-user /etc», потому что меня тошнило от сбоя rsync), так что это моя ошибка.

В любом случае, я не думаю, что вы можете решить эту проблему без получения корневой оболочки. (Я не уверен, какие методы восстановления возможны на ec2?)

Если вы действительно использовали рекурсивный метод /etc, то я думаю, что восстановление сервера - это лучший способ.