it-swarm-eu.dev

Was ist die übliche pragmatische Strategie für die Verwaltung von Schlüsselpaaren?

Ich habe eine kleine Anzahl verschiedener Workstations (plus Client-Geräte wie das iPhone), mit denen ich über SSH eine Verbindung zu zahlreichen Servern herstellen kann.

Als ich ursprünglich von PKI erfuhr, erstellte ich auf meiner Workstation ein einzelnes Schlüsselpaar, das ich sofort von überall aus verwendete (dh ich kopierte es auf meinen Laptop usw.) und verwendete es für die Verbindung mit allen meinen Serverkonten.

Seitdem habe ich die Meinung entwickelt, dass dies mit der Verwendung eines einzelnen Passworts überall vergleichbar ist, und ich muss möglicherweise den Zugriff selektiv widerrufen, z. wenn einer meiner Workstations kompromittiert ist.

Grundsätzlich versuche ich, eine persönliche Strategie für den Umgang mit Schlüsselpaaren zu entwickeln:

Was ist der richtige Weg, um Schlüsselpaare für den allgemeinen Gebrauch sicher zu denken und gleichzeitig für die Benutzerfreundlichkeit pragmatisch zu bleiben? (d. h. ich denke nicht, dass Einwegschlüsselpaare für jeden Verbindungspunkt notwendigerweise auch Sinn machen.)

Ist es falsch, dass ein Schlüsselpaar eine persönliche Identität von allen Zugriffspunkten ("me-überall-id_rsa") global darstellt, wie ich es in der Vergangenheit getan habe, oder denke ich derzeit, dass eine eindeutige Client-Benutzer-Kombination immer durch dargestellt werden sollte ein eigener Schlüssel ("ich-auf-meinem-persönlichen-Laptop-id_rsa") passender?

Verwenden Sie denselben Schlüssel erneut, um eine Verbindung zu allen Servern herzustellen, oder unter welchen Bedingungen möchten Sie einen separaten Schlüssel prägen?

48
Andrew Vit

Ich bevorzuge einen Schlüssel pro Authentifizierungsbereich. Daher habe ich für jeden Desktop- oder Servercomputer bei der Arbeit (alle physisch ziemlich sicher und unter der Kontrolle einer einzelnen Gruppe von Administratoren) einen privaten Schlüssel. Ich verwende auf meinem neuen Heim-PC denselben privaten Schlüssel wie auf meinem alten Heim-PC. Ich verwende verschiedene Schlüssel auf Laptops und anderen Mobilgeräten. Dieser Ansatz ermöglicht ein detailliertes Risikomanagement: Ich kann Schlüssel separat widerrufen und die Möglichkeiten einschränken, dass meine Konten an einer eskalierten Infiltration beteiligt sind, indem bestimmte Schlüssel auf bestimmten Computern nicht autorisiert werden (ich mache nicht so viel, aber es ist eine Option für die Paranoiden).

Solange Sie nichts Kompliziertes tun, ist das Kopieren der öffentlichen Schlüssel nicht so schwierig. Sie können eine große Liste autorisierter Schlüssel führen und überall synchronisieren. Wenn Sie ein Gerät registrieren, müssen Sie dieser Liste ein Element hinzufügen und die Änderung vorantreiben. Dies ist nicht viel mehr Arbeit als das Abrufen des privaten Schlüssels, wenn Sie überhaupt über ein zentrales Datenrepository verfügen.

Beachten Sie, dass der offensichtlichste Vorteil separater privater Schlüssel darin besteht, einen separat widerrufen zu können, sie jedoch auch einen Verfügbarkeitsvorteil haben: Wenn ein Systemadministrator auf Computer A beschließt, den Schlüssel des C-Computers, auf dem Sie sich befinden, zu widerrufen, Möglicherweise finden Sie immer noch eine Maschine B, die den Schlüssel von C noch akzeptiert und deren Schlüssel von A akzeptiert wird. Dies scheint ziemlich esoterisch zu sein, aber dies ist mir einmal passiert (nach Debian hat erkannt, dass sie ihr RNG nicht ausgesät haben) , ich war froh, dass ich mich nicht nur auf einen auf der schwarzen Liste stehenden Schlüssel verlassen musste), während ich im Notfall noch keinen Schlüssel widerrufen musste.

