Cuando el usuario raíz cambió los permisos de todos los archivos en una determinada carpeta, se utilizó el comando chmod -R. A primera vista, este comando es normal y se puede ejecutar, pero las siguientes indicaciones hacen que las personas se sientan muy mal, porque no hay tantos archivos bajo yang, ¿por qué también se han cambiado los permisos de directorios irrelevantes? Siento que ctrl+c está terminado. Después de una mirada más cercana, hay un / en yang. Este es un comando muy peligroso. Cualquiera con un poco de común sentido sabe que el directorio raíz Los permisos de archivo no se pueden manipular En ese momento, me sorprendió, así que abrí otra terminal y no pude conectarme, pero pude conectarme con la función clonar ssh de secureCRT.
[aplicación root@yang]# chmod -R 777 yang /
Use ssh localhost para solicitar:
[test@yang .ssh]$ ssh localhost
ssh_exchange_identification: leer: Conexión restablecida por par
La conexión remota no se puede conectar, use el siguiente comando para ver el proceso de conexión detallado:
use [root@yang app]# ssh -v localhost
OpenSSH_6.7p1, OpenSSL 1.0.0-fips 29 de marzo de 2010
debug1: lectura de datos de configuración /etc/ssh/ssh_config
debug1: conexión al host local [::1] puerto 22. debug1:
conexión establecida
. 0/0
debug1: key_load_public: no existe tal archivo o directorio
debug1: archivo de identidad /root/.ssh/id_rsa tipo -1
debug1: key_load_public: no existe tal archivo o directorio
debug1: archivo de identidad /root/.ssh/id_rsa-cert tipo - 1
debug1: key_load_public: No existe tal archivo o directorio
debug1: archivo de identidad /root/.ssh/id_dsa tipo -1
debug1: key_load_public: no existe tal archivo o directorio
debug1: archivo de identidad /root/.ssh/id_dsa-cert tipo -1
debug1: key_load_public: no existe tal archivo o directorio
debug1: archivo de identidad /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No existe tal archivo o directorio
debug1: archivo de identidad /root/.ssh/id_ed25519-cert type -1
debug1: Habilitación del modo de compatibilidad para el protocolo 2.0
debug1: Cadena de versión local SSH-2.0-OpenSSH_6.7
ssh_exchange_identification: lectura: restablecimiento de la conexión por pares
Así que fui al omnipotente Baidu Google, busqué la palabra clave ssh_exchange_identification: leer: Restablecimiento de la conexión por pares, y descubrí que muchos internautas encontraron tales problemas, algunos de los cuales fueron agregados por ip a la lista restringida, algunos de los cuales fueron dns incapaz de resolver el nombre del host, y algunos de los cuales dije que cambié los permisos por error, y me alegré de ver esto, y el héroe vio lo mismo. ¿No es este el mismo problema que encontré, así que cambié todos los permisos? archivos en el directorio /etc/ssh/ de acuerdo con la publicación En 400 permisos, haz lo que está, aún no funciona, informa el mismo error.
Otro extranjero dijo, no te preocupes por nada, solo reinícialo y listo. Es un poco de dolor de cabeza. Aunque es un entorno de prueba, no me atrevo a reiniciarlo precipitadamente. Si no funciona, tengo que preguntarle al administrador de host para ejecutar en la sala de computación. Afortunadamente, hay un entorno similar en la máquina virtual. Primero hice una instantánea del sistema, imitando la misma operación, oye, realmente es el mismo error, reinícialo, oye, yo No puedo iniciar sesión directamente en el lado de administración, incluso si está en la sala de computadoras, no hay nada que pueda hacer, lo correcto es usar Iniciar sesión en la consola con root + contraseña. Afortunadamente, no se reinició De lo contrario, si corriera a la sala de computadoras, estaría en contacto con la máquina a distancia cero. Sin embargo, el destino terminó y no puede iniciar sesión. ¿Qué puede hacer? Solo puede devolver la máquina virtual. a la original. En la instantánea, continúa experimentando.
Continuando con Baidu, fui a un sitio web de nueces torcidas. En un hilo humilde en un hilo humilde en un foro humilde, un amigo dijo de una manera muy discreta: "Sé que esta pregunta es antigua, pero quería compartir algunos hallazgos que obtuve, verifique si /var/empty/sshd en el servidor tiene la propiedad y los permisos adecuados. Teníamos un script de chef que se modificó para actualizar algunas peimisiones del directorio, pero sin querer Se actualizó el directorio debajo del objetivo previsto, se cambió la propiedad de /var a un usuario/grupo de la aplicación y se cambiaron los permisos a 755". Marcado en /
var, y efectivamente, los permisos son todos 777, cd al directorio vacío, efectivamente Ahí está la carpeta ssh, y no queda nada en el cd, entonces ejecuto directamente dos comandos:
cd /var
chmod -R 755 *
Luego probé la conexión remota nuevamente y resultó estar bien.
Parece que Linux está lleno de trampas, similares a los errores por descuido, está rm -f log *, que borra todo en el directorio actual; el comando hostname tiene un espacio, lo que hace que RAC se bloquee. Es cierto escuchar las palabras de los predecesores, si no puede usar root, no use root, si no puede usar root, no use root, si no puede usar root, no use root !