Der OpenSSH-Server akzeptiert keine Schlüsselauthentifizierung


13

Ich habe versucht, die Authentifizierung mit öffentlichem Schlüssel auf meinem neuen Server zu verwenden, und bin auf dieses Problem gestoßen.

$ ssh -v -i .ssh/server 192.168.1.100
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data .ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.1.100 [192.168.1.100] port 22.
debug1: Connection established.
debug1: identity file .ssh/server type -1
debug1: identity file .ssh/server-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '192.168.1.100' is known and matches the RSA host key.
debug1: Found key in .ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: .ssh/server
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

und dann muss ich mein Passwort eingeben, um angemeldet zu werden.

Wenn ich jedoch bereits eine Sitzung mit diesem Server verbunden habe (der über ein Kennwort verbunden ist), verwendet die folgende Verbindung die Schlüsselauthentifizierung, um eine Kennworteingabe zu vermeiden.

Wenn noch keine SSH-Verbindung besteht, kann ich keine Verbindung ohne eingegebenes Kennwort herstellen.

Das ist wirklich komisch für mich, ich habe das MD5 /usr/sbin/sshdzwischen dem neuen Server und dem anderen normalen Server überprüft , es ist das gleiche. Dann habe ich einfach den /etc/ssh/sshd_configvom anderen normalen Server auf den neuen Server kopiert und lief service ssh restart. Das Problem besteht immer noch.

Wie soll ich das beheben?

Antworten:


10

Stellen Sie sicher, dass Ihr .sshOrdner und die darin enthaltenen Dateien auf dem Client-Computer nur vom Eigentümer ( chmod -R 600 .ssh) gelesen werden können und der Eigentümer für den Ordner und die Dateien korrekt ist (verwenden Sie chownggf. den Befehl).

Überprüfen Sie auch den authorized_keysOrdner und die Datei auf dem Server (möglicherweise im /root/.sshoder im Ausgangsordner des Benutzers, der sich anmelden möchte), um sicherzustellen, dass seine Berechtigungen und sein Besitzer auf die gleiche Weise festgelegt sind.


Bearbeiten: basierend auf mehr Feedback (und einigen Vermutungen!) - können Sie überprüfen, /etc/ssh/sshd_configob der folgende Parameter wie folgt eingestellt ist. Wenn nicht, versuchen Sie es zu bearbeiten.

AuthorizedKeysFile /home/%u/.ssh/authorized_keys

Beachten Sie, dass Sie sich nicht remote als root anmelden


Mein .ssh ist 700 und die Dateien in .ssh sind 600, und ich habe ~ / .ssh / authorized_keys in der entfernten Maschine doppelt überprüft. Das Einrichten der öffentlichen Schlüsselauthentifizierung ist das erste, was ich nach der Installation des Systems mache. Daher ist es unwahrscheinlich, dass andere Vorgänge zu Problemen führen. Übrigens, Problem immer noch ..
Lxyu

OK - Ich füge meiner Antwort etwas hinzu, das darauf basiert.
Linker3000

Es gibt eine Zeile mit "#AuthorizedKeysFile% h / .ssh / authorized_keys". Ich habe versucht, es zu kommentieren, aber es hat keinen Sinn. Übrigens, dasselbe '/ usr / sbin / sshd' mit demselben 'sshd_config', wie verhalten sie sich anders?
Lxyu

Schließlich habe ich ubuntu neu installiert, dann habe ich in einer Minute den openssh-server eingerichtet und es funktioniert jetzt einwandfrei ... Ich weiß immer noch nicht, was los ist. :(
lxyu

Manchmal ist es wirklich schwierig herauszufinden, wo das Problem liegt. Ich habe einmal authorized_keys als auhorized_keys falsch geschrieben. Ich brauchte ungefähr eine Stunde, um das Problem zu beheben. Hast du die Rechtschreibung gesehen? Es ist wirklich knifflig! :-)
nalply

4

Ich habe meinen eigenen Fehler id_rsa.pubbehoben, indem ich aus .ssh entfernt habe.

Ich hatte id_rsavon einem anderen Computer kopiert und es auf mehrere Dummy-Clients verteilt. Daher gab id_rsaund id_rsa.pubgab es eigentlich verschiedene Schlüssel, die die Verwendung id_rsainsgesamt verhinderten.

Keine Fehlermeldung, die dies jedoch deutlich anzeigt. Ich habe es im Wesentlichen durch Zufall herausgefunden und versucht, die verschiedenen Maschinen in einen identischen Zustand zu versetzen.


3

Meines Erachtens ist die geringste Erlaubnis des Heimdirektors des Ziels 750. Wenn das nicht der Fall ist 0, wird es nicht funktionieren.

Z.B. Für das Stammverzeichnis:

drwxr-x--- 3 root root 4096 Jul 20 11:57 root

Der nächste ist /root/.ssh

drwx------  2 root root  4096 Jul 17 03:28 .ssh

Dann /root/.ssh/authorized_keys

-rw------- 1 root root 1179 Jul 17 03:28 authorized_keys

3

In meinem Fall waren die Berechtigungen für das Basisverzeichnis 775anstelle von 0755oder niedriger.

Der gesamte Pfad zur Datei authorized_keys, dh /home/user/.ssh/muss kleiner 0755oder gleich sein.


DANKE Ich habe gerade von Kopfschmerzen gelesen, die ich seit einer Woche habe. Die meisten Leute erwähnen nur den .ssh-Ordner (700) und die authorized_keys (600)
Jonathan Komar

2

Nachdem ich mich sehr bemüht hatte, bekam ich die Lösung des Problems:

Das Home-Verzeichnis des Benutzers sollte keine Berechtigung haben 777oder von der Welt beschreibbar sein. In diesem Fall schlägt die SSH-Schlüsselüberprüfung fehl und Sie müssen ein Kennwort für die Anmeldung eingeben.


1

Stellen Sie einfach sicher, dass das Konto, mit dem Sie versuchen, zu ssh zu werden, ein Benutzer mit einem Kennwort auf dem Remote-Server ist. Ich habe gerade eine halbe Stunde lang meinen Kopf gegen die Wand geschlagen, bevor ich diese Antwort hier gefunden habe: /programming//a/14421105/758174


1

Wenn in Ihrer /etc/ssh/sshd_configSSH-Konfiguration die folgende Zeile nicht kommentiert ist, kann nur eine feste Benutzerliste in das System aufgenommen werden, und Sie müssen der Liste neue Konten hinzufügen:

AllowUsers root user1 user2 user3

Alle anderen Benutzer als die oben aufgeführten, die versuchen, sich über SSH anzumelden, erhalten diese kryptischen Fehlermeldungen:

Roaming not allowed by server

0

Ich habe herausgefunden, dass ich nach dem Ändern meines Benutzer- und Gruppennamens (aber nicht der IDs) in /etc/passwdund /etc/group, ohne dies zu ändern /etc/shadow, dieselbe Meldung "Kein Roaming erlaubt" erhalten habe.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.