So verwenden Sie die Public-Key-SSH-Authentifizierung

18022
Poma

Ich habe 2 ubuntu 12.04 (beta) -Server (node1 und node2) und möchte einen passwortlosen Root-Zugriff zwischen ihnen einrichten. Andere Benutzer sollten keinen Zugriff auf andere Boxen haben. Beachten Sie auch, dass der Standardport von ssh in 220 geändert wird.

Folgendes habe ich getan:

sudo -i cd /root/.ssh ssh-keygen -t rsa # with default name and empty password cat id_rsa.pub > authorized_keys

kopierte dann id_rsa & id_rsa.pub nach node2 und fügte id_rsa.pub zu authorized_keys hinzu. Beide Hosts haben dieselbe Datei /root/.ssh/config:

Host node1 Hostname 1.2.3.4 Port 220 IdentityFile /root/.ssh/id_rsa  Host node2 Hostname 5.6.7.8 Port 220 IdentityFile /root/.ssh/id_rsa

Das Problem ist nun, dass ich bei der ssh node2Eingabe nach dem Passwort gefragt werde. Was kann das Problem sein?

Aktualisieren:

Debug-Informationen zum Client:

debug1: Server host key: RSA *** debug1: Host '[*.*.*.*]:220' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:6 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/id_rsa ((nil)) debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/id_rsa debug1: read PEM private key done: type RSA debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug2: we did not send a packet, disable method debug1: Next authentication method: password

Debug-Informationen auf dem Server:

debug1: userauth-request for user root service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug1: PAM: initializing for "root" debug1: PAM: setting PAM_RHOST to "*.*.*.*" debug1: PAM: setting PAM_TTY to "ssh" debug1: userauth-request for user root service ssh-connection method publickey [preauth] debug1: attempt 1 failures 0 [preauth] debug1: test whether pkalg/pkblob are acceptable [preauth] debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file /root/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK debug1: matching key found: file /root/.ssh/authorized_keys, line 2 Found matching RSA key: **** debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x7f0647b0c1b0 is allowed debug3: mm_request_send entering: type 22 debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth] Postponed publickey for root from *.*.*.* port 38887 ssh2 [preauth]

Berechtigungen:

drwx------ 2 root root 4096 Mar 26 15:34 .ssh  -rw------- 1 root root 840 Mar 26 14:50 authorized_keys -rw-r--r-- 1 root root 225 Mar 26 15:34 config -rw------- 1 root root 1679 Mar 26 14:47 id_rsa -rw-r--r-- 1 root root 2652 Mar 26 14:39 known_hosts

Einige Zeilen aus Konfigurationsdateien:

PermitRootLogin without-password RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile %h/.ssh/authorized_keys UsePAM no # also tried yes
5
Waren Sie zuerst alle anderen Fragen dazu? Es gibt viele Vorschläge, wie Sie dieses Problem beheben können. In der Regel müssen Berechtigungen für .ssh / * und / etc / sshd_config verwendet werden Paul vor 12 Jahren 0
@Paul Yep Ich habe die gelesen (nicht * alle *, um ehrlich zu sein) und nichts Nützliches gefunden Poma vor 12 Jahren 0
Ist das Debugging von der Clientseite aus? Können Sie das Debugging auf der Serverseite aktivieren und sehen, was es nicht mag? Paul vor 12 Jahren 0
Was ist die Erlaubnis für / root selbst? Es wäre besser, wenn Sie Schlüsselpaare eingeben und den öffentlichen Schlüssel zu den Authorized_keys der fernen Seite hinzufügen müssen, anstatt die privaten Schlüssel quer zu kopieren. Bruno vor 12 Jahren 1
@Paul fügte meiner Frage Server-Debug-Informationen hinzu Poma vor 12 Jahren 0
@Bruno / root-Berechtigungen sind wie immer 700 Poma vor 12 Jahren 0
Poma, sind Sie sicher, dass das Server-Debug beendet ist? Das eingefügte Protokoll wird nicht an den Punkt gebracht, an dem es fehlschlägt. Nach dem Verschieben sollte mehr vorhanden sein. Paul vor 12 Jahren 0
@Paul ja das ist die letzte Zeile. An diesem Punkt fragt der ssh-Client nach dem Passwort. Poma vor 12 Jahren 0
Ich sehe in Ihrem Berechtigungsverzeichnis kein id_rsa.pub. Hast du einen auf dem "Client" Rechner? Best Practice würde auch vorschreiben, dass root @ machinea seine id_rsa.pub in machineb kopiert: /root/.ssh/authorized_keys und root @ machineb kopiert seine id_rsa.pub nach machinea: /root/.ssh/authorized_keys. Hier ist ein Kommentarfeld hilfreich (authorized_keys, direkt nach dem Schlüssel, Leerzeichen, dann ein Kommentar). Auch http://askubuntu.com/questions/54670/passwordless-ssh-not-working schlagen vor, dass das Benutzerverzeichnis (/ root?) Über die Berechtigung go + rx verfügt. maxwellb vor 12 Jahren 0

