Me tomó horas resolver este problema de SSH con una de las cuentas de mi clase en los servidores de mi escuela.
No podía ingresar a una cuenta de clase en particular sin ingresar mi contraseña, mientras que la autenticación sin contraseña funcionó con mis otras cuentas de clase. El directorio .ssh/ y todo su contenido tenían los mismos permisos correctos que las otras cuentas de clase.
Resulta que el problema eran los permisos establecidos en mi propio directorio de inicio. La autenticación sin contraseña no funcionó cuando los permisos en mi directorio HOME se establecieron en 770 (independientemente de los permisos establecidos para .ssh/), pero funcionó con los permisos establecidos en 755 o 700.
¿Alguien sabe por qué SSH hace esto? ¿Es porque los permisos del directorio de inicio son demasiado permisivos? ¿Por qué SSH se niega a autenticarse con las claves pública/privada cuando el directorio de inicio está configurado para ser más permisivo que 700?
Respuesta aceptada:
Este es el comportamiento predeterminado para SSH. Protege las claves de usuario al hacer cumplir rwx------ en $HOME/.ssh y asegurarse de que solo el propietario tenga permisos de escritura para $HOME . Si un usuario que no sea el propietario respectivo tiene permiso de escritura en $HOME directorio, podrían modificar malintencionadamente los permisos en $HOME/.ssh , secuestrando potencialmente las claves de usuario, known_hosts , o algo similar. En resumen, los siguientes permisos en $HOME será suficiente para que SSH funcione.
rwx------rwxr-x---rwxr-xr-x
SSH no funcionará correctamente y enviará advertencias a las instalaciones de registro si hay alguna variación de g+w o o+w existe en el $HOME directorio. Sin embargo, el administrador puede anular este comportamiento definiendo StrictModes no en el sshd_config (o similar) archivo de configuración, aunque debe quedar claro que esto no se recomienda .