Passphrase für einen Schlüssel entfernen oder behalten? Die Kopie, die Sie anlegen
Eine unverschlüsselte Schlüsseldatei enthält dasselbe Geheimnis hinter schwächerem Schutz. Vergleichen Sie das Ruherisiko vor der Umwandlung und wissen Sie, was sie nicht rückgängig macht.
Ein verschlüsselter privater Schlüssel und ein unverschlüsselter enthalten dasselbe Schlüsselmaterial. Die Umwandlung erzeugt keine neue Identität, setzt kein VPN-Konto zurück und macht die alte Datei nicht ungültig. Sie schreibt eine zweite Kopie, und diese Kopie trägt ein anderes Ruherisiko.
Ob der Tausch sich lohnt, hängt davon ab, wo die Datei liegen wird und wer sie lesen kann.
Was die Umwandlung tatsächlich ändert
Vor der Umwandlung schützt eine Passphrase den Schlüssel, die der Betreiber angibt. Nach der Umwandlung schützen ihn Dateisystemberechtigungen und jede Zugriffskontrolle, die die Datei umgibt. Die Kryptografie hat sich nicht geändert; die Zahl der Dinge zwischen einem Angreifer und dem Schlüssel hat sich geändert. Das ist der ganze Vergleich.
Eine Tabelle macht den Unterschied konkret.
| Form | What protects it | How it fails |
|---|---|---|
| Encrypted key | A passphrase plus file access | Weak passphrase, or an offline attack on the file |
| Unencrypted key | File permissions and host security only | Any reader copies it silently |
Keine der beiden Formen ist automatisch sicherer. Sie scheitern auf unterschiedliche Weise, und nur eine dieser Weisen hinterlässt einen Logeintrag.
Wann es besser ist, die Passphrase zu behalten
Kann ein unterstützter Client die Passphrase abfragen oder aus einem genehmigten Secret Store holen, bringt die Umwandlung nichts. Sie behalten eine Kopie, eine Schutzgrenze und eine Datei weniger zu verwalten. Die meisten VPN-Clients, die PEM-Schlüssel akzeptieren, können das.
Die Umwandlung ist auch der falsche Schritt, wenn ein Team den Schlüssel teilt. Eine unverschlüsselte Datei auf einem gemeinsam genutzten Host wird zu einem Geheimnis, das jeder mit Shell-Zugriff kopieren kann.
Wann eine unverschlüsselte Kopie gerechtfertigt ist
Manche Dienste können nicht abfragen, manche Container binden Geheimnisse schreibgeschützt ein, und manche Geräte lesen eine Schlüsseldatei beim Start ohne interaktiven Weg. In diesen Fällen kann ein unverschlüsselter Schlüssel in einem ordentlich beschränkten Verzeichnis das unterstützte Design sein. Die Rechtfertigung ist die Umgebung, nicht die Bequemlichkeit.
Wenn Sie nicht sagen können, wer die Datei lesen kann und warum, lautet die Antwort nein.
Der Befehl und seine scharfen Kanten
Für einen dateibasierten Schlüssel, den OpenSSL 3.5 unterstützt, die pkey-Referenz dokumentiert das Entfernen der Passphrase und eine interaktive Abfrage, wenn die Eingabe verschlüsselt ist und keine Passwortquelle angegeben wird. Die minimale Form ist kurz, und sie lässt sich leicht unvorsichtig ausführen.
umask 077
openssl pkey -in protected-key.pem -out new-private-key.pemDrei scharfe Kanten. Die E/A der Ausgabedatei ist nicht atomar, daher kann ein vorhandener Ausgabepfad mitten im Schreiben abgeschnitten werden. Verwenden Sie den Eingabepfad nicht als Ausgabe, und experimentieren Sie nicht mit der einzigen geschützten Kopie. Geben Sie die Passphrase an der Abfrage ein, nicht auf der Kommandozeile, wo sie in der Shell-Historie landet.
Prüfen Sie das Ergebnis, bevor Sie eine VPN-Konfiguration ändern: openssl pkey -in new-private-key.pem -pubout sollte denselben öffentlichen Schlüssel ausgeben, den Sie vorher hatten.
Was die Umwandlung nicht tut
Sie widerruft nicht die verschlüsselte Kopie, die dort weiterhin existiert, wo Sie sie liegengelassen haben. Sie ändert weder das Passwort des VPN-Kontos noch das Zertifikat. Und sie repariert keine Offenlegung, die bereits geschehen ist. Wenn ein Schlüssel abgeflossen ist, lautet die Lösung Ersatz und serverseitiger Widerruf, nicht eine lokale Formatänderung.
Löschen Sie die Zwischendatei bewusst, und bestätigen Sie, dass der Pfad, den Sie löschen, der von Ihnen erstellte ist.