Frage Bestes System für die Verwaltung von SSH-Schlüsseln? [geschlossen]


Ich habe mehrere Client-Computer (z. B. Laptops, Desktops usw.), und ich verbinde mich mit mehreren Server-Computern, die ich verwalte, und ich melde mich über SSH bei ihnen an. Ich kann mir mehrere Schemata vorstellen, die ssh-Schlüssel verwalten, die Sinn ergeben, und ich bin neugierig darauf, was andere tun.

Option 1: Ein globales öffentliches / privates Schlüsselpaar.

Ich würde ein öffentliches / privates Schlüsselpaar generieren und den privaten Schlüssel auf jedem Clientcomputer und den öffentlichen Schlüssel auf jedem Servercomputer platzieren.

Option 2: Ein Schlüsselpaar pro Server-Maschine.

Ich würde ein Schlüsselpaar auf jedem Server-Rechner erzeugen und jeden privaten Schlüssel auf meinen Client-Rechnern ablegen.

Option 3: Ein Schlüsselpaar pro Client-Maschine.

Jeder Clientcomputer hat einen eindeutigen privaten Schlüssel, und jeder Servercomputer verfügt über die öffentlichen Schlüssel für jeden Clientcomputer, mit dem ich eine Verbindung herstellen möchte.

Option 4: Ein Schlüsselpaar pro Client / Server-Paar

Völlig über Bord?

Welches ist das Beste? Gibt es andere Möglichkeiten? Nach welchen Kriterien bewerten Sie die richtige Konfiguration?


40
2018-05-27 22:32


Ursprung




Antworten:


ich benutze Option 3: Ein Schlüsselpaar pro Client-Maschine und es macht mir am meisten Sinn. Hier sind einige der Gründe:

  • Wenn ein Client kompromittiert wird, muss dieser Schlüssel (und nur dieser Schlüssel) von den Servern entfernt werden.
  • Es ist flexibel genug, um zu entscheiden, auf was ich von wo aus zugreifen kann, ohne dass von allen Clients ein pauschaler Zugriff auf alle Server gewährt wird.
  • Sehr angenehm. Es gibt nur einen Schlüssel für ssh-add, keine Verwirrung.
  • Einfach einzurichten und zu verwalten Option 4

Option 4 ist nett, aber ist einfach zu viel Arbeit. Option 3 bekommt man 98% dort mit viel weniger Aufwand.


32
2018-05-27 22:44



Ich verstehe den Punkt von Option 4 nicht. Er dient überhaupt keinem Zweck. - niXar


Ich verwende eine Lösung, die etwas komplizierter, aber vielseitiger ist, da ich eine gewisse Trennung in SSH-Identitätsschlüsseln für Heimnetzwerkserver, Office-Server, Consulting-Clientnetzwerkserver und andere Systeme, auf denen ich Konten habe, beibehalten möchte.

Nun gesagt, ich arbeite fast ausschließlich von Linux-Workstations, also habe ich einen USB-Schlüssel, der mit LUKS-Verschlüsselung eingerichtet ist und mein X11-Window-Manager zusammen mit dem HAL-Daemon das LUKS-verschlüsselte Laufwerk erkennt und zur Entschlüsselungs-Passphrase auffordert montiert sein. Indem ich diese auf einem verschlüsselten Laufwerk so ablege, wie ich es tue, speichere ich niemals meine SSH-Schlüssel auf irgendeiner Arbeitsstation.

Ich habe dann folgende Konfiguration in meinem ~/.ssh/config Datei:

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

Das % d wird von OpenSSH in das Home-Verzeichnis des Benutzers übersetzt und in der ~ / .ssh Verzeichnis, das ich erstellt habe Schlüssel.d als Symlink zum Verzeichnispfad auf dem verschlüsselten USB-Laufwerk, wenn es ordnungsgemäß installiert ist.

Das % l Der Ausdruck wird in den Hostnamen des lokalen Client-Rechners übersetzt % u wird in den lokalen Benutzernamen des Kunden übersetzt.

