Ich habe Stunden gebraucht, um dieses SSH-Problem mit einem meiner Klassenkonten auf den Servern meiner Schule zu lösen.
Ich konnte nicht in ein bestimmtes Klassenkonto ssh, ohne mein Passwort einzugeben, während die passwortlose Authentifizierung mit meinen anderen Klassenkonten funktionierte. Das .ssh/-Verzeichnis und alle seine Inhalte hatten dieselben korrekten Berechtigungen wie die anderen Klassenkonten.
Es stellte sich heraus, dass das Problem die Berechtigungen waren, die für mein eigenes Home-Verzeichnis festgelegt wurden. Die passwortlose Authentifizierung funktionierte nicht, wenn die Berechtigungen für mein HOME-Verzeichnis auf 770 gesetzt waren (unabhängig von den Berechtigungen für .ssh/), aber es funktionierte mit Berechtigungen, die auf 755 oder 700 gesetzt waren.
Weiß jemand warum SSH das macht? Liegt es daran, dass die Berechtigungen des Home-Verzeichnisses zu freizügig sind? Warum weigert sich SSH, sich mit den öffentlichen/privaten Schlüsseln zu authentifizieren, wenn das Home-Verzeichnis freizügiger als 700 ist?
Akzeptierte Antwort:
Dies ist das Standardverhalten für SSH. Es schützt Benutzerschlüssel, indem es rwx------ erzwingt auf $HOME/.ssh und sicherzustellen, dass nur der Besitzer Schreibrechte auf $HOME hat . Wenn ein anderer Benutzer als der jeweilige Besitzer Schreibrechte auf der $HOME hat Verzeichnis, könnten sie die Berechtigungen für $HOME/.ssh böswillig ändern , wodurch möglicherweise die Benutzerschlüssel known_hosts entführt werden , oder etwas ähnliches. Zusammenfassend die folgenden Berechtigungen auf $HOME ausreichen, damit SSH funktioniert.
rwx------rwxr-x---rwxr-xr-x
SSH funktioniert nicht richtig und sendet Warnungen an die Protokollierungseinrichtungen, wenn g+w variiert oder o+w existiert auf $HOME Verzeichnis. Der Administrator kann dieses Verhalten jedoch überschreiben, indem er StrictModes no definiert in der sshd_config (oder ähnliche) Konfigurationsdatei, obwohl klar sein sollte, dass dies nicht empfohlen wird .