☰

Verbindung über SSH und Publickey und Benutzer B nicht möglich (Benutzer A kann)

tag-icon • tag-icon ssh login
Verbindung über SSH und Publickey und Benutzer B nicht möglich (Benutzer A kann)

GELÖST.Es war der für die Gruppe beschreibbare Teil user_Bdes Home-Verzeichnisses, der mich ausgetrickst hat.

Mir gehen die Ideen hierzu aus. Ich bin für jeden Hinweis sehr dankbar.

Betrachten Sie dieses Setup:

  • Ein Server Smit Ubuntu, Benutzer boldewynunduser_Auser_B
  • Zwei Laptops Aund B, jeder mit einem lokalen Benutzer boldewyn(hat einen id_rsaSchlüssel zum Anmelden S) und einem zweiten Schlüssel id_rsa_A/ id_rsa_B. Alle Schlüssel sind in gespeichert /home/boldewyn/.ssh. Beide laufen unter Ubuntu.

  • user_Aund user_Bwenn Sdas Passwort leer ist, sollte die Anmeldung nur per Publickey und SSH möglich sein.

    +--------+            +-------------------+            +--------+
| laptop |            |       server      |            | laptop |
|   A    |            |         S         |            |   B    |
|        |            |                   |            |        |
+--------+    SSH     +-------------------+    SSH     +--------+
|id_rsa_A|------------|< user_A   user_B >|------------|id_rsa_B|
+--------+            +-------------------+            +--------+
|id_rsa  |------------|<    boldewyn     >|------------|id_rsa  |
+--------+            +-------------------+            +--------+

Was funktioniert:

  • Melden Sie sich von jedem Laptop aus als boldewyn(mit id_rsaundS:/home/boldewyn/.ssh/authorized_keys

  • AVom Laptop aus als Benutzer anmelden user_A(mit id_rsa_Aund S:/home/user_A/.ssh/authorized_keys: ssh -i id_rsa_A user_A@S)

Mein Problem:Auf dem Laptop Bschlägt genau dasselbe Setup fehl user_B. Ich kann mich nicht anmelden S, weil aus irgendeinem Grund der Schlüssel nicht akzeptiert wird und die Kennwortabfrage kommt ( user_Bhat kein Kennwort, das ist keine Option).

Was ich überprüft habe:

  • Auf dem Laptop B:

    • Die Rechte ~/.sshund den gesamten Inhalt wurden überprüft
    • setze den öffentlichen Teil id_rsa_Bin boldewyns .authorized_keysund ssh -i id_rsa_B boldewyn@S: funktioniert (der Schlüssel ist nicht beschädigt oder so)
    • ssh -vvv: Naja, nicht wirklich hilfreich: Sagt mir nur an einer Stelle, dass es publickeydie Methode jetzt überspringt. Kein Grund angegeben.

  • Auf dem Server S:

    • Dreifach geprüfte user_BS- .authorized_keysDatei
    • Überprüfung der Rechte /home/*/.sshund aller Inhalte (insbesondere Vergleiche user_Aund user_B)
    • Überprüft, ob $HOMEeingestellt ist (über sudo -u user_B -i)
    • Überprüft, ob alle Benutzer in /etc/ssh/sshd_configs AllowUsers(und AllowGroupsübrigens auch in ) sind

Andere Sachen:

user_ADer einzige Unterschied, der mir zwischen und einfällt user_B, ist, dass ich letzteres mit erstellt habe adduser -M(kein Home-Verzeichnis erstellen, es existierte bereits vorher). Ich habe jedoch dreimal überprüft, dass /home/user_Bund alle relevanten untergeordneten Elemente Eigentum von user_Bund seiner primären Gruppe sind.

Antwort1

Hast du das dreimal überprüft?/home/user_B(sowie /home/user_B/.sshund /home/user_B/.ssh/authorized_keys) hatten die entsprechenden Berechtigungen:nicht beschreibbar, außer für den Benutzer, also Modus 755 oder restriktiver?

Antwort2

Ich denke, es könnte mit der Art und Weise zusammenhängen, wie Sie diese Schlüssel generiert haben. Ich würde es noch einmal versuchen. Schlüssel werden mit der Funktion ssh-keygen generiert. Vielleicht wurde beim Generieren eines Schlüsselsatzes eine Passphrase im Generierungsprozess verwendet. Sie könnten versuchen, einfach die Eingabetaste zu drücken, wenn Sie zur Eingabe einer Passphrase aufgefordert werden. Kopieren Sie den Pub-Teil dieses Schlüssels nach Ubuntu. Stellen Sie sicher, dass Sie den fehlerhaften Eintrag in der Datei .ssh/authorized_keys löschen. Ein zweiter Gedanke: Wenn Sie die Pub-Datei caten, stellen Sie sicher, dass Sie ein >> (Anhängen) anstelle von > (Ersetzen_) verwenden, wenn Sie die Pub-Datei in die Datei authorized_keys kopieren. (cat id_rsa.pub >> .ssh/authorized_keys).

Ich bin ein wenig überrascht. Ich habe meine Methoden bei der Arbeit mit Solaris und Cygwin und zu Hause in meinem Linux-LAN mit Centos, Slackware, Debian und Ubuntu verwendet. Ist es möglich, dass Ihr privater Schlüssel nicht mit dem öffentlichen übereinstimmt? Wenn Sie Ihre Schlüssel generieren, erhalten Sie ein Paar, der öffentliche wird traditionell in die Datei .ssh/authorized keys im Home-Verzeichnis des Zielcomputers kopiert. Wenn Sie die Schlüssel erneut generieren, muss die neue .pub-Datei kopiert werden. Der neue private Schlüssel wird nicht mit dem alten öffentlichen gepaart. Mir ist aufgefallen, dass Sie anscheinend einen Ordner .authorized_keys im Home-Verzeichnis haben. Das habe ich nie ausprobiert. Ich denke, die normale Platzierung ist im Ordner /home/user_name/.ssh/authorized_keys. Ich hatte nie Probleme mit irgendeiner Version von Solaris ab etwa 6, Freebsd und verschiedenen Iterationen und Varianten von Linux. Viel Glück

Alan

verwandte Informationen