Es ist sogar ein theoretischer Vorteil, ein separates Schlüsselpaar pro Maschinenpaar zu behalten, da es separate Widerrufe ermöglicht. Der Nutzen ist jedoch äußerst gering und die Verwaltung ist viel schwieriger (Sie können keine Berechtigungslisten mehr senden). Die Vereinfachung der Schlüsselverwaltung ist ein entscheidender Vorteil der Kryptografie mit öffentlichen Schlüsseln gegenüber gemeinsamen Geheimnissen.

Sie haben bereits den Hauptpunkt gesehen: Wenn einer Ihrer Computer kompromittiert ist, muss der auf diesem Computer enthaltene private Schlüssel "widerrufen" werden: Sie müssen alle Server konfigurieren, auf denen Sie eine Verbindung herstellen, um weitere Authentifizierungsversuche mit diesem Schlüssel abzulehnen (dh Sie entfernen den entsprechender öffentlicher Schlüssel aus dem .ssh/authorized_keys der Server). Es gibt eine Schadensbegrenzungstechnik, die darin besteht, den privaten Schlüssel mit einem Kennwort (oder einer Passphrase) zu sichern. Dies ist mit einem Preis verbunden, nämlich dass Sie das Passwort eingeben müssen ( ssh-agent kann dafür sehr praktisch sein); Auf der anderen Seite kann dies den Angreifer vorübergehend davon abhalten, den privaten Schlüssel zu erhalten (dies hängt von der Art des Kompromisses ab. Wenn es sich jedoch um einen Diebstahl eines kompletten Computers handelt - ein plausibles Szenario mit mobilen Geräten -, wird das Kennwort verhindert Sofortiger Zugriff auf den privaten Schlüssel und etwas Zeit für die Neukonfiguration der Server.


Man kann feststellen, dass "PKI" "Public Key Infrastructure" bedeutet und SSH in dieser Hinsicht rudimentär ist. In einer vollständigen PKI würde Zertifikate mit Delegierung und Zentralisierung des Widerrufs verwendet. Mit Zertifikaten:

  • sie würden ein CA-Schlüsselpaar erstellen, das sicher irgendwo gespeichert ist.
  • für jeden Client-Computer erhalten Sie ein neues Schlüsselpaar, wobei der öffentliche Schlüssel von der Zertifizierungsstelle signiert ist.
  • die Server sind so konfiguriert, dass sie automatisch den von der Zertifizierungsstelle signierten öffentlichen Schlüssel any akzeptieren (sie kennen den öffentlichen Schlüssel der Zertifizierungsstelle, jedoch nicht die einzelnen Schlüssel des Clientcomputers).
  • die Zertifizierungsstelle verwaltet und veröffentlicht regelmäßig Sperrinformationen, dh die Liste der öffentlichen Schlüssel, die nicht mehr akzeptiert werden dürfen. obwohl Diese Schlüssel werden von der Zertifizierungsstelle signiert (Sperrinformationen müssen an die Server gesendet werden.) oder auf Anfrage gezogen).

Das Tolle an Zertifikaten ist, dass Sie Entscheidungen zentralisieren. In der Praxis bedeutet dies, dass Sie den neuen öffentlichen Schlüssel nicht manuell drücken müssen, wenn Sie von Ihren Clientcomputern aus eine Verbindung zu 20 Servern herstellen und dann einen neuen Clientcomputer hinzufügen alle 20 Server.

