OpenVPN-Dienst bleibt bei der Eingabe des privaten Schlüsselpassworts hängen: So lässt sich das beheben

OpenVPN fragt die Passphrase des privaten Schlüssels auf dem lokalen Rechner ab, eine funktionierende Login-Datei beantwortet sie also nie. Bei einem Dienst gibt es kein Terminal zum Eingeben, und der Start hängt entweder oder scheitert mit einem Journal-Eintrag, der die Eingabe statt der Ursache nennt. Es sind zwei Geheimnisse im Spiel, und jedes braucht vor dem Neustart der Unit seine eigene lesbare Quelle. Der Ablauf unten trennt sie und prüft dann die Identität, die jede Datei tatsächlich öffnet.

Die beiden Abfragen unterscheiden

Die Schlüsselpassphrase entschlüsselt den lokalen privaten Schlüssel; die Kontodaten authentifizieren die Sitzung beim Server. Sie kommen von verschiedenen Stellen, scheitern zu verschiedenen Zeitpunkten und erzeugen verschiedene Meldungen. Wer sie verwechselt, sucht nach einem Passwort-Reset, obwohl das Konto gar nicht beteiligt war. Lesen Sie den Abfragetext, bevor Sie eine Option ändern, denn die Formulierung ist der einzige verlässliche Hinweis darauf, welches Geheimnis fehlt.

In Community OpenVPN 2.x benennt askpass eine Datei, die die Schlüsselpassphrase in der ersten Zeile hält, und auth-user-pass eine Datei mit dem Benutzernamen in einer Zeile und dem Passwort in der nächsten. Keine der beiden Dateien erfüllt die jeweils andere Option. Eine Desktop-App oder ein NetworkManager-Profil kann beides im eigenen Geheimnisspeicher halten, den ein Kommandozeilen-Client nie liest, also notieren Sie, welchen Client Sie konfigurieren, bevor Sie einen Pfad schreiben.

Beide Optionen auf lesbare Dateien zeigen lassen

Ein Profil, das beide Eingaben braucht, endet mit drei Dateiverweisen: dem verschlüsselten Schlüssel, der Passphrase, die ihn entsperrt, und dem Login-Paar. Fügen Sie sie hinzu, ohne CA oder Identitätsprüfungen anzutasten, denn diese entscheiden, wer der Server ist, und gehören nicht zu diesem Problem. Nutzt das Deployment überhaupt keine Kontodaten, erzeugt auth-user-pass eine Eingabe, die niemand liefern kann.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Optionen ohne Argument verhalten sich anders als Optionen mit Pfad, und in einem Dienst ist der Unterschied wichtig. Ein askpass ohne Argument liest weiterhin die Konsole, und eine auth-user-pass-Datei mit nur einem Benutzernamen lässt weiterhin eine Passwortabfrage warten. Sobald der Client daemonisiert, kann er ein Terminal gar nicht mehr um Eingabe bitten, eine so konfigurierte Unit kommt also nicht hoch.

Absolute Pfade nehmen die Frage nach dem Arbeitsverzeichnis weg, gewähren aber keinen Zugriff. Besitz, Modus und Durchquerung folgen, und alle drei werden gegen das Konto geprüft, unter dem der Prozess läuft.

Die Konfiguration der Unit vor dem Profil lesen

Welche Konfiguration die Instanz lädt, entscheidet die Unit, nicht die Datei, die Sie bearbeitet haben. Lesen Sie ihre Kommandozeile und alle Drop-ins und folgen Sie dann dem Arbeitsverzeichnis bis zum tatsächlich verwendeten Profil. Ein Passphrase-Verweis in einer anderen .ovpn-Datei ändert für diese Instanz nichts.

Drei schreibgeschützte Befehle beantworten das meiste davon. Der erste zeigt die Unit und alle Drop-ins, der zweite die Identität und die Sandbox-Einstellungen, die den Prozess binden, und der dritte, worüber sich der letzte Start tatsächlich beschwert hat. Verwenden Sie den Instanznamen, der auf dem Host existiert:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Achten Sie auf ProtectHome und auf die eigenen Optionen des Profils user, group und chroot. Eine Datei unter einem Home-Verzeichnis kann in Ihrer Shell lesbar und im Dienst unsichtbar sein, sobald Home-Verzeichnisse verborgen werden. Das Konto, mit dem systemd startet, ist nicht immer das Konto, das den Schlüssel am Ende öffnet.

Beweisen, dass die Laufzeitidentität beide Dateien öffnen kann

Den Modus zu lesen reicht nicht, denn jedes Verzeichnis auf dem Pfad muss von derselben Identität durchquerbar sein. Gehen Sie den Pfad Komponente für Komponente durch und testen Sie dann das Öffnen als das Konto, das der Prozess verwendet. Eine Datei mit Modus 600 im Besitz von root funktioniert nur, solange der Prozess noch root ist, was nach dem Privilegienabfall vieler Profile nicht gilt. Zwei Befehle decken Durchquerung und Öffnen ab:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

Der erste Befehl zeigt den Modus jeder Komponente und scheitert dort, wo das Konto nicht durchqueren kann; der zweite beantwortet die einzige wichtige Frage, ob die Laufzeitidentität die Datei zum Lesen öffnen kann. Keiner von beiden zeigt Dateiinhalte, und genau das ist der Punkt, wenn die Datei eine Passphrase enthält. Wiederholen Sie den Test für die Login-Datei, denn die beiden werden oft mit unterschiedlichem Besitz gespeichert.

Nutzt der Prozess ein chroot oder einen eingeschränkten Namespace, führen Sie denselben Test aus dieser Sicht aus, sonst beschreibt die Antwort das falsche Dateisystem. Eine Passphrase unter einem verborgenen Home-Verzeichnis ist das übliche Beispiel für einen Test, der außerhalb der Unit besteht und darin scheitert.

Den ersten Start prüfen, dann eine Wiederverbindung

Starten Sie die Instanz einmal und lesen Sie den ersten Fehler statt des letzten. Eine fehlende Eingabedatei, eine gescheiterte Schlüsselentschlüsselung und ein AUTH_FAILED vom Server sind drei verschiedene Ereignisse mit drei verschiedenen Reparaturen. Eine Berechtigungswarnung zu beheben beweist nichts darüber, ob der Schlüssel entsperrt wurde.

Die Journal-Zeile sagt, welchen der drei Fälle Sie haben. Die Reparatur folgt daraus, welche Eingabe fehlgeschlagen ist:

Testen Sie dann den Lebenszyklus, den Sie wirklich brauchen: einen Start beim Booten und jede unterstützte Wiederverbindung, nicht nur einen manuellen Start aus Ihrer Shell. Mit auth-nocache werden die Eingaben nach der ersten Nutzung verworfen, eine spätere Wiederverbindung braucht also weiterhin eine lesbare Quelle. Ein Schlüsselbund, der beim Desktop-Login entsperrt wird, steht einem Dienst nicht zur Verfügung, der startete, bevor sich jemand anmeldete, und das ist der übliche Grund, warum ein manueller Test besteht und ein Neustart scheitert. Gelingt der erste Start und scheitert eine spätere Wiederverbindung, lesen Sie das Journal zum Wiederverbindungsereignis, bevor Sie erneut Berechtigungen ändern.

Die Passphrase neben dem Schlüssel zu speichern verringert, was die Verschlüsselung bringt, also beschränken Sie diese Datei und ihre Sicherungen. Das Entfernen der Schlüsselpassphrase ist eine eigene Entscheidung zu Anmeldedaten und keine Reparatur für eine fehlende Eingabe. Ein Deployment, das auf menschlicher Freigabe oder interaktiver MFA beruht, braucht seinen unterstützten Agenten oder seine Verwaltungsintegration; ein dauerhaft gespeicherter Einmalcode ist kein gleichwertiger Ersatz.