5 Antworten auf die Frage

3
eallrich

Ist das Home-Verzeichnis von Root verschlüsselt (vielleicht durch Ecryptfs)?

Ich hatte ein ähnliches Problem, bei dem die Authentifizierung mit öffentlichen Schlüsseln nicht funktioniert, wenn der Benutzer bereits eine aktive Sitzung hatte. Beim Lesen dieser Frage wurde mir klar, dass ich durch die Verschlüsselung des Home-Verzeichnisses des Benutzers verhindert habe, dass sshd ~ / .ssh / authorised_keys liest, es sei denn, der Benutzer war bereits in einer anderen Sitzung angemeldet (wodurch das Home-Verzeichnis automatisch entschlüsselt würde).

Ich habe das Problem behoben, indem ich zu unverschlüsselten Home-Verzeichnissen gewechselt habe. Danach begann die Authentifizierung mit öffentlichen Schlüsseln.

+1: danke, ich hatte ein Problem mit `.Xauthority 'und ich dachte, es sei verwandt. Es scheint, dass dies das erste Mal ist, dass ich versuche, "ssh" zu meinem anderen PC zu wechseln, ohne eingeloggt zu sein ... Avio vor 12 Jahren 0
1
Michael Hampton

ssh wird mit einem Befehl zum Kopieren des öffentlichen Schlüssels auf den Remote-Server geliefert ssh-copy-id. Es kümmert sich um alle erforderlichen Berechtigungen und verschiedene andere "gotcha" -Probleme.

Beispiel:

ssh-copy-id -i $HOME/.ssh/id_dsa user@server.example.com

Nach dem Kopieren mit ssh-copy-idsollte beim Passwort nicht mehr nach einem Passwort gefragt werden ssh.

0
jakob

Some suggestions:

  • Check the permissions of your /root/.ssh (and its contents
  • Check whether ssh allows root-login and/or public key authentication (/etc/ssh/sshd_config iirc)
  • use ssh -v -v to see more debugging output
Ich habe die schon geprüft. Für mich sieht alles gut aus. Ich habe meine Antwort mit mehr Informationen aktualisiert. Poma vor 12 Jahren 0
0
tuomassalo

Verwenden Sie LogLevel DEBUGin /etc/ssh/sshd_configzu debuggen. Ein mögliches Problem besteht darin, das .sshVerzeichnis zu haben /home/someuser/, wie es unter sein sollte /root/.

0
ansi_lumen

Ich bin darauf gestoßen, weil ich einen verschlüsselten Benutzer auf meinem System hatte. Dies führt die sshd zu der Annahme, dass jedes Benutzerverzeichnis verschlüsselt ist und sich die Datei authorized_keys unter befindet/etc/ssh/username/authorized_keys

Bei mir hat es funktioniert, nachdem ich den berechtigten Schlüssel zu /etc/ssh/username/und dann verschoben habe chown -R username:username /etc/ssh/username/. Komisch genug, dass ich das für jeden Benutzer tun musste, selbst für die nicht verschlüsselten!

Verwandte Probleme