it-swarm.com.de

Die Authentifizierung mit öffentlichem SSH-Schlüssel funktioniert nicht

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

Ich kann mich problemlos über die Kennwortauthentifizierung bei meinem Server anmelden. Ich habe alle Schritte zum Einrichten von PKA durchlaufen (wie unter http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1- beschrieben. ssh-beyondshell.html ), aber wenn ich SSH verwende, weigert es sich, überhaupt eine Überprüfung des öffentlichen Schlüssels zu versuchen. Verwenden des Befehls

ssh -vvv [email protected]

(wobei -vvv die Ausführlichkeit auf das maximale Niveau bringt) Ich erhalte die 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 mit zu erzwingen

ssh -vvv -o PreferredAuthentications=publickey [email protected]

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.

Obwohl der Server angibt, dass er die Publickey-Authentifizierungsmethode akzeptiert und mein SSH-Client darauf besteht, werde ich zurückgewiesen. (Beachten Sie das auffällige Fehlen einer Zeile "Öffentlichen Schlüssel anbieten:" oben.) Irgendwelche Vorschläge?

41
Trey Parkman

Überprüfen Sie, ob Ihre Centos-Maschine über Folgendes verfügt:

RSAAuthentication yes
PubkeyAuthentication yes

in sshd_config

und stellen Sie sicher, dass Sie über die entsprechende Berechtigung für das Verzeichnis ~/.ssh/des Centos-Computers verfügen.

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

sollte den Trick machen.

44
pyhimys

Ich hatte ein ähnliches Problem: Der Remote-PC konnte die Authentifizierung mit öffentlichem Schlüssel nicht verwenden, um sich beim CentOs 6-Server anzumelden. Das Problem in meinem Fall war SELinux-bezogen - das Home-Verzeichnis des Benutzers, der versucht, sich anzumelden, hatte Sicherheitskontexte für Nachrichten. Ich habe dies mit dem Tool restorecon folgendermaßen gelöst:

restorecon -Rv /home
17
Gareth

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

 RSAAuthentication ja 
 PubkeyAuthentication ja 

2- Überprüfen Sie das sichere Protokoll vom Remotecomputer und suchen Sie das detaillierte Fehlerprotokoll des sshd-Dämons. z.B. in meinem Ubuntu

 # grep 'sshd'/var/log/secure | grep 'Authentifizierung abgelehnt' | tail -5 
 4. August 06:20:22 xxx sshd [16860]: Authentifizierung abgelehnt: schlechter Besitz oder Modi für das Verzeichnis /home/xxx[.____.‹Aug 4 06:20:22 xxx sshd [16860 ]: Authentifizierung abgelehnt: fehlerhafter Besitz oder Modi für Verzeichnis /home/xxx[.____.‹Aug 4 06:21:21 xxx sshd [17028]: Authentifizierung abgelehnt: fehlerhafter Besitz oder Modi für Verzeichnis /home/xxx
 4. August 06:21:21 xxx sshd [17028]: Authentifizierung abgelehnt: fehlerhafter Besitz oder Modi für Verzeichnis /home/xxx[.____.‹Aug 4 06:27:39 xxx sshd [20362]: Authentifizierung abgelehnt: schlechter Besitz oder Modi für das Verzeichnis /home/xxx

Überprüfen Sie dann den Besitz und die Modi für das Verzeichnis/home/xxx. Möglicherweise müssen Sie dies ausführen

 Chmod 755 /home/xxx
13
Jinyu Liu

Stellen Sie sicher, dass Ihre Berechtigungen korrekt sind und die Dateistruktur (insbesondere die Rechtschreibung) sowohl für lokale als auch für Remotecomputer korrekt ist. Die URL, auf die Sie verweisen, gibt sie alle an, aber es lohnt sich zu überprüfen, ob Ihre Übereinstimmungen übereinstimmen. Normalerweise werfen Berechtigungen jedoch einen relevanten Fehler aus.

Haben Sie überprüft, ob sshd_config auf Ihrem CentOS 5.3-Feld PubkeyAuthentication oder RSAAuthentication zulässt?

Überprüfen Sie die SSH-Serverprotokolle auf dem CentOS-System. Möglicherweise werden weitere Informationen bereitgestellt. Ich bin mir nicht sicher, ob CentOS den ssh-Schlüssel auf der schwarzen Liste überprüft, den Debian überprüft, aber ich habe ssh publickey-Ablehnungen gesehen, die in Bezug auf die -vvv-Ausgabe relativ leise sind, aber die Protokolle haben ziemlich klar erklärt, was los war

11
Daniel Lawson

Ich habs! Es stellte sich heraus, dass es sich um ein clientseitiges Problem handelte. (Ich denke, dass jedes serverseitige Problem zu einer nützlicheren Debug-Ausgabe geführt hätte.) Aus mir 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.

7
Trey Parkman

Stellen Sie neben den Modi der Dateien/Verzeichnisse sicher, dass der Besitz korrekt ist! Ein Benutzer muss sein eigenes Home-Verzeichnis, .ssh/und die darin enthaltenen Dateien besitzen.

Ich musste laufen chown -R $user:$user /home/$user um meine SSH-Fehler zu überwinden.

4
Visser

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

  1. Die SSH-Tasten in $HOME/.ssh/authorized_keys sind lesbar; und
  2. SSHd ist so konfiguriert, dass die Anmeldung mit öffentlichen Schlüsseln möglich ist.
2
sybreon

Überprüfen Sie den Benutzernamen, mit dem Sie sich anmelden möchten. Standardmäßig ist dies Ihr Benutzername auf dem lokalen Computer.

2
Creotiv

Überprüfen Sie auch, ob ein Schlüssel automatisch bereitgestellt werden kann oder nicht. Verwenden Sie -i Pfad/zu/Schlüssel, wenn nicht oder nur zum Testen

2
Jimsmithkka

ich bin gerade in dem gleichen Problem gefangen, mit Fedora Core 16 auf Cent 5,5 zuzugreifen

die Protokolle und die ausführlichen Protokolle sahen genauso aus

das Problem war der öffentliche Schlüssel. Er hat einige gefälschte Daten erhalten, diese neu generiert und im sshd_server veröffentlicht. Sie sshd_client sendet die Schlüsselinformationen, wird jedoch vom Server nicht erkannt (sie stimmen nicht mit den Schlüsseln in autorisierten Schlüsseln überein.)

1
Freaktor

Die Ausgabe des Clients wie in ssh -v zeigt an, dass in einem bestimmten Schritt des Protokolls ein Problem vorliegt, aber wenn es auf etwas auf dem Server zurückzuführen ist, wird der Client nicht über die Ursache informiert. Überprüfen Sie die Server-Protokolldateien, um herauszufinden, was falsch ist. Sie müssen wahrscheinlich root sein, um die Berechtigung dazu zu haben. Für ein sshd, das für die Protokollierung in Syslog konfiguriert ist, finden Sie die Nachrichten möglicherweise 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 in diesem Fall war ein (dummer) Standardwert default von 0002. Das heißt, Schreibzugriff für die Gruppe. (Gruppenname = Benutzername, aber immer noch.) Der SSH-Dämon vertraut keinen Dateien, die von anderen als dem Benutzer manipuliert werden können (naja, und natürlich root). Sie können das Problem mit chmod lösen.

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