SSH-Key-Authentifizierung schlägt fehl

Question 1

Dadurch werden normalerweise die meisten Probleme mit der SSH-Berechtigung für autorisierte Schlüssel behoben.auf der Serverseite, vorausgesetzt, jemand hat keine zusätzlichen Änderungen an den Berechtigungen vorgenommen.

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

(Das ist wasBenutzerführt dies automatisch in seinem „Shim“-Skript durch, um alle Berechtigungsprobleme basierend auf Änderungen im Web-Dashboard des Teams zu aktualisieren und zu beheben.)

Wenn Ihr Administrator das Verzeichnis .ssh/ oder die Datei .ssh/authorized_keys als Root erstellt hat (was am häufigsten vorkommt, wenn dies nicht funktioniert), dann ist es nicht erlaubt, dass die Datei einem anderen Benutzer gehört, SELBST wenn dieser BenutzerWurzel.

Answer

Dadurch werden normalerweise die meisten Probleme mit der SSH-Berechtigung für autorisierte Schlüssel behoben.auf der Serverseite, vorausgesetzt, jemand hat keine zusätzlichen Änderungen an den Berechtigungen vorgenommen.

# paste these into an SSH session that server (probably from
# another user account or root)

# change this to YOUR username on the server.
YOURUSER=example

# paste these lines verbatim:
sudo chown $YOURUSER:$YOURUSER /home/$YOURUSER/{.,.ssh/,.ssh/authorized_keys}
sudo chmod u+rwX,go-rwX,-t /home/$YOURUSER/{.ssh/,.ssh/authorized_keys}
sudo chmod go-w /home/$YOURUSER/

(Das ist wasBenutzerführt dies automatisch in seinem „Shim“-Skript durch, um alle Berechtigungsprobleme basierend auf Änderungen im Web-Dashboard des Teams zu aktualisieren und zu beheben.)

Wenn Ihr Administrator das Verzeichnis .ssh/ oder die Datei .ssh/authorized_keys als Root erstellt hat (was am häufigsten vorkommt, wenn dies nicht funktioniert), dann ist es nicht erlaubt, dass die Datei einem anderen Benutzer gehört, SELBST wenn dieser BenutzerWurzel.

Question 2

Ich hatte genau das gleiche Problem auf zwei Servern: einem Linux mit Debian Stretch und einem NAS (Synology DS715).

Es stellte sich heraus, dass in beiden Fällen die Berechtigungen für das Home-Verzeichnis auf dem Server falsch waren

das auth.log auf dem Server war sehr hilfreich

Authentication refused: bad ownership or modes for directory /home/cyril

unter Linux war das Schreib-/Gruppenbit aktiviert (drwxrwxr--x), also musste ich zumindest das Schreib-Gruppenbit entfernen (chmod gw ~/), und dann funktionierte es

Auf der Synology gab es aus irgendeinem Grund ein klebriges Stück

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

Ich musste es ändern mit

chmod -t ~/

und ich konnte mich dann ohne Passwort verbinden

Answer

Ich hatte genau das gleiche Problem auf zwei Servern: einem Linux mit Debian Stretch und einem NAS (Synology DS715).

Es stellte sich heraus, dass in beiden Fällen die Berechtigungen für das Home-Verzeichnis auf dem Server falsch waren

das auth.log auf dem Server war sehr hilfreich

Authentication refused: bad ownership or modes for directory /home/cyril

unter Linux war das Schreib-/Gruppenbit aktiviert (drwxrwxr--x), also musste ich zumindest das Schreib-Gruppenbit entfernen (chmod gw ~/), und dann funktionierte es

Auf der Synology gab es aus irgendeinem Grund ein klebriges Stück

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

Ich musste es ändern mit

chmod -t ~/

und ich konnte mich dann ohne Passwort verbinden

Question 3

Wenn Sie CentOS 7 verwenden, und ich bin sicher, dass dies auch für andere Linux-Betriebssysteme gilt, die SSHD verwenden. Mit Root-Zugriff können Sie genauer ermitteln, warum die Authentifizierung möglicherweise fehlschlägt. Gehen Sie dazu wie folgt vor:

