Solution 1 :
Oui, SELinux en est probablement la cause. Le .ssh dir est probablement mal étiqueté. Regardez /var/log/audit/audit.log . Il doit être étiqueté ssh_home_t . Vérifiez avec ls -laZ . Exécutez restorecon -r -vv /root/.ssh si besoin.
Solution 2 :
J'ai eu le même problème. Dans mon cas, restorecon et chcon n'ont pas fonctionné.
Je ne voulais pas désactiver selinux. Après de nombreuses recherches, j'ai finalement compris que c'était parce que mon répertoire personnel avait été monté d'ailleurs (NFS). J'ai trouvé ce rapport de bogue qui m'a éclairé.
J'ai couru :
> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off
pour confirmer que use_nfs_home_dirs était désactivé, puis :
sudo setsebool -P use_nfs_home_dirs 1
pour l'activer.
Maintenant, je peux me connecter en ssh à ma machine en utilisant ma clé et sans entrer de mot de passe. Basculer le booléen use_home_nfs_dirs était ce qu'il fallait pour moi.
Solution 3 :
Pour ajouter à la réponse de Mark Wagner, si vous utilisez un chemin de répertoire personnel personnalisé (c'est-à-dire pas /home ), vous devez vous assurer que vous avez défini le contexte de sécurité SELinux. Pour ce faire, si vous avez des répertoires d'accueil des utilisateurs dans, par exemple, /myhome , exécutez :
semanage fcontext -a -e /home /myhome
restorecon -vR /myhome