Назад | Перейти на главную страницу

Невозможно войти в экземпляр ec2 после запуска «sudo chmod 2770 /»

Я новичок в Linux и AWS.

Я побежал sudo chmod 2770 / command на моем экземпляре ec2 и после этого

Мне было отказано в разрешении на все, что я делал (даже при использовании ls или cd)

Итак, я вышел из своего соединения (используя cygwin) и попытался повторно подключиться, но теперь я получаю

В доступе отказано (publickey, gssapi-keyex, gssapi-with-mic)

Я пробовал установить chmod 400 my.pem , chmod 600 my.pem, chmod 777 my.pem но ничего не работало.
Я пытаюсь подключиться, используя ssh -i my.pem ec2-user@xx.xx.xx.x который раньше работал нормально.
Каково решение?

Решение - запустить новый экземпляр и никогда больше не делать то, что делали вы. Было бы слишком сложно попытаться правильно восстановить все разрешения, которые вы сбросили на 2770.

Если у вас есть ценные файлы на сломанном экземпляре, вы можете остановить его, смонтировать его корневой объем в новый экземпляр и скопируйте файлы оттуда.


Обновить: как отмечает @GeraldSchneider, вам может повезти, если вы не повсюду рекурсивно изменили все разрешения. Вам нужно будет запустить новый экземпляр и использовать его, чтобы восстановить права root на 0755. Следуйте, например, инструкциям здесь: Изменено правило брандмауэра AWS EC2 и заблокирован ssh (вместо того Исправить брандмауэр делать sudo chmod 755 /mnt или куда бы вы ни монтировали другой диск).

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

Вы сделали каждый файл в файловой системе с разрешением 2770.

-rwxrws--- 1 username  agroup  2 Feb 19 23:07 thefilename

Это липкий бит в столбце группы, что означает, что все файлы внутри каталога принадлежат группа.


Я никогда так плохо не создавал образ AWS. Но я видел несколько проблем, которые их убивают.

ПЕРВЫЙ Вернитесь к своему последнему снимку, прежде чем использовать режимы файлов.

Вы не делаете периодические снимки?

ВТОРОЙ Посмотрите свои резервные копии. Будет ли больше или меньше работать, чтобы восстановить коробку или восстановить данные из резервных копий?

Какой? У вас тоже нет резервных копий?

Тогда последняя канава стандартный метод восстановления будет примерно таким:

  1. Создайте новый экземпляр из текущего AMI, в идеале того же дистрибутива, что и ваша сломанная машина. Это может быть что-то маленькое вроде t3.nano
  2. Отсоедините тома от сломанной машины и прикрепите их к новому экземпляру как sdf, g, h ... и т. Д.
  3. Войдите в свой новый экземпляр как root и для каждого из дисков вашего сломанного экземпляра запустите

    fsck /dev/xvdX
    mkdir /sdX
    mount /dev/xvdX /sdX
    cd /sdX
    ls -l
    
  4. На этом этапе вам нужно решить, стоит ли использовать chmod снова и снова, чтобы исправить вашу проблему, или копируете ли вы данные в новый экземпляр и настраиваете его заново.

  5. Поэтому вручную перейдите в каждый каталог и измените каждый файл таким, каким он должен быть. Не закрывайте два окна и сравните файлы живого хоста с смонтированными сломанными дисками. Убедитесь, что вы меняете ПРАВИЛЬНЫЕ файлы - проверяйте чаще !!!

  6. Когда вы закончите работу, выключите временную машину, отсоедините диски в веб-интерфейсе EC2, а затем снова подключите их к старой машине в тех же точках монтирования, с которых они были получены. ПРИМЕЧАНИЕ корневой диск прикреплен как sda1 не sda но все остальные тома подключены как sdb через z.


В любом случае вам следует настроить автоматические снимки состояния или резервное копирование, либо и то, и другое!

Чтобы избежать повторения того же самого, используйте псевдоним chmod для

 chmod --preserve-root

Но это не защитит никакой другой каталог.

Также не используйте sudo перед командами просто по привычке.