Soluzione 1:
Sì, SELinux è probabilmente la causa. Il .ssh dir è probabilmente etichettato in modo errato. Guarda /var/log/audit/audit.log . Dovrebbe essere etichettato ssh_home_t . Controlla con ls -laZ . Esegui restorecon -r -vv /root/.ssh se necessario.
Soluzione 2:
Ho avuto lo stesso problema. Nel mio caso, restorecon e chcon non hanno funzionato.
Non volevo disabilitare selinux. Dopo molte ricerche, ho finalmente capito che era perché la mia home directory era stata montata da un'altra parte (NFS). Ho trovato questo bug report che mi ha dato un indizio.
Ho corso:
> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off
per confermare che use_nfs_home_dirs era disattivato e poi:
sudo setsebool -P use_nfs_home_dirs 1
per accenderlo.
Ora posso ssh sulla mia macchina usando la mia chiave e senza inserire una password. Cambiare il valore booleano use_home_nfs_dirs è stato quello che mi è servito.
Soluzione 3:
Per aggiungere alla risposta di Mark Wagner, se stai usando un percorso di home directory personalizzato (cioè non /home ), devi assicurarti di aver impostato il contesto di sicurezza SELinux. Per farlo, se hai directory home degli utenti in, ad esempio, /myhome , esegui:
semanage fcontext -a -e /home /myhome
restorecon -vR /myhome