Frage Muss der ssh-Schlüssel id_rsa heißen?


Ich bin auf dieses Problem einige Male gestoßen, als ich Build Server mit Keyed Authentication erstellte.

Ich habe mich gefragt, ob jemand anderes diese Erfahrung gemacht hat. Ich habe ein paar Schlüssel für meinen aktuellen Benutzer, der sich mit verschiedenen Rechnern verbinden kann. Sagen wir Maschine1 und Maschine2. Ich habe meinen öffentlichen Schlüssel in die entsprechende authorized_keys-Datei eingefügt. Den ersten habe ich den ersten Schlüssel id_rsa und den zweiten Schlüssel Bender genannt.

Wenn ich versuche, mich mit bender zu verbinden, erhalte ich die folgende Ausgabe mit meiner ausführlichen ssh-Verbindung

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
debug1: Next authentication method: publickey
debug1: Trying private key: /home/bozo/.ssh/.ssh/identity
debug1: Trying private key: /home/bozo/.ssh/.ssh/id_rsa
debug1: Trying private key: /home/bozo/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).

Es bietet nur den Schlüssel id_rsa, wie Sie oben sehen können. Ist das richtig? Wenn ja warum? Wie bekomme ich es, mehr Schlüssel anzubieten? Ich weiß, dass es ein Problem ist, das ich mit Unterbrechungen sehe, weil ich zu Hause mehrere Schlüssel ohne große Probleme habe.

Ich würde auch einen Überblick darüber schätzen, wie der Pub und die privaten Schlüssel mit dem Client und dem Server interagieren. Ich dachte, ich hätte eine ziemlich gute Idee, aber anscheinend vermisse ich etwas.

Bitte und Danke.


110
2018-03-17 15:37


Ursprung




Antworten:


Standardmäßig sucht ssh nach id_dsa und id_rsa Dateien. Die Schlüssel müssen nicht so benannt werden, Sie können sie benennen mykey genauso gut, oder legen Sie es sogar in ein anderes Verzeichnis. Wenn Sie jedoch einen dieser Befehle ausführen, müssen Sie wie folgt explizit auf den Schlüssel im ssh-Befehl verweisen:

ssh user@server -i /path/to/mykey

Wenn ein Befehl nicht akzeptiert wird -i, z.B. sshfs, benutze die IdentityFile Möglichkeit:

sshfs -o IdentityFile=/path/to/mykey user@host:/path/on/remote /mountpoint

Wie es funktioniert

Wenn Sie einen Schlüssel generieren, erhalten Sie zwei Dateien: id_rsa (privater Schlüssel) und id_rsa.pub (Öffentlicher Schlüssel). Wie ihre Namen andeuten, sollte der private Schlüssel geheim gehalten und der öffentliche Schlüssel öffentlich veröffentlicht werden.

Die Public-Key-Authentifizierung funktioniert mit einem öffentlichen und einem privaten Schlüssel. Sowohl der Client als auch der Server haben ihre eigenen Schlüssel. Bei der Installation openssh-server Die öffentlichen und privaten Schlüssel des Servers werden automatisch generiert. Für den Kunden müssen Sie das selbst machen.

Wenn Sie (Client) eine Verbindung mit einem Server herstellen, werden öffentliche Schlüssel ausgetauscht. Sie erhalten die Server eins und den Server Ihres. Wenn Sie den öffentlichen Schlüssel des Servers zum ersten Mal erhalten, werden Sie aufgefordert, ihn zu akzeptieren. Wenn sich dieser öffentliche Schlüssel im Laufe der Zeit ändert, werden Sie gewarnt, weil ein möglicher MITM-Angriff (Man in the middle) stattfindet, der den Verkehr zwischen dem Client und dem Server abfängt.

Der Server prüft, ob Sie eine Verbindung herstellen dürfen (definiert in /etc/ssh/sshd_config) und wenn Ihr öffentlicher Schlüssel in der Liste aufgeführt ist ~/.ssh/authorized_keys Datei. Mögliche Gründe, warum der öffentliche Schlüssel abgelehnt wurde:

  • /etc/ssh/sshd_config:
    • AllowUsers oder AllowGroups ist angegeben, aber Ihr Serverbenutzer ist nicht in der Liste der Gruppen oder Benutzer aufgeführt (Standard nicht definiert, keine Einschränkung für die Anmeldung von Benutzern oder Gruppen).
    • DenyUsers oder DenyGroups ist angegeben und Sie befinden sich in der Liste der Benutzer oder Gruppen.
    • Du versuchst dich als root anzumelden, aber PermitRootLogin ist eingestellt auf No (Standard yes).
    • PubkeyAuthentication ist eingestellt auf No (Standard yes).
    • AuthorizedKeysFile wird an einem anderen Speicherort festgelegt und die öffentlichen Schlüssel werden dieser Datei nicht hinzugefügt (Standard .ssh/authorized_keys, relativ zum Heimverzeichnis)
  • ~/.ssh/authorized_keys: Ihr öffentlicher Schlüssel wird in dieser Datei nicht hinzugefügt (beachten Sie, dass diese Datei als root-Benutzer gelesen wird)

Verwenden mehrerer Schlüssel

Es ist nicht ungewöhnlich, mehrere Schlüssel zu verwenden. Anstatt zu rennen ssh user@host -i /path/to/identity_filekönnen Sie eine Konfigurationsdatei verwenden, ~/.ssh/config.

Allgemeine Einstellungen sind die IdentityFile (die Schlüssel) und der Port. Die nächste Konfiguration prüft "id_dsa" und "bender" nur beim Verbinden mit ssh youruser@yourhost:

Host yourhost
   IdentityFile ~/.ssh/id_dsa
   IdentityFile ~/.ssh/bender