Aktivieren Sie die Protokollierung für den sshdDaemon:sudo vi /etc/ssh/sshd_config
Unter „Protokollierung“ die Auskommentierung entfernen:

SyslogFacility AUTH
LogLevel INFO

Ändern LogLevelvon INFOaufDEBUG
Speichern und schließen
Starten Sie den SSH-Daemon neu mitsudo systemctl restart sshd
Beobachten Sie die Nachrichtendateitail -l /var/log/messages
Versuchen Sie, über ein anderes Terminal eine Verbindung per SSH herzustellen
Versuch einer Verbindung mitssh
Überprüfen Sie das Authentifizierungsprotokoll auf die genaue Ursache

Bei mir traten beispielsweise einige der oben beschriebenen Probleme auf.

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

Mithilfe dieser Schritte konnte ich bestätigen, dass das Problem an den Berechtigungen für die authorized_keysDatei lag. Durch die Einstellung chmod 644der authorized_keysDatei meines Benutzers wurde das Problem behoben.

Answer

Wenn Sie CentOS 7 verwenden, und ich bin sicher, dass dies auch für andere Linux-Betriebssysteme gilt, die SSHD verwenden. Mit Root-Zugriff können Sie genauer ermitteln, warum die Authentifizierung möglicherweise fehlschlägt. Gehen Sie dazu wie folgt vor:

Aktivieren Sie die Protokollierung für den sshdDaemon:sudo vi /etc/ssh/sshd_config
Unter „Protokollierung“ die Auskommentierung entfernen:

SyslogFacility AUTH
LogLevel INFO

Ändern LogLevelvon INFOaufDEBUG
Speichern und schließen
Starten Sie den SSH-Daemon neu mitsudo systemctl restart sshd
Beobachten Sie die Nachrichtendateitail -l /var/log/messages
Versuchen Sie, über ein anderes Terminal eine Verbindung per SSH herzustellen
Versuch einer Verbindung mitssh
Überprüfen Sie das Authentifizierungsprotokoll auf die genaue Ursache

Bei mir traten beispielsweise einige der oben beschriebenen Probleme auf.

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

Mithilfe dieser Schritte konnte ich bestätigen, dass das Problem an den Berechtigungen für die authorized_keysDatei lag. Durch die Einstellung chmod 644der authorized_keysDatei meines Benutzers wurde das Problem behoben.

Question 4

Ich hatteein ähnliches Problem, wo die SSH-Verbindung den Schlüssel versucht, ~/.ssh/id_rsabevor sie unerwartet beendet wird:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

In meinem Fall lag es daran, dass eine alte öffentliche Schlüsseldatei im .sshVerzeichnis herumlag:

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Das Verschieben/Löschen id_rsa.pubaus dem .sshVerzeichnis hat das Problem gelöst.

So wie ich es verstehe: Wenn auf der Clientseite ein öffentlicher Schlüssel vorhanden ist, validiert SSH zuerst den privaten Schlüssel anhand dieses Schlüssels. Wenn dies fehlschlägt, wird nicht versucht, mit dem privaten Schlüssel eine Remoteverbindung herzustellen.

Ich habe eine E-Mail an die OpenSSH-Mailingliste gesendet:https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html.

Answer

Ich hatteein ähnliches Problem, wo die SSH-Verbindung den Schlüssel versucht, ~/.ssh/id_rsabevor sie unerwartet beendet wird:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

In meinem Fall lag es daran, dass eine alte öffentliche Schlüsseldatei im .sshVerzeichnis herumlag:

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Das Verschieben/Löschen id_rsa.pubaus dem .sshVerzeichnis hat das Problem gelöst.

So wie ich es verstehe: Wenn auf der Clientseite ein öffentlicher Schlüssel vorhanden ist, validiert SSH zuerst den privaten Schlüssel anhand dieses Schlüssels. Wenn dies fehlschlägt, wird nicht versucht, mit dem privaten Schlüssel eine Remoteverbindung herzustellen.

Ich habe eine E-Mail an die OpenSSH-Mailingliste gesendet:https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html.

SSH-Key-Authentifizierung schlägt fehl

Antwort1

Antwort2

Antwort3

Antwort4

verwandte Informationen