Mit dieser Konfiguration kann SSH mithilfe von 3 verschiedenen Ausdrücken nach einem Schlüssel suchen. Zum Beispiel, wenn der Benutzername meines lokalen Kunden war jdoeund mein lokaler Client-Computername war examplehost Es würde in der folgenden Reihenfolge aussehen, bis es einen Schlüssel gefunden hat, der sowohl vorhanden als auch vom Remoteserver akzeptiert wurde.

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

Du könntest sogar die benutzen % r Ausdruck, um nach einem Schlüssel zu suchen, der für den Benutzernamen des fernen Servers spezifisch ist oder % h für den Hostnamen des Remote-Servers wie % u und % l wurden benutzt.

Update: Jetzt nutze ich den gpg-agent GnuPG mit ssh-agent compatibility, um einfach den Authentifizierungsschlüssel meiner OpenPGP v2 Smartcard zu lesen und zu benutzen.


26
2018-06-11 02:14



Wow, tolle Lösung, danke! Ich liebe die universelle Konfiguration in ~ / .ssh / config - slacy
Es hat sich als sehr praktisch erwiesen, die Dinge getrennt zu halten für Arbeit, persönliche und beratende Client-Netzwerk-Server ... Ich möchte nicht die Authentifizierung zwischen ihnen mischen, sondern möchte auch, dass es für mich einfach ist. - Jeremy Bouse
Tolle! Ich liebe diesen hier wirklich. - balu
Ich nehme an, Sie verwenden verschiedene USB-Schlüssel für verschiedene Client-Rechner. Sonst was ist der Punkt in separaten Schlüsseln, wenn alle von ihnen an der gleichen Stelle gespeichert sind? Im Falle eines Verstoßes müssten Sie alle widerrufen. Wenn (und wahrscheinlich) ich etwas vermisse, scheint dies die Dinge nur zu komplizieren. - Halil Özgür
@ HalilÖzgür, Ja ich berate und möchte nicht immer den gleichen Schlüssel benutzen. Da der USB-Schlüssel verschlüsselt ist und nicht mit einem Computer verbunden ist, es sei denn, dass er eine Verbindung herstellen muss, besteht keine Gefahr, dass der Server verletzt wird und die Passphrase zum Entschlüsseln des Laufwerkdateisystems ausreichend lang genug ist, um die Schlüssel zu entziehen. - Jeremy Bouse


Ich würde beide Optionen eliminieren (von denen ich vermute, dass sie Option 2 sein sollten ;-), da private Schlüssel sensible Daten sind und es sinnvoll ist, sie an möglichst wenigen Stellen zu speichern. Ich persönlich würde niemals einen privaten Schlüssel von einem Computer zu einem anderen (oder sogar von einer Datei zu einer anderen auf demselben Computer) kopieren, außer vielleicht um Sicherungen zu erstellen. Obwohl im Gegensatz zu den meisten Verschlüsselungsschlüsseln, wenn ein SSH-Schlüssel verloren geht, ist es nicht das Ende der Welt (einfach ein neues erstellen, du verlierst keine Daten).


6
2018-05-27 23:07



Ja, in eine richtige "Option 2" umbenannt Ich mag die Regel "kopiere nie einen privaten Schlüssel". Das ist eine gute Regel. - slacy


Option 3 und verwenden Sie etwas wie Puppet, um die Schlüsselverwaltung zu handhaben.


1
2018-05-27 23:41



Ist das reductivabls.com/trac/puppet/wiki/PuppetEinführung der Link zu Puppet? - Andy
Ja das ist es. Achten Sie darauf, einige der Beispiele auf der Website zu überprüfen. Hilft zu sehen, was andere bereits getan haben - keine Notwendigkeit, das Rad neu zu erfinden. - diq


Option 3

Auf diese Weise können Sie auch steuern, auf welche Server ein Client zugreifen kann. z.B. Wenn Client X Zugriff auf Server A und B, aber C oder D benötigt, kopieren Sie seinen öffentlichen Schlüssel nur auf diese Hosts.


1
2018-05-31 06:10