Muss der ssh-Schlüssel den Namen id_rsa haben?

111

Dieses Problem ist beim Erstellen von Build-Servern mit Authentifizierung mit Schlüsseln mehrmals aufgetreten.

Ich habe mich gefragt, ob jemand anderes diese Erfahrung gemacht hat. Ich habe ein paar Schlüssel für meinen aktuellen Benutzer, die eine Verbindung zu verschiedenen Maschinen herstellen können. Sagen wir machine1 und machine2. 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üsselbinder genannt.

Wenn ich versuche, mich mit Bender zu verbinden, 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 bietet nur den id_rsa-Schlüssel an, wie Sie oben sehen können. Ist das richtig? Wenn ja warum? Wie bekomme ich mehr Schlüssel? Ich weiß, es ist ein Problem, das ich zeitweise sehe, weil ich zu Hause mehrere Schlüssel ohne viel Mühe habe.

Ich würde mich auch über einen Überblick über die Interaktion der öffentlichen und privaten Schlüssel mit dem Client und dem Server freuen. Ich dachte, ich hätte eine ziemlich anständige Idee, aber mir fehlt anscheinend etwas.

Bitte und danke.

    
myusuf3 17.03.2011, 16:37

3 Antworten

138

Standardmäßig sucht ssh nach id_dsa und id_rsa Dateien. Die Schlüssel müssen nicht so benannt werden, Sie können sie genauso gut mykey nennen oder sie sogar in einem anderen Verzeichnis ablegen. Wenn Sie jedoch eine der beiden Aktionen ausführen, müssen Sie den Schlüssel im Befehl ssh explizit wie folgt angeben:

ssh [email protected] -i /path/to/mykey

Wenn ein Befehl -i nicht akzeptiert, z. sshfs , verwenden Sie die Option IdentityFile :

sshfs -o IdentityFile=/path/to/mykey [email protected]:/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 vermuten lässt, sollte der private Schlüssel geheim gehalten werden, und der öffentliche Schlüssel kann der Öffentlichkeit zugänglich gemacht werden.

Die Authentifizierung mit einem öffentlichen Schlüssel funktioniert mit einem öffentlichen und einem privaten Schlüssel. Sowohl der Client als auch der Server verfügen über eigene Schlüssel. Bei der Installation von openssh-server werden die öffentlichen und privaten Schlüssel des Servers automatisch generiert. Für den Kunden müssen Sie dies selbst tun.

Wenn Sie (Client) eine Verbindung mit einem Server herstellen, werden öffentliche Schlüssel ausgetauscht. Sie erhalten die Server und die Server Ihre. 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 dem Client und dem Server abfängt.

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

  • /etc/ssh/sshd_config :
    • AllowUsers oder AllowGroups wurde angegeben, der Serverbenutzer ist jedoch nicht in der Gruppen- oder Benutzerliste aufgeführt (Standardeinstellung ist nicht definiert, sodass sich die Benutzer oder Gruppen beim Anmelden nicht einschränken).
    • DenyUsers oder DenyGroups ist angegeben und Sie befinden sich in der Benutzer- oder Gruppenliste.
    • Sie versuchen, sich als root anzumelden, aber PermitRootLogin ist auf No (Standardwert yes ) gesetzt.
    • PubkeyAuthentication ist auf No gesetzt (Standardeinstellung yes ).
    • AuthorizedKeysFile ist auf einen anderen Speicherort gesetzt, und die öffentlichen Schlüssel werden nicht zu dieser Datei hinzugefügt (Standardwert .ssh/authorized_keys , relativ zum Basisverzeichnis)
  • ~/.ssh/authorized_keys : Ihr öffentlicher Schlüssel wird nicht in dieser Datei hinzugefügt (beachten Sie, dass diese Datei als root-Benutzer gelesen wird)

Verwenden mehrerer Tasten

Es ist nicht ungewöhnlich, mehrere Schlüssel zu verwenden. Anstatt ssh [email protected] -i /path/to/identity_file auszuführen, können Sie die Konfigurationsdatei ~/.ssh/config .

verwenden

Allgemeine Einstellungen sind IdentityFile (die Schlüssel) und Port. Die nächste Konfiguration überprüft "id_dsa" und "bender" nur, wenn eine Verbindung mit ssh [email protected] :

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

Wenn Sie Host yourhost nicht angeben, gelten die Einstellungen für alle SSH-Verbindungen. Für diese Host-Übereinstimmung können auch andere Optionen angegeben werden, wie User youruser , Port 2222 usw. Dies würde Ihnen die Verbindung mit der Kurzschreibweise ssh yourhost anstelle von ssh -p2222 [email protected] -i ~/.ssh/id_dsa -i ~/.ssh/bender ermöglichen.

    
Lekensteyn 17.03.2011, 16:58
32

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

IdentityFile ~/.ssh/%l_%[email protected]%h_id_rsa

SSH ersetzt% l durch den Namen des lokalen Computers,% r durch den Remote-Benutzernamen und% h durch den Remote-Host. Wenn ich also von meinem Computer namens foo to bar als Benutzer eine Verbindung herstellen wollte, führe ich aus:

ssh bar

Und ssh würde automatisch Folgendes verwenden:

~/.ssh/[email protected]_id_rsa

Da der lokale Host ebenfalls gespeichert ist, können Heimatverzeichnisse über NFS (unterschiedlicher Schlüssel pro Rechner!) gemeinsam genutzt werden. Außerdem kann sogar angegeben werden, auf welchem Rechner sich der Schlüssel befinden sollte.

    
Viperfang 19.02.2014 19:54
0

In Anbetracht der Bemerkung von StevenRoose, dass die Festlegung vieler Tasten länger dauert und ich zufällig mit vielen Tasten herumspiele, möchte ich meine persönliche Lösung vorschlagen.

Ich erstelle einen Symlink zu dem Schlüssel, den ich zu diesem Zeitpunkt verwenden möchte, und da sich dies nur selten ändert, je nachdem, an welchem Projekt ich gerade arbeite, bin ich damit zufrieden.

Hier habe ich eine Verknüpfung zu meinen Schlüsseln für Maschinen hergestellt, 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 wirklich schnelles Skript hinzufügen, um zu einem anderen Set zu wechseln, ohne den Befehl ln erneut eingeben zu müssen.

Auch hier ist dies nicht nur für zwei Schlüssel eine Lösung, aber für eine größere Anzahl kann es funktionieren.

    
ajhcasual 04.10.2013 16:43

Tags und Links