Wenn Sie weglassen Host yourhostDie Einstellungen gelten für alle SSH-Verbindungen. Andere Optionen können ebenfalls für diese Hostübereinstimmung angegeben werden, wie z User youruser, Port 2222usw. Dies würde Ihnen erlauben, sich mit der Kurzschrift zu verbinden ssh yourhost Anstatt von ssh -p2222 youruser@yourhost -i ~/.ssh/id_dsa -i ~/.ssh/bender.


136
2018-03-17 15:58



Warum muss ich den Schlüssel angeben? Der springende Punkt ist, dass ich die Maschine einfacher an die Maschine anschließen kann. - myusuf3
@StevenRoose von ssh_config(5): Der Dateiname kann die Tildesyntax verwenden, um auf das Basisverzeichnis eines Benutzers oder eines der folgenden Escapezeichen zu verweisen: '% d' (Heimatverzeichnis des lokalen Benutzers), '% u' (lokaler Benutzername), '% l' (lokal Hostname), '% h' (Name des entfernten Hosts) oder '% r' (Name des entfernten Benutzers). Es ist nicht möglich, Wildcards anzugeben, aber das sollte bequem genug sein, denke ich. Beachten Sie, dass ein Server jeden von Ihnen gesendeten Schlüssel prüfen muss. Daher ist die Angabe von weniger Schlüsseln besser. Wildcards auf Host arbeiten, siehe auch die Manpage von ssh_config(5). - Lekensteyn
@therobyouknow Sie müssen kein eindeutiges Schlüsselpaar für jede Maschine erstellen. Normalerweise haben Sie nur wenige Schlüssel und hängen den öffentlichen Schlüssel eines der Schlüssel an .ssh/authorized_keys Datei auf den Remote-Rechnern. Wenn Sie den Standard verwenden .ssh/id_rsa Dateiname (oder id_dsa, id_ecdsa oder die letzte id_ed25519), dann versucht ssh dies automatisch und Sie müssen nicht angeben IdentityFile in deiner Konfiguration (oder der -i path/to/id_file Parameter für ssh). - Lekensteyn
Ich liebe Antworten, die über das erforderliche Detail hinausgehen und sich die Zeit nehmen, das Konzept zu erklären. Wunderbare Arbeit! +1 - user2490003
@landed Es ist der Host des SSH-Servers (es könnte eine IP-Adresse oder ein DNS-Name sein). Ich habe versucht, diesen Abschnitt zu klären, hoffentlich hilft es. - Lekensteyn


Bei meiner bevorzugten Methode kann der private Schlüssel automatisch ausgewählt werden

IdentityFile ~/.ssh/%l_%r@%h_id_rsa

SSH ersetzt% l durch den Namen der lokalen Maschine,% r durch den Remote-Benutzernamen und% h durch den Remote-Host. Wenn ich also eine Verbindung von meinem Rechner namens foo zu bar als Benutzer herstellen möchte, führe ich Folgendes aus:

ssh bar

Und ssh würde automatisch verwenden:

~/.ssh/foo_user@bar_id_rsa

Da der lokale Host ebenfalls gespeichert wird, können Stammverzeichnisse über NFS gemeinsam genutzt werden (unterschiedlicher Schlüssel pro Maschine!) Oder sogar angegeben werden, auf welcher Maschine der Schlüssel sein sollte ...


30
2018-02-19 18:54





In Anbetracht von StevenRoose's Kommentar, dass es viel länger dauert, um viele Schlüssel zu spezifizieren, und ich zufällig mit vielen Schlüsseln herumspiele, möchte ich meine persönliche Lösung vorschlagen.

Ich erstelle einen Symlink zu dem Schlüssel, den ich zu der Zeit benutzen möchte, und da sich das nur selten ändert, abhängig davon, an welchem ​​Projekt ich gerade arbeite, bin ich damit zufrieden.

Hier habe ich meine Schlüssel für Maschinen, die unter virtualbox laufen, verlinkt:

$ cd .ssh/
$ ln -s adam_vbox-id_rsa.pub id_rsa.pub
$ ln -s adam_vbox-id_rsa id_rsa

$ ls -l
total 12
-rw------- 1 adam adam 1675 2013-10-04 02:04 adam_vbox-id_rsa
-rw-r--r-- 1 adam adam  396 2013-10-04 02:04 adam_vbox-id_rsa.pub
lrwxrwxrwx 1 adam adam   16 2013-10-04 02:17 id_rsa -> adam_vbox-id_rsa
lrwxrwxrwx 1 adam adam   20 2013-10-04 02:17 id_rsa.pub -> adam_vbox-id_rsa.pub
-rw-r--r-- 1 adam adam 3094 2013-10-04 02:09 known_hosts

Man könnte auch ein wirklich schnelles Skript hinzufügen, um auf ein anderes Set umzusteigen, ohne das Manuell eingeben zu müssen ln Befehl erneut.

Auch dies ist keine Lösung für zwei Schlüssel, aber für eine größere Anzahl könnte es praktikabel sein.


0
2017-10-04 14:43



Ich füge einfach einen Alias ​​von bash_profile für jeden Server, mit dem ich arbeite. Also für einen Server namens bob habe ich nur das ... alias bob = "ssh bob.beispiel.com -l pete -i / pfad / zu / schlüssel" - dann tippe ich einfach bob - und ich bin dabei! - Peter Bagnall
Während es manchmal einfacher ist, "Dinge so zu erledigen, wie Sie es bereits wissen", gibt es einfachere Ansätze, wenn Sie .ssh / configs Schlüssel und Hosts einrichten. Dieser Kommentar bezieht sich sowohl auf das Kommentarposter als auch auf den Kommentator @ Peter-Bagnall - Crossfit_and_Beer