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 mich anzumelden.
Wenn ich jedoch bereits über eine Sitzung mit diesem Server verbunden bin (die Verbindung erfolgt über ein Kennwort), verwendet die folgende Verbindung die Schlüsselauthentifizierung, um die Kennworteingabe zu vermeiden.
Wenn noch keine SSH-Verbindung hergestellt ist, kann ich ohne Eingabe des Kennworts keine Verbindung herstellen.
Das ist für mich wirklich seltsam. Ich habe den MD5 /usr/sbin/sshdzwischen dem neuen Server und dem anderen normalen Server überprüft, er ist derselbe. Dann habe ich einfach den /etc/ssh/sshd_configvom anderen normalen Server auf den neuen Server kopiert und ausgeführt service ssh restart. Das Problem besteht immer noch.
Wie soll ich das beheben?
Antwort1
Überprüfen Sie, 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 dass der Eigentümer für den Ordner und die Dateien korrekt ist (verwenden Sie chownbei Bedarf einen Befehl).
Überprüfen Sie auch den authorized_keysOrdner und die Datei auf dem Server (wahrscheinlich im /root/.sshHome-Ordner des Benutzers, der sich anzumelden versucht), um sicherzustellen, dass ihre Berechtigungen und ihr Besitzer auf die gleiche Weise festgelegt sind.
Bearbeiten: Basierend auf weiterem Feedback (und einigen Vermutungen!) – können Sie überprüfen, /etc/ssh/sshd_configob der folgende Parameter wie unten eingestellt ist. Wenn nicht, versuchen Sie, ihn zu bearbeiten.
AuthorizedKeysFile /home/%u/.ssh/authorized_keys
Beachten Sie, dass dies davon ausgeht, dass Sie sich nicht remote als Root anmelden.
Antwort2
In meinem Fall waren die Berechtigungen für das Home-Verzeichnis 775stattdessen 0755oder niedriger.
Der vollständige Pfad zur Datei authorized_keys, d. h. /home/user/.ssh/muss 0755oder niedriger sein.
Antwort3
Ich habe diesen Fehler bei mir selbst behoben, indem ich ihn id_rsa.pubaus .ssh entfernt habe.
Ich hatte es id_rsavon einer anderen Maschine kopiert und auf mehrere Dummy-Clients verteilt. Daher waren id_rsaes id_rsa.pubeigentlich unterschiedliche Schlüssel, die die Verwendung von id_rsainsgesamt verhinderten.
Es gab jedoch keine Fehlermeldung, die das klar anzeigt. Ich habe es im Wesentlichen zufällig herausgefunden, als ich versuchte, die verschiedenen Maschinen in einen identischen Zustand zu versetzen.
Antwort4
Nach langem Grübeln habe ich die Lösung des Problems gefunden:
Das Home-Verzeichnis des Benutzers darf keine Berechtigung haben 777oder allgemein beschreibbar sein. Wenn dies der Fall ist, schlägt die SSH-Schlüsselüberprüfung fehl und Sie müssen für die Anmeldung ein Passwort eingeben.