Eine SSH-Schlüsselpassphrase schützt die Datei, nicht die Route

Ein Sicherungsdatenträger von einem alten Laptop enthält noch einen privaten SSH-Schlüssel, und jemand fragt, ob das VPN ihn schützt. Es tut es nicht, und es hat es nie getan. Das VPN schützt einen Pfad zwischen zwei Netzwerken; die Passphrase schützt die Datei; der Agent schützt eine laufende Sitzung. Drei verschiedene Mechanismen, drei verschiedene Fehlerarten, und eine gestohlene Kopie kümmert sich nur um die ersten beiden.

Die Passphrase gehört zur Datei

Eine SSH-Schlüsselpassphrase verschlüsselt das private Schlüsselmaterial im Ruhezustand. Sie ist nicht das Kontopasswort, das an den Server gesendet wird, und sie ist nicht die Anmeldeinformation, mit der man dem VPN beitritt. Wer beides verwechselt, nimmt Änderungen vor, die die Exposition nicht beseitigen.

OpenSSHs ssh-keygen-Handbuch behandelt den Umgang mit Passphrasen, einschließlich des Schalters -p, der eine neue Passphrase für einen bereits vorhandenen Schlüssel setzt.

Für einen vorhandenen Schlüssel ist die Befehlsform einfach, und sie schreibt die Datei neu:

ssh-keygen -p -f ~/.ssh/id_ed25519

Verwenden Sie den genehmigten Wartungs- und Wiederherstellungsprozess des Schlüsseleigentümers, denn dies ist ein Schreibvorgang, keine Prüfung. Veröffentlichen Sie die private Datei nicht und setzen Sie keine echte Passphrase auf eine gemeinsam genutzte Kommandozeile. Eine Passphrase-Änderung verschlüsselt eine früher gezogene Kopie nicht neu. Halten Sie den Ort der alten Kopie im Ticket fest, damit der Eigentümer entscheiden kann, ob sie vernichtet wird.

Eine Kopie überlebt den Laptop und den Tunnel

Sobald eine Schlüsseldatei kopiert wurde, sagt die laufende VPN-Verbindung des Laptops nichts mehr über sie aus. Entscheidend ist, wie gut die Datei selbst geschützt ist, und welche Server dem passenden öffentlichen Schlüssel noch vertrauen.

Die Passphrase der aktuellen Datei zu ändern berührt die Kopie nicht und entfernt nicht denselben öffentlichen Schlüssel aus authorized_keys auf einem Server. Widerruf und Neuverschlüsselung sind getrennte Vorgänge.

Behandeln Sie einen geleakten privaten Schlüssel daher als Identitätsereignis, nicht als Netzwerkereignis. Entfernen oder ersetzen Sie den akzeptierten Schlüssel über die Server und den Registrierungsprozess, die ihn besitzen. Das VPN zu stoppen begrenzt eine Route zu einem Zeitpunkt; es ist kein Widerruf.

Entsperren verschiebt das Geheimnis in einen Agenten

Ein Agent hält entschlüsselte Identitäten für spätere Authentifizierung bereit, damit der Benutzer die Passphrase nicht bei jeder Verbindung neu eingibt. Das ist eine Komfortfunktion mit eigener Sicherheitsgrenze.

ssh-agent kann über seine Option -t begrenzen, wie lange eine Identität geladen bleibt, und eine Einstellung pro Identität kann diese Grenze überschreiben. Wählen Sie die Richtlinie für den Agenten, den Sie tatsächlich betreiben, statt anzunehmen, ein VPN-Trennen vergesse jeden geladenen Schlüssel.

Ein Prozess, der nach dem Entsperren des Schlüssels kompromittiert wird, ist ein anderes Problem als eine gestohlene verschlüsselte Datei. Die Weiterleitung des Agenten an einen anderen Host delegiert die Authentifizierungsfähigkeit, ohne die Schlüsseldatei zu kopieren, aktivieren Sie sie also nur bei genehmigtem Bedarf.

Listen Sie auf, was der Agent derzeit hält, vor und nach einer Änderung:

ssh-add -l

Unbeaufsichtigte Aufgaben brauchen ihren eigenen Plan

Ein geplanter Job kann keine Eingabeaufforderung beantworten. Er braucht eine genehmigte Regelung für Maschinenanmeldeinformationen, und das Entsperrgeheimnis im selben Verzeichnis wie der Schlüssel zu halten, lesbar für dasselbe Konto, schafft keine zweite Grenze.

Arbeiten Sie mit dem Dienstinhaber an unterstützter Geheimnisauslieferung oder hardwaregestütztem Betrieb und decken Sie Erneuerung, Ausfall und Wiederherstellung ab. Der Wunsch nach einem Menschen an der Tastatur verändert, wie ein Ausfall aussieht, verglichen mit einem Host, der ohne Aufsicht startet.

Behalten Sie auch die Host-Identitätsprüfung des Servers und seine Kontobeschränkungen bei. Eine VPN-Route gibt Ihnen einen privaten Pfad; sie beweist nicht, dass jeder erreichbare SSH-Listener der beabsichtigte Host ist. Erfassen Sie den Listener und den Hostschlüssel-Fingerabdruck im selben Inventar wie den Schlüssel selbst.

Prüfen Sie die Grenzen getrennt

Testen Sie jede Grenze mit ihrer eigenen Frage. Öffnet sich die Datei ohne die Passphrase? Hält der Agent die Identität nach einer Trennung noch? Akzeptiert der Server den öffentlichen Schlüssel noch?

Zwei Befehle beantworten die erste und die dritte:

ssh-keygen -y -f ~/.ssh/id_ed25519
ssh -v [email protected]

Erfassen Sie Dateischutz, erlaubte Schlüsselnutzung und serverseitige Entfernung als drei getrennte Posten. Ein Tunnel, eine Passphrase und ein Agent bewachen jeweils einen anderen Teil der Beziehung, und nur einer davon betrifft das Netzwerk.