OpenSSH unterstützt seit Version 5.4 (veröffentlicht am 8. März 2010) Zertifikate; Siehe den gleichnamigen Abschnitt in der Manpage für ssh-keygen . Die OpenSSH-Zertifikate haben ein viel einfacheres Format als "übliche" X.509-Zertifikate (wie sie mit SSL verwendet werden). Die Vereinfachung hat auch einen Preis: Es gibt keine zentrale Widerrufsunterstützung. Wenn stattdessen ein privater Schlüssel kompromittiert wird, müssen Sie den entsprechenden öffentlichen Schlüssel auf allen Servern auf die schwarze Liste setzen, und die schwarze Liste ist in OpenSSH eine Whitelist (Option AuthorizedPrincipalsFile in sshd_config), Die steht normalerweise unter der Kontrolle von root. Der Widerruf funktioniert also nicht gut und Sie müssen die Dinge auf jedem Server immer noch manuell konfigurieren, wenn Sie einen Schlüssel erstellen oder verlieren. Dies ist genau das Unpraktische, das PKI eigentlich abschaffen sollte.

Sie könnten immer noch zeitlich begrenzte Schlüssel erstellen, da OpenSSH-Zertifikate zeitlich begrenzte Schlüssel einbetten können. In diesem Fall würden Sie jedem Client-Computer einen Schlüssel geben, der beispielsweise für eine Woche gültig ist. Mit Schlüsseln, die nach einer Woche sterben, und einem öffentlichen CA-Schlüssel, der den Servern bekannt ist, haben Sie die Hauptgüte der CA (Sie müssen nichts auf allen Servern pushen, wenn ein neuer Computer zum Client-Pool hinzugefügt wird) und einen privaten Wenn der Schlüssel kompromittiert ist, ist der Schaden "begrenzt", vorausgesetzt, Sie hatten ein Schlüsselkennwort, das vermutlich einer Woche des Knackens standhalten würde (dies funktioniert jedoch nicht, wenn es sich bei dem Kompromiss um eine feindliche Übernahme mit einem Schlüssellogger handelt). Zeitlich begrenzte Schlüssel können mit der Zeit langweilig werden und sie setzen voraus, dass alle Server eine korrekt eingestellte Uhr haben, was nicht immer gegeben ist (es wäre bedauerlich, von einem Server ausgeschlossen zu werden, da die Serveruhr stark ausgeschaltet ist und zurückgesetzt wird Die Uhr benötigt SSH-Zugriff auf den Server ...).

Ein weiteres Problem mit SSH ist, dass es einfach ist, öffentliche Schlüssel auf jedem Server hinzuzufügen. Dies bedeutet, dass ein Angreifer, wenn er einen privaten Schlüssel kompromittiert und Zugriff auf einen Server erhält einmal, dem .ssh/authorized_keys Auf diesem Server seinen eigenen öffentlichen Schlüssel hinzufügen kann, und zwar nicht Widerruf wird das beheben. Der Widerruf ist von Natur aus ein asynchroner Prozess. Daher wird keine ausreichend strenge Schadenskontrolle durchgeführt.


Angesichts der Mängel der SSH-Unterstützung für Zertifikate gibt es kein vernünftiges Schema, mit dem in bestimmten Situationen keine Konfiguration auf allen Servern vorgenommen werden muss. Sie haben also grundsätzlich die folgenden Möglichkeiten, wenn Sie einen neuen Client-Computer hinzufügen:

  1. Sie kopieren den privaten Schlüssel von einem anderen Client-Computer (genau das tun Sie gerade). Dies erfordert keine zusätzliche Konfiguration auf den Servern.

  2. Sie erstellen ein neues Schlüsselpaar für diesen Computer. Sie müssen den öffentlichen Schlüssel an alle Server senden.

Bei einem Schlüsselkompromiss müssen Sie eine Verbindung zu allen Servern herstellen, um den entsprechenden öffentlichen Schlüssel aus allen .ssh/authorized_keys Zu entfernen. Dies ist unvermeidlich (um dies zu vermeiden, müssten Sie Zertifikate verwenden, und SSH ist nicht gut in Zertifikaten, siehe oben). Dann, wenn Sie haben Auswahl 1 verwendet, dann müssen Sie auch ein neues Schlüsselpaar erstellen und es an alle client Schieben = Maschinen, die eine Kopie des kompromittierten privaten Schlüssels verwendeten.

Daher ist Auswahl 1 im Normalfall mit weniger Konfigurationsarbeit verbunden als Auswahl 2, aber die Dinge sind umgekehrt, wenn ein Schlüsselkompromiss aufgetreten ist. Da Kompromisse normalerweise seltene Ereignisse sind, würde dies Wahl 1 begünstigen (was Sie bereits tun). Daher schlage ich vor, dass Sie Ihren privaten Schlüssel mit einem sicheren Kennwort schützen und auf alle Ihre Client-Systeme kopieren.

Hinweis: In all den oben genannten Fällen habe ich angenommen, dass Sie mit SSH eine Verbindung zu einer Liste von Servern herstellen und auf einen der Server zugreifen möchten von einem Ihrer Client-Computer. Sie möglicherweise möchten den Zugriff einschränken, z. B. den Zugriff auf einen bestimmten Server nur von einem oder zwei bestimmten Clientcomputern aus. Dies kann mit mehreren Clientschlüsseln erfolgen, die Konfigurationskomplexität nimmt jedoch quadratisch zu.

22
Tom Leek

Grundsätzlich versuche ich, eine persönliche Strategie für den Umgang mit Schlüsselpaaren zu entwickeln

Wenn Sie in erster Linie für die betreffenden Server verantwortlich sind, empfehle ich Ihnen dringend, nach Konfigurationsmanagement-Tools wie Puppet/Chef zu suchen. Beide haben Methoden zum Verteilen von SSH-Schlüsseln an Ihre Computer.

Der Grund, warum ich mit Puppet angefangen habe, war speziell, dass ich einen guten Weg wollte, um einen Schlüssel auf meinen ~ 60 Linux-Servern schnell zu widerrufen, wenn das Personal wechselte.

Wenn Sie über ein Konfigurationsverwaltungstool zur Verwaltung Ihrer Schlüssel verfügen, ist es viel einfacher, viele Schlüsselpaare zu haben. Anstatt manuell einen Schlüssel für jedes Feld zu widerrufen oder einen neuen Schlüssel für jedes Feld hinzuzufügen, fügen Sie einfach den öffentlichen Schlüssel auf dem Konfigurationsmaster hinzu, und die Clients aktualisieren die Berechtigungslisten innerhalb des für Ihr Konfigurationsmanagement festgelegten Abfrageintervalls Werkzeug.

Dies bedeutet, dass Sie viel Vertrauen in Ihren Konfigurationsverwaltungs-Host setzen, der nicht gefährdet wird. Da es normalerweise Aufgaben mit Root-Rechten auf jedem Computer ausführt, für den Sie es konfigurieren, müssen Sie sicherstellen, dass es fest und mit viel Überwachung gesperrt ist. Wenn ein Angreifer den Konfigurationsmaster kompromittieren sollte, kann er beispielsweise neue Schlüssel hinzufügen, neue Konten hinzufügen usw.

10
Zoredache

Ich verwende einen Schlüssel pro Realm und pro Maschine. 4 Fernbedienungen, auf die von 2 Arbeitsstationen zugegriffen wird => 8 private Schlüssel. Kopieren Sie niemals einen privaten Schlüssel von einem Host auf einen anderen. Wenn eine Workstation gefährdet ist, widerrufen Sie alle diese Schlüssel.

Da das Erstellen und Konfigurieren von Schlüsseln für deren Verwendung ziemlich mühsam ist, habe ich ein Tool zum Verwalten meiner SSH-Schlüssel für den Github-Zugriff geschrieben: github-keygen .

0
dolmen