Verhindern, dass NetworkManager ein gespeichertes VPN-Passwort anzeigt

NetworkManager kann ein VPN-Passwort halten, damit die Verbindung zustande kommt, ohne dass jemand es tippt, und es kann diesen Wert über den Editor oder über nmcli --show-secrets wieder anzeigen. Es gibt drei Eigentumsmodelle, und das Anzeigeverhalten ist nur ein Symptom dafür, welches Sie gewählt haben. Wählen Sie zuerst das Modell und setzen Sie dann das Flag, das dazu passt, statt ein Feld mit einem Platzhalter zu verstecken, der die nächste Person verwirrt.

Drei Eigentumsmodelle

Das erste Modell fragt jedes Mal. Nichts wird gespeichert, das Geheimnis existiert nur während der Aktivierung, und wer die Verbindung startet, muss das Passwort kennen. Es ist die unbequemste Option und die am leichtesten zu verteidigende.

Das zweite übergibt das Geheimnis an einen Schlüsselbund des Benutzers. Der Agent entsperrt beim Sitzungsstart und liefert den Wert auf Anfrage, was ihn aus der Verbindungsdatei heraushält, aber die Verbindung an die Sitzung dieses Benutzers bindet. Daraus folgen zwei Bedingungen: Der Agent muss laufen, und er muss entsperrt sein.

Das dritte speichert eine geschützte Anmeldeinformation für eine Systemverbindung. Sie überlebt Neustarts und funktioniert, bevor sich jemand anmeldet, und dafür liegt der Wert auf der Platte, geschützt durch Dateirechte statt durch Verschlüsselung.

Jedes Modell ist im richtigen Zusammenhang vernünftig. Der Fehler ist, sie zu mischen, und so landet ein Laptop mit einem Geheimnis an zwei Stellen und ohne klare Antwort, welches maßgeblich ist. Notieren Sie, welches Modell ein Profil verwendet. Eine Zeile im Team-Runbook erspart der nächsten Person, einen vierten Ort zum Nachsehen zu erfinden.

Lesen Sie den aktuellen Zustand, bevor Sie ihn ändern

Betrachten Sie das Profil und den Zustand des Geheimnisses als der Benutzer, der die Verbindung verwaltet. Der zweite Befehl ist derjenige, der Ihnen sagt, ob der Wert tatsächlich lesbar ist.

nmcli connection show "Office VPN"
nmcli --show-secrets connection show "Office VPN"
sudo stat -c '%U %a %n' /etc/NetworkManager/system-connections/*.nmconnection

Eine Schlüsseldatei in diesem Verzeichnis gehört normalerweise root mit Modus 600. Das hält gewöhnliche Benutzer draußen und root nicht, was zählt, wenn dieselbe Maschine geteilt wird oder wenn eine Sicherung als root läuft.

Dateirechte sind eine Grenze, keine Verschlüsselung. Wer die Datei als root lesen kann, hat das Passwort im Klartext. Das ist ein akzeptabler Kompromiss für einen unbeaufsichtigten Server und ein schlechter für eine geteilte Workstation. Einmal aufgeschrieben, verhindert es eine lange Diskussion darüber, ob der Wert geschützt ist.

Was jeder Flag-Wert bewirkt

Das VPN-Geheimnis trägt eine Eigenschaft flags, und die Werte sind nicht allein aus den Zahlen ersichtlich.

Das tatsächliche Verhalten hängt auch vom Plugin und davon ab, ob ein Agent läuft, also behandeln Sie die Tabelle als Vertrag und das beobachtete Verhalten als das, was Sie prüfen. Ein Wert, der auf einem Desktop funktioniert, kann sich auf einem Server ohne Sitzung anders verhalten. In dieser Lücke leben die meisten verwirrenden Tickets.

Setzen Sie die Eigenschaft ausdrücklich, statt eine Zeile zu löschen und zu hoffen. Ein fehlendes Flag ist keine Richtlinie, und das nächste Paketupdate kann es mit etwas füllen, das Sie nicht beabsichtigt haben.

Passen Sie das Modell dazu, wann die Verbindung startet

Wenn die Verbindung nur startet, während ein Benutzer angemeldet ist, passt Agent-Eigentum gut und hält das Geheimnis aus der Datei. Wenn sie beim Start beginnt, bevor eine Sitzung existiert, kann ein Agent Ihnen nicht helfen.

Das ist die ganze Entscheidung für die meisten Maschinen. Es erklärt auch eine Klasse verwirrender Berichte, bei denen die Verbindung interaktiv funktioniert und nach einem Neustart scheitert. Das Flag hat sich nie geändert; der Kontext schon.

Für den unbeaufsichtigten Fall ist eine eingeschränkte, root-eigene Datei oder eine genehmigte Anmeldeinformationsquelle die praktische Antwort. Halten Sie sie aus dem Verbindungsprofil heraus, wenn dieses Profil jemals exportiert oder auf eine andere Maschine kopiert wird.

Wenn der Wert bereits sichtbar war, wechseln Sie ihn

Das Ändern eines Flags lässt das Passwort selbst unberührt. Ein Wert, der in einem Screenshot, in der Shell-Historie, in einem an den Support gesendeten Paket oder in einer Datei auftauchte, die andere Benutzer öffnen konnten, sollte als offengelegt gelten.

Ändern Sie es auf dem Server, korrigieren Sie dann den Client und beenden Sie jede Sitzung, die sich mit dem alten authentifiziert hat. Das Löschen der lokalen Verbindung widerruft auf der Gegenseite nichts, und genau das übersehen die Leute.

Hören Sie dann auf, das Passwort auf die Kommandozeile zu setzen. Es landet in der Shell-Historie und kann in einer Prozessliste auftauchen; nutzen Sie stattdessen die interaktive Eingabeaufforderung oder den Agenten.

Prüfen Sie durch erneutes Verbinden

Wiederholen Sie den Befehl, der das Geheimnis zeigte, und bestätigen Sie, dass das Feld nicht mehr ausgegeben wird. Trennen und verbinden Sie dann erneut, und starten Sie neu, wenn die Verbindung automatisch beginnt, weil der interessante Fehler erst auftritt, wenn sich der Sitzungskontext ändert.

Wenn das Geheimnis weiterhin erscheint, liefert es ein anderes Profil oder ein anderer Agent. Untersuchen Sie die aktive Verbindung und den Schlüsselbund, statt Dateien zu löschen, bis sich das Symptom verschiebt.