☰

Как восстановить удаленный доступ к системе RHEL из расширенных разрешений, установленных для всей файловой системы?

tag-icon • tag-icon linux ssh permissions chmod
Как восстановить удаленный доступ к системе RHEL из расширенных разрешений, установленных для всей файловой системы?

Причина проблемы

Я намеревался добавить групповое разрешение на запись для скрытых файлов, таких как «.hgignore», с помощью следующего:

# пароль
/выбор
# sudo chmod -R g+w .*

Проблема в том, что '..' соответствует этому шаблону, и теперь вся файловая система RHEL имеет набор g+w. Немедленные проблемы следующие:

  • /etc/sudoers необходимо установить на 440, а не на 460, чтобы теперь пользователи не могли использовать sudo.
  • Некоторые механизмы, похожие на описанные выше, не позволяют получить доступ по SSH. (Удаленные клиенты SSH получают сообщение об ошибке «ssh_exchange_identification: Connection closed by remote host»).

Вопрос

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

Теперь возникает вопрос: для каких важных файлов и каталогов необходимо отменить разрешения, чтобы восстановить sshих sudoфункциональность?

Примечание о «закрытом как дубликат»

ВопросПочему «chmod -R 777 /» является деструктивным?дает подробные объяснения того, какой эффект может иметь рекурсивное расширение разрешений. Этот вопрос призван ответить на вопрос о том, как восстановить удаленный доступ через ssh, чтобы можно было выполнить более масштабное восстановление и ремонт.

решение1

Для файлов, которые являются частью пакета, вы можете узнать, что именно было испорчено, выполнив команду

rpm --verify "имя_пакета"

где packagename — это отдельный пакет, или вы можете выполнить цикл по выводу "rpm -qa"

Тогда вы сможете использовать rpm, чтобы исправить их, например,

rpm --setperm "имя_пакета"

решение2

Проблема с ssh не ограничивается только /etc, а также связана с папкой .ssh пользователя, с которым вы пытаетесь подключиться, имеющей неправильные разрешения. Обычно папка .ssh для пользователя должна быть 700, закрытые ключи должны быть 600, а все остальное может быть 644.

Папка /etc/ssh должна иметь права 755, в /etc/ssh закрытые ключи должны иметь права 600, а все остальное должно иметь права 644.

Как восстановить сервер после неверных разрешений в /etc?

Возможно, одним из самых простых методов может быть восстановление из резервной копии. Вы ведь делаете резервные копии и тестировали процедуры восстановления, верно? :)

Если у вас нет резервной копии, которую можно использовать для восстановления, вам может потребоваться настроить чистую систему, идентичную виртуальной машине, а затем исправить разрешения на хосте на основе вашего сервера, сравнив их.

решение3

Если у вас заведомо исправный сервер, запуск на нем чего-то вроде следующего может помочь восстановить его. (Предполагается возможность рекурсивной подстановки (zsh), вместо этого можно использовать find с -exec / xargs):

for i in /etc/**/*; do
    perm=$(stat "$i" -c "%a")
    ssh root@badServerHostName "chmod $perm $i"
done

Может быть, нужно исключить несколько подкаталогов, а другие можно добавить... Rsync был бы лучше, если бы мог это сделатьтолькоразрешения, но я не думаю, что это возможно.

решение4

Если у вас есть резервная копия, LVM и достаточно места, вы можете сделать следующее:

1. восстановите резервную копию на новый временный логический том (смонтируйте его в /oldperm)
2. сделайте что-то вроде следующего псевдокода:

foreach oldfile in /oldperm/* {  
  newf = strip "/oldperm" from oldfile  
  chmod --reference=oldfile newf  
}

Вы можете восстановить частично, как и все в /etc сначала, если у вас проблемы с пространством. Этот трюк основан на флаге chmod --reference, который берет в качестве шаблона другой файл и делает аргумент соответствующим по разрешениям.

Таким образом, вы восстановите только старые права, не изменяя содержимое файлов.

Связанный контент