Muss der SSH-Schlüssel id_rsa heißen?

Ich bin ein paarmal auf dieses Problem gestoßen, als ich Build-Server mit verschlüsselter Authentifizierung erstellt habe.

Ich habe mich gefragt, ob das jemand anderes erlebt hat. Ich habe ein paar Schlüssel für meinen aktuellen Benutzer, die möglicherweise eine Verbindung zu verschiedenen Computern herstellen. Sagen wir machine1 und machine2. Ich habe meinen öffentlichen Schlüssel in die jeweilige authorized_keys-Datei eingefügt. Das erste habe ich den ersten Schlüssel id_rsa und den zweiten Schlüsselbieger genannt.

Wenn ich versuche, eine Verbindung zu Bender herzustellen, erhalte ich mit meiner ausführlichen ssh-Verbindung die folgende Ausgabe

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 wird nur der Schlüssel id_rsa angeboten, wie Sie oben sehen können. Ist das richtig? Wenn ja warum? Wie kann ich dafür sorgen, dass mehr Schlüssel angeboten werden? Ich weiß, dass es ein Problem ist, das ich zeitweise sehe, weil ich zu Hause ohne große Probleme mehrere Schlüssel habe.

Ich würde mich auch über eine Übersicht darüber freuen, wie der Pub- und der private Schlüssel mit dem Client und dem Server interagieren. Ich dachte, ich hätte eine ziemlich gute Idee, aber anscheinend fehlt mir etwas.

Bitte und Dankeschön.

Standardmäßig sucht ssh nach id_dsaund id_rsaDateien. Die Schlüssel müssen nicht so benannt werden, Sie können sie mykeygenauso gut benennen oder sie sogar in einem anderen Verzeichnis ablegen. Wenn Sie jedoch einen dieser Schritte ausführen, müssen Sie den Schlüssel im Befehl ssh wie folgt explizit referenzieren:

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

Wenn ein Befehl nicht akzeptiert wird -i, verwenden Sie z. B. sshfsdie IdentityFileOption:

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

Wie es funktioniert

Beim Generieren eines Schlüssels erhalten Sie zwei Dateien: id_rsa(privater Schlüssel) und id_rsa.pub(öffentlicher Schlüssel). Wie der Name schon sagt, sollte der private Schlüssel geheim gehalten und der öffentliche Schlüssel öffentlich veröffentlicht werden.

Die Authentifizierung mit öffentlichem Schlüssel 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-serverdes Servers werden öffentliche und private Schlüssel automatisch generiert. Für den Kunden müssen Sie das selbst tun.

Wenn Sie (Client) eine Verbindung mit einem Server herstellen, werden öffentliche Schlüssel ausgetauscht. Sie erhalten einen Server und Ihren Server. 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, da ein möglicher MITM-Angriff (Man in the middle) stattfindet, der den Datenverkehr zwischen Client und Server abfängt.

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

• /etc/ssh/sshd_config:
  • AllowUsersoder AllowGroupsist angegeben, aber Ihr Serverbenutzer ist nicht in der Gruppen- oder Benutzerliste aufgeführt (standardmäßig nicht definiert, wodurch die Anmeldung der Benutzer oder Gruppen nicht eingeschränkt wird).
  • DenyUsersoder DenyGroupsist angegeben und Sie befinden sich in der Benutzer- oder Gruppenliste.
  • Sie versuchen, sich als root anzumelden, sind jedoch PermitRootLoginauf No(Standard yes) gesetzt.
  • PubkeyAuthenticationist auf No(Standard yes) eingestellt.
  • AuthorizedKeysFileist auf einen anderen Speicherort festgelegt und die öffentlichen Schlüssel werden dieser Datei nicht hinzugefügt (Standardeinstellung .ssh/authorized_keys, relativ zum Basisverzeichnis)
• ~/.ssh/authorized_keys: Ihr öffentlicher Schlüssel wird in dieser Datei nicht hinzugefügt (beachten Sie, dass diese Datei als Root-Benutzer gelesen wird)

Verwendung mehrerer Schlüssel

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

Allgemeine Einstellungen sind das IdentityFile (die Schlüssel) und der Port. Die nächste Konfiguration überprüft "id_dsa" und "bender" nur, wenn eine Verbindung hergestellt wird mit ssh youruser@yourhost:

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

Wenn Sie nichts angeben Host yourhost, gelten die Einstellungen für alle SSH-Verbindungen. Andere Optionen können auch für dieses Host Spiel angegeben werden, wie User youruser, Port 2222etc. Auf diese Weise könnten Sie mit der Stenographie verbinden ssh yourhoststatt ssh -p2222 youruser@yourhost -i ~/.ssh/id_dsa -i ~/.ssh/bender.

Meine bevorzugte Methode ermöglicht die automatische Auswahl des privaten Schlüssels

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

SSH ersetzt% l durch den lokalen Computernamen,% r durch den entfernten Benutzernamen und% h durch den entfernten Host. Wenn ich also eine Verbindung von meinem Computer 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 ist, können private Verzeichnisse über NFS gemeinsam genutzt werden (unterschiedlicher Schlüssel pro Computer!) Oder sogar ermittelt werden, auf welchem ​​Computer sich der Schlüssel befinden sollte ...

In Anbetracht des Kommentars von StevenRoose, dass die Angabe vieler Schlüssel länger dauert 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 gerade verwenden möchte, und da sich dieser nur selten ändert, je nachdem an welchem ​​Projekt ich arbeite, bin ich damit zufrieden.

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

$ 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

Sie können auch ein sehr schnelles Skript hinzufügen, um zu einem anderen Satz zu wechseln, ohne den Befehl ln erneut manuell eingeben zu müssen.

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