Wo sollte Linux Ihr VPN-Passwort speichern? Nicht im Profil
Die Secret-Flags von NetworkManager entscheiden, ob das Profil, ein Schlüsselbund-Agent oder niemand das Passwort hält. Die Antwort hängt davon ab, wann die Verbindung startet.
Das VPN-Passwort muss irgendwo leben: im Verbindungsprofil, in einem Schlüsselbund, den die Desktop-Sitzung entsperrt, oder nirgends. NetworkManager nennt diese Wahl ein Secret-Flag, und die falsche Wahl ist der Grund, warum eine Verbindung nach der Anmeldung funktioniert und als Dienst scheitert. Das Flag ist eine Zeile Konfiguration, und es entscheidet, welches dieser drei Ergebnisse Sie bekommen.
Drei Flags decken fast jeden Fall ab, und die Entscheidung hängt davon ab, wann die Verbindung startet.
Drei Secret-Flags, drei Verhaltensweisen
Ein Flag von 0 bedeutet, dass das Geheimnis mit der Verbindung gespeichert wird, in welchem Speicher das Profil auch liegt. Ein Flag von 1 macht es agenteneigen: Das Geheimnis kommt von einem Secret-Agent wie einem Desktop-Schlüsselbund, und NetworkManager fragt es bei der Aktivierung ab. Ein Flag von 2 bedeutet nicht gespeichert, das Geheimnis wird also nie geschrieben und muss jedes Mal geliefert werden. Flag 4 markiert ein Geheimnis als nicht erforderlich, für Verbindungen, die wirklich keines brauchen.
| Flag | Where it lives | Works unattended |
|---|---|---|
| 0 saved | Connection profile | Yes, if the store is readable |
| 1 agent-owned | Secret agent or keyring | Only if that agent is available |
| 2 not-saved | Nowhere | No |
Setzen Sie die Flags pro Geheimnis statt pro Verbindung. Eine Verbindung kann ein agenteneigenes Passwort und eine gespeicherte Passphrase für einen privaten Schlüssel haben.
Entscheiden Sie danach, wann die Verbindung startet
Wenn ein angemeldeter Benutzer die Verbindung startet, ist agenteneigen die vernünftige Voreinstellung: Der Schlüsselbund wird durch die Anmeldung entsperrt, und das Geheimnis liegt nie in einer Datei. Wenn die Verbindung hochkommen muss, bevor sich jemand anmeldet, ist agenteneigen die falsche Wahl, weil es keinen Sitzungsschlüsselbund zum Entsperren gibt.
Das ist die ganze Entscheidung. Alles andere ist eine Variante davon.
Für einen Dienst vor der Anmeldung ist ein systemweiter Speicher oder eine geschützte Schlüsseldatei das unterstützte Muster, und Dateiberechtigungen werden zum Schutz. Lösen Sie das Problem nicht, indem Sie das Passwort in ein Shell-Skript kleben, das beim Start läuft.
Was der Schlüsselbund gibt und was nicht
Ein Schlüsselbund hält das Geheimnis aus dem Verbindungsprofil heraus und bindet es an eine Benutzersitzung. Er macht das Geheimnis nicht für einen Dienst ohne Sitzung verfügbar, und er verschlüsselt nichts auf der Leitung. Das sind getrennte Eigenschaften, die Menschen oft vermengen. Was er tatsächlich kauft, ist ein kleinerer Schadensradius, wenn eine Profildatei durchsickert.
Der private Schlüssel, auf den das Profil verweist, braucht eigene Berechtigungen, unabhängig davon, wo das Passwort liegt.
Diagnose ohne Ausgabe von Geheimnissen
Verbindungsnamen, UUIDs und Flags reichen meist aus, um einen Fehler zu erklären. nmcli connection show listet das Profil auf, und die Secret-Flags sagen Ihnen, woher das Passwort kommen sollte.
Vermeiden Sie --show-secrets in Tickets und Chats. Einmal eingefügt, ist es ein Zugangsdatum in einem Protokoll.
Speichern ist keine Widerrufung
Ein Geheimnis aus einem Schlüsselbund zu entfernen macht das Zugangsdatum nicht ungültig, das der entfernte Betreiber bereits akzeptiert hat. Konto-Widerruf ist eine serverseitige Aktion, und lokale Speicherung ist ein separates Thema mit einem separaten Eigentümer.
Entscheiden Sie beides vor dem Vorfall, nicht währenddessen. Eine interaktive Benutzerverbindung und ein Dienst vor der Anmeldung brauchen unterschiedliche Antworten, und ein gemeinsames Shell-Skript ist keines von beidem. Die NetworkManager-Dokumentation zu Secret-Flags listet die Werte vollständig auf.