Solución 1:
Sí, SELinux es probablemente la causa. El .ssh dir probablemente esté mal etiquetado. Mira /var/log/audit/audit.log . Debería estar etiquetado como ssh_home_t . Verifique con ls -laZ . Ejecute restorecon -r -vv /root/.ssh si es necesario.
Solución 2:
Tuve el mismo problema. En mi caso, restorecon y chcon no funcionaron.
No quería deshabilitar selinux. Después de mucha investigación, finalmente pensé que era porque mi directorio de inicio estaba montado desde otro lugar (NFS). Encontré este informe de error que me dio una pista.
Corrí:
> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off
para confirmar que use_nfs_home_dirs estaba desactivado y luego:
sudo setsebool -P use_nfs_home_dirs 1
para encenderlo.
Ahora puedo usar ssh en mi máquina usando mi clave y sin ingresar una contraseña. Cambiar el booleano use_home_nfs_dirs fue lo que me llevó.
Solución 3:
Para agregar a la respuesta de Mark Wagner, si está utilizando una ruta de directorio de inicio personalizada (es decir, no /home ), debe asegurarse de haber configurado el contexto de seguridad de SELinux. Para ello, si tiene directorios de inicio de usuario en, por ejemplo, /myhome , ejecuta:
semanage fcontext -a -e /home /myhome
restorecon -vR /myhome