Lösung 1:
Ja, SELinux ist wahrscheinlich die Ursache. Der .ssh dir ist wahrscheinlich falsch beschriftet. Sehen Sie sich /var/log/audit/audit.log an . Es sollte mit ssh_home_t gekennzeichnet sein . Prüfen Sie mit ls -laZ . Führen Sie restorecon -r -vv /root/.ssh aus wenn nötig.
Lösung 2:
Ich hatte das gleiche Problem. In meinem Fall funktionierten restorecon und chcon nicht.
Selinux wollte ich nicht deaktivieren. Nach vielen Recherchen fand ich schließlich heraus, dass es daran lag, dass mein Home-Verzeichnis von woanders (NFS) gemountet wurde. Ich habe diesen Fehlerbericht gefunden, der mich darauf aufmerksam gemacht hat.
Ich lief:
> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off
um zu bestätigen, dass use_nfs_home_dirs ausgeschaltet war und dann:
sudo setsebool -P use_nfs_home_dirs 1
um es einzuschalten.
Jetzt kann ich mit meinem Schlüssel und ohne Eingabe eines Passworts eine SSH-Verbindung zu meinem Computer herstellen. Das Umschalten des booleschen use_home_nfs_dirs war das, was es für mich brauchte.
Lösung 3:
Um die Antwort von Mark Wagner zu ergänzen, wenn Sie einen benutzerdefinierten Home-Verzeichnispfad verwenden (dh nicht /home ), müssen Sie sicherstellen, dass Sie den SELinux-Sicherheitskontext festgelegt haben. Um dies zu tun, wenn Sie beispielsweise Benutzer-Home-Verzeichnisse in /myhome haben , ausführen:
semanage fcontext -a -e /home /myhome
restorecon -vR /myhome