SSH akzeptiert öffentlichen Schlüssel nicht

31894
Zurahn

Beim Einrichten von ssh-Schlüsseln zwischen zwei Computern funktioniert die Authentifizierung nur auf eine Weise. Ein Server akzeptiert den öffentlichen Schlüssel des anderen nicht, wenn versucht wird, eine Verbindung herzustellen. Irgendwelche Ideen? Hier ist die ausführliche Ausgabe.

debug1: Reading configuration data /usr/local/etc/ssh_config  debug1: Rhosts Authentication disabled, originating port will not be trusted.  debug1: Connecting to xxxxxx.com [xx.xx.xx.xx] port 22.  debug1: Connection established.  debug1: identity file /root/.ssh/identity type -1  debug1: identity file /root/.ssh/id_rsa type 1  debug1: identity file /root/.ssh/id_dsa type -1  debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5  debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*  debug1: Enabling compatibility mode for protocol 2.0  debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2  debug1: SSH2_MSG_KEXINIT sent  debug1: SSH2_MSG_KEXINIT received  debug1: kex: server->client aes128-cbc hmac-md5 none  debug1: kex: client->server aes128-cbc hmac-md5 none  debug1: SSH2_MSG_KEX_DH_GEX_REQUEST 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 'xxxxxx.com' is known and matches the RSA host key.  debug1: Found key in /root/.ssh/known_hosts:17  debug1: ssh_rsa_verify: signature correct  debug1: SSH2_MSG_NEWKEYS sent  debug1: expecting SSH2_MSG_NEWKEYS  debug1: SSH2_MSG_NEWKEYS received  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: /root/.ssh/identity  debug1: Offering public key: /root/.ssh/id_rsa  debug1: Authentications that can continue: publickey,password  debug1: Trying private key: /root/.ssh/id_dsa  debug1: Next authentication method: password

EDIT: Wenn es darauf ankommt, ist dies fürroot

4
Ich gehe davon aus, dass root-Logins in Ihrer sshd_config erlaubt sind? heavyd vor 14 Jahren 0
Ist dies ein spezifisches Problem für diesen Server? Haben Sie bereits erfolgreich die SSH-Schlüsselautorisierung eingerichtet? Doug Harris vor 14 Jahren 0
Es gibt andere Konten, die sich auf diese Weise authentifizieren, einfach nicht root Zurahn vor 14 Jahren 0
Am Ende benutzte ich ein anderes Konto, das funktionierte und Sudoing. Ok, nicht so elegant, aber ich hatte genug Zeit damit verbracht. Zurahn vor 14 Jahren 0

5 Antworten auf die Frage

8
Pada

Ich hatte gerade einen Fall, in dem SELinux verhindert hat, dass sshd die Datei /root/.ssh/authorized_keys liest. / var / log / messages zeigt Ihnen, dass dem sshd-Prozess der Zugriff auf die Datei "authorized_keys" für den Lesevorgang verweigert wurde.

Nachdem ich gelaufen war restorecon -v /root/.ssh/authorized_keys, funktionierte SSH mit dem öffentlichen Schlüssel gut.

In meinen Protokollen wurde nichts verweigert, aber ich habe diesen Befehl trotzdem ausgeführt. Und was weißt du, es hat funktioniert. Vielen Dank! Kaivosukeltaja vor 11 Jahren 0
5
derunbekanntschatten

Das Ändern von StrictModes in "Nein" /etc/ssh/sshd_confighat für mich funktioniert.

sysadmin@suselinux1:~> con sysadmin kaiser Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-25-generic i686)  * Documentation: https://help.ubuntu.com/  Last login: Fri Nov 9 15:40:11 2012 from 10.1.3.25 sysadmin@kaiser:~$ date vie nov 9 17:53:11 CST 2012 sysadmin@kaiser:~$
Anstatt `StrictModes` zu deaktivieren, können Sie stattdessen die Dateiberechtigungen für Dateien in` .ssh` (und im `.ssh'-Verzeichnis selbst) festlegen. Flimm vor 9 Jahren 0
1
radius

Überprüfen Sie die Werte der folgenden Optionen auf dem SSH-Server:

PubkeyAuthentication Yes RSAAuthentication Yes PermitRootLogin Yes
RSAAuthentication ja PubkeyAuthentication ja Zurahn vor 14 Jahren 0
Prüfen Sie, ob PermitRootLogin nicht auf no gesetzt ist. Wenn no eingestellt ist, setzen Sie nopwd radius vor 14 Jahren 0
Es wurde auf "yes" gesetzt und ich habe es in "without-password" geändert und ssh ohne irgendwelche Auswirkungen neu gestartet - es wurde immer noch nach einem Passwort gefragt. Das, mein Freund, ist Entschlossenheit. Zurahn vor 14 Jahren 1
@radius gibt es keine nopwd. Wenn Sie es ohne Kennwort einstellen, wird es nur etwas sicherer, da sie noch einen Schlüssel benötigen. Und trotzdem stehen die Schlüssel trotzdem an erster Stelle. Wenn er nicht mit einem Schlüssel einsteigen kann, kann er trotzdem nicht mit einem Schlüssel einsteigen. Ich weiß nicht, vielleicht hatte er seinen öffentlichen Schlüssel nicht kopiert oder sich nicht als der richtige Benutzer auf dem SSH-Server angemeldet. barlop vor 12 Jahren 0
1
pfrenssen

Mein Schlüssel wurde nicht weitergeleitet. Es stellte sich heraus, dass ich den SSH-Agenten in einem anderen Terminalfenster gestartet hatte. Daher war die $SSH_AUTH_SOCKUmgebungsvariable nicht in dem Terminal verfügbar, in dem ich die Verbindung herstellte.

Wenn Sie den Agenten manuell starten, stellen Sie sicher, dass Sie die Verbindung in derselben Terminalsitzung herstellen.

0
Andy Zhang

Überprüfen Sie die Berechtigung und den Besitzer des .ssh-Ordners, der Datei authorized_key und des Basisordners. Mit /var/log/auth.log erhalten Sie weitere Meldungen, wenn Sie versuchen, sich anzumelden.

`/ var / log / auth.log` auf dem Server, nicht auf dem Client (falls jemand von letzterem ausgeht). Daniel Beck vor 12 Jahren 1

Verwandte Probleme