Causa del problema
Tenía la intención de agregar permiso de escritura grupal en archivos ocultos como '.hgignore' con lo siguiente:
#contraseña /optar # sudo chmod -R g+w .*
El problema es que '..' coincidía con este patrón, y ahora todo el sistema de archivos RHEL tiene configurado g+w. Los problemas inmediatos son los siguientes:
- /etc/sudoers debe configurarse en 440, no en 460, por lo que ahora los usuarios no pueden usar sudo.
- Algún mecanismo similar al anterior no permite el acceso ssh. (Los clientes ssh remotos reciben el mensaje de error "ssh_exchange_identification: Conexión cerrada por host remoto")
Pregunta
Para recuperar la capacidad de iniciar sesión de forma remota, es necesario instruir a alguien con acceso físico al servidor sobre cómo reparar el sistema.
La pregunta ahora es: ¿qué archivos y directorios importantes necesitan revertir sus permisos para restaurar sshsu sudofuncionalidad?
Nota sobre "cerrado como duplicado"
La pregunta¿Por qué "chmod -R 777 /" es destructivo?proporciona explicaciones detalladas sobre el efecto que pueden tener los permisos expandidos de forma recursiva. Esta pregunta pretende responder a la pregunta de cómo recuperar el acceso remoto a través de ssh para poder realizar restauraciones y reparaciones más exhaustivas.
Respuesta1
Para los archivos que forman parte de un paquete, puede averiguar qué se estropeó haciendo
rpm --verificar "nombre del paquete"
donde nombre del paquete es un paquete individual, o puede recorrer la salida de "rpm -qa"
Entonces deberías poder usar rpm para arreglarlos con algo como
rpm --setperm "nombre del paquete"
Respuesta2
El problema con ssh no se limita solo a /etc y también tiene que ver con la carpeta .ssh del usuario con el que está intentando conectarse y que tiene permisos inadecuados. Generalmente, la carpeta .ssh para un usuario debe ser 700, las claves privadas deben ser 600 y todo lo demás puede ser 644.
La carpeta /etc/ssh debe ser 755, en /etc/ssh las claves privadas deben ser 600 y todo lo demás debe ser 644.
¿Cómo recuperar un servidor de malos permisos en/etc?
Posiblemente uno de los métodos más sencillos sea restaurar desde su copia de seguridad. Usted hace copias de seguridad y ha probado los procedimientos de restauración, ¿verdad? :)
Si no tiene una copia de seguridad que pueda usar para realizar una restauración, es posible que necesite configurar un sistema limpio que sea idéntico en una VM y luego corregir los permisos en el host según su servidor comparando los dos.
Respuesta3
Si tiene un servidor en buen estado, ejecutar algo como lo siguiente en el servidor en buen estado podría ayudarle a restaurarlo. (Se supone que la capacidad de globbing recursiva (zsh), podría usar buscar con -exec / xargs en su lugar):
for i in /etc/**/*; do
perm=$(stat "$i" -c "%a")
ssh root@badServerHostName "chmod $perm $i"
done
Podrían ser un par de subdirectorios para excluir otros podrían agregarse... Rsync sería mejor si pudiera hacerlosolopermisos, pero no creo que pueda.
Respuesta4
Si tiene una copia de seguridad y tiene LVM y suficiente espacio, puede hacer lo siguiente:
1.restaurar la copia de seguridad en un nuevo nivel temporal (montarlo en /oldperm)
2. hacer algo como el siguiente pseudocódigo:
foreach oldfile in /oldperm/* {
newf = strip "/oldperm" from oldfile
chmod --reference=oldfile newf
}
Puede restaurar parcialmente, como todo lo que se encuentra en /etc primero, en caso de que tenga problemas de espacio. Este truco se basa en el indicador --reference de chmod que toma como plantilla otro archivo y hace que el argumento coincida en cuanto a permisos.
De esta manera sólo restaurará los permisos antiguos sin cambiar el contenido de los archivos.