Frage Die SSH-Authentifizierung mit öffentlichem Schlüssel kann nicht funktionieren [geschlossen]


Auf meinem Server läuft CentOS 5.3. Ich bin auf einem Mac mit Leopard. Ich weiß nicht, wer dafür verantwortlich ist:

Ich kann mich über die Passwort-Authentifizierung gut am Server anmelden. Ich habe alle Schritte zum Einrichten von PKA (wie beschrieben unter http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html), aber wenn ich SSH verwende, weigert es sich sogar, eine öffentliche Verifizierung durchzuführen. Verwenden des Befehls

ssh -vvv user@host

(wo -vvv die Ausführlichkeit bis zum maximalen Level ankurbelt) Ich bekomme folgende relevante Ausgabe:

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

gefolgt von einer Eingabeaufforderung für mein Passwort. Wenn ich versuche, das Problem zu erzwingen

ssh -vvv -o PreferredAuthentications=publickey user@host

Ich bekomme

debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: No more authentication methods to try.

Also, obwohl der Server sagt, dass er die Publickey-Authentifizierungsmethode akzeptiert, und mein SSH-Client darauf besteht, werde ich widerlegt. (Beachten Sie das auffällige Fehlen einer Zeile "Offering public key:" oben.) Irgendwelche Vorschläge?


39
2017-08-18 04:18


Ursprung


verwenden Sie einfach "ssh -v", Sie brauchen nicht mehr Ausführlichkeit und schließen die gesamte Ausgabe ein, nicht nur die Zeilen, die Sie für wichtig halten - cstamas
Diese Frage wird geschlossen, weil sie nicht mehr zu beantworten ist und Antworten von schlechter Qualität anzieht. - HopelessN00b


Antworten:


Vergewissern Sie sich, dass Ihr Centos-Gerät über Folgendes verfügt:

RSAAuthentication yes
PubkeyAuthentication yes

in sshd_config

und stellen Sie sicher, dass Sie im Verzeichnis ~ / .ssh / der centos-Maschine die entsprechende Berechtigung haben.

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

sollte den Trick machen.


41
2017-08-18 11:25



die richtigen Rechte und Dateinamen (manchmal authorized_keys2, manchmal ohne die 2) ist sehr wichtig! - brandstaetter
Die Erlaubnis der Datei authorized_keys ist ein sehr wichtiger Hinweis. Vielen Dank. - Kane
Möglicherweise müssen Sie auch chmod go-w ~/ wenn es nicht schon so ist. - tylerl
Überprüfen Sie auch, ob Ihr Home-Verzeichnis auf dem Remote-Server über Berechtigungen verfügt 755 (wie Jinyu Liu unten erwähnt) - Attila Fulop
In anderen Betriebssystemen könnte die SSH-Konfigurationsdatei auch leben unter: /etc/ssh/ssh_config - Yoshua Wuyts


Ich hatte ein ähnliches Problem - der Remote-PC konnte die Authentifizierung mit öffentlichem Schlüssel nicht verwenden, um sich bei CentOs 6 Server anzumelden. Das Problem in meinem Fall war mit SELinux verbunden - das Home-Verzeichnis des Benutzers, der sich anzumelden versuchte, hatte Sicherheitskontexte für Nachrichten. Ich löste das mit dem restorecon Werkzeug so:

restorecon -Rv /home

16
2018-02-20 23:02



Danke, Gareth! "restorecon - Rv /root/.ssh" hat es gut gemacht. - tbroberg
Zur weiteren Erläuterung: Dieser Befehl teilt SELinux mit, dass die SELinux-Tags für Dateien zurückgesetzt werden sollen /home zu dem, was sie normalerweise im Verzeichnis-Layout für sind /home. - rakslice
Wenn Sie sich als root anmelden, sollte es sein restorecon -Rv /root - zhangyoufu


1- Überprüfen Sie Ihre / etc / ssh / sshd_config, stellen Sie sicher, dass Sie haben

RSAAuthentifizierung ja
PubkeyAuthentifizierung ja

2- Überprüfen Sie das sichere Protokoll von Remote-Computer, suchen Sie das Detail sshd-Daemon-Fehlerprotokoll. z.B. in meinem Ubuntu

# grep 'sshd' / var / log / secure | grep 'Authentifizierung abgelehnt' | Schwanz -5
4. Aug 06:20:22 xxx sshd [16860]: Authentifizierung abgelehnt: Bad Ownership oder Modi für Verzeichnis / home / xxx
4. Aug 06:20:22 xxx sshd [16860]: Authentifizierung abgelehnt: Bad Ownership oder Modi für Verzeichnis / home / xxx
Aug 4 06:21:21 xxx sshd [17028]: Authentifizierung abgelehnt: fehlerhafte Besitzer oder Modi für Verzeichnis / home / xxx
Aug 4 06:21:21 xxx sshd [17028]: Authentifizierung abgelehnt: fehlerhafte Besitzer oder Modi für Verzeichnis / home / xxx
4. Aug 06:27:39 xxx sshd [20362]: Authentifizierung abgelehnt: Bad Ownership oder Modi für Verzeichnis / home / xxx

Dann überprüfen Sie die Eigentümerschaft und Modi für Verzeichnis / home / xxx, vielleicht müssen Sie dies ausführen

chmod 755 / home / xxx

11
2017-08-04 13:53



Check-Log-Datei des Systems ist ein sehr wichtiger Hinweis. - Kane
Das Home-Verzeichnis perms von 755 hat mir geholfen - unbedingt erforderlich! - Ben


Überprüfen Sie, ob Ihre Berechtigungen korrekt sind und die Dateistruktur (insbesondere die Schreibweise) für lokale und Remote-Computer korrekt ist. Die URL, auf die Sie verweisen, gibt alle an, aber es lohnt sich, zu überprüfen, was Sie gefunden haben. Normalerweise werden Berechtigungen einen relevanten Fehler auslösen.

Haben Sie überprüft, ob sshd_config in Ihrer CentOS 5.3-Box auf PubkeyAuthentication oder RSAAuthentication eingestellt ist?

Überprüfen Sie die SSH-Server-Logs auf dem CentOS-System - es kann weitere Informationen liefern. Ich bin mir nicht sicher, ob CentOS den Blacklist-SSH-Schlüssel überprüft, ob Debian das tut, aber ich habe ssh publickey-Ablehnungen gesehen, die relativ leise sind, was die -vvv-Ausgabe angeht, aber die Logs erklärten ziemlich klar, was vor sich ging


10
2017-08-18 04:26





Ich habs! Es stellte sich heraus, dass es sich um ein clientseitiges Problem handelte. (Ich denke, dass jedes serverseitige Problem eine nützlichere Debug-Ausgabe ergeben hätte.) Aus unbekannten Gründen hatte die Datei / etc / ssh_config auf meinem Mac die Zeile

PubkeyAuthentication = no

Ich habe diese eine Zeile auskommentiert, und jetzt funktioniert alles gut.


6
2017-08-18 16:16





Stellen Sie neben den Modi von Dateien / Verzeichnissen sicher, dass die Eigentümerschaft korrekt ist! Ein Benutzer muss sein eigenes Home-Verzeichnis, .ssh /, und Dateien darin besitzen.

Ich musste rennen chown -R $user:$user /home/$user über meine ssh Fehler hinwegkommen.


3
2017-08-23 22:34



+1, auf einem meiner Systeme waren die Berechtigungen für .ssh richtig, aber jemand hatte das Home-Verzeichnis des Kontos 777 erstellt. - GargantuChet


Überprüfen Sie auch, ob es automatisch einen Schlüssel liefern kann oder nicht, verwenden Sie -i Pfad / zu / Schlüssel, wenn nicht oder nur zum Testen


1
2017-08-18 13:17





Klingt nach einem Konfigurationsproblem für mich. Wie Daniel vorgeschlagen hat, gibt es zwei Dinge zu überprüfen:

  1. Der SSH Schlüssel ein $HOME/.ssh/authorized_keys sind lesbar; und
  2. SSHd ist so konfiguriert, dass die Anmeldung mit öffentlichen Schlüsseln zulässig ist.

1
2017-08-18 06:46





Die Ausgabe des Clients wie in ssh -v zeigt an, dass ein Problem bei einem bestimmten Schritt im Protokoll besteht, aber wenn es aufgrund von etwas auf dem Server auftritt, wird der Client nicht über die Ursache informiert. Überprüfen Sie die Serverprotokolldateien, um herauszufinden, was falsch ist. Du musst wahrscheinlich sein root um Berechtigungen dafür zu haben. Zum Beispiel für ein sshd konfiguriert für die Anmeldung bei Syslog, finden Sie möglicherweise die Nachrichten in /var/log/secure. Wie diese:

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

Der Grund war in diesem Fall ein (dummer) Fehler default von 0002. Das bedeutet, Schreibzugriff für die Gruppe. (Gruppenname = Benutzername, aber immer noch.) Der SSH-Daemon wird Dateien nicht vertrauen, die von anderen als dem Benutzer manipuliert werden können (na ja, und root, Na sicher). Sie können das Problem mit beheben chmod.

chmod 700 ~/.ssh # solve the issue
chmod 720 ~/.ssh # reproduce the issue
# or similar for a file

0
2018-02-14 18:52