Ist --key-password in OpenConnect Ihr VPN-Kontopasswort?

Lesen Sie den Optionsnamen wörtlich. Er benennt einen Schlüssel, und die Verwirrung beginnt, wenn die Datei, die entsperrt wird, mit dem Konto verwechselt wird, das authentifiziert wird. Fügen Sie das Kontopasswort in diese Option ein, und der Client versucht, damit eine Schlüsseldatei zu öffnen, was aus Gründen scheitert, die nichts mit der VPN-Anmeldung zu tun haben.

Der verwirrende Teil ist, dass eine einzelne Verbindung beide Geheimnisse zu Recht benötigen kann. Die Client-Zertifikatsauthentifizierung kann einen verschlüsselten Schlüssel erfordern, und dasselbe Gateway kann nach Annahme des Zertifikats noch einen Benutzer-Authentifizierungsaustausch durchführen. Keines der Geheimnisse erfüllt die andere Stufe, und ein Fehler in einem sieht von außen einem Fehler im anderen sehr ähnlich.

Zwei Geheimnisse, zwei verschiedene Aufgaben

Lesen Sie die Rollen als Dateizugriff gegenüber Netzzutritt. Das Schlüsselpasswort entschlüsselt den privaten PEM-Schlüssel, der in --sslkey angegeben ist, damit das TLS-Client-Zertifikat vorgelegt werden kann. Diese Entschlüsselung geschieht lokal im Clientprozess, und die Passphrase selbst reist nie zum Gateway. Was das Gateway sieht, sind das Zertifikat und eine mit dem Schlüssel erstellte Signatur. Das OpenConnect-Handbuch führt --key-password neben --certificate und --sslkey, und bei Builds, die einen im TPM gehaltenen Schlüssel nutzen können, trägt dieselbe Option stattdessen das Passwort des Speicher-Wurzelschlüssels.

Das Kontopasswort ist anderer Art. Es geht in den Authentifizierungsaustausch ein: ein Formular mit Benutzername und Passwort, ein Token, eine SAML-Runde oder eine Kombination, die das Gateway ankündigt. Manche Installationen fragen gar nicht danach, wenn das Zertifikat der einzige Faktor ist, und manche fragen auch nach einem Zertifikat danach, weil das Zertifikat das Gerät belegt, während das Konto die Person belegt.

Die Vermischung der beiden erzeugt irreführende Fehler. Ein Gateway, das eine Anmeldung ablehnt, meldet normalerweise einen Authentifizierungsfehler, während eine falsche Schlüsselpassphrase meist früher scheitert, wenn die TLS-Schicht die Schlüsseldatei nicht lesen kann. Das sind verschiedene Stufen mit verschiedenen Korrekturen, und die Namen sind ähnlich genug, dass Leute sie vertauschen und dann dem falschen Log nachjagen. Notieren Sie, welche Abfrage erschienen ist, bevor Sie eine Einstellung ändern, denn der Wortlaut der Abfrage ist die billigste Diagnose, die Sie haben.

Wann das Schlüsselpasswort wirklich gebraucht wird

Die Option ist nur sinnvoll, wenn es einen verschlüsselten Schlüssel zu entsperren gibt. Wenn Sie sich mit Benutzername und Passwort und ohne Client-Zertifikat verbinden, hat --key-password nichts, worauf es wirken könnte, und die Angabe ändert nichts. Wenn Sie sich mit --certificate und --sslkey verbinden, entscheidet das Format der Schlüsseldatei selbst, ob überhaupt eine Passphrase abgefragt wird.

Beide Geheimnisse in einem Befehl sind in verwalteten Umgebungen üblich: ein Gerätezertifikat in einem verschlüsselten Schlüssel plus eine Anmeldung pro Benutzer. Die richtige Reihenfolge ist, den Client die Schlüsselpassphrase lokal abfragen zu lassen, den Zertifikats-Handshake abzuschließen und dann die Kontoabfrage des Gateways getrennt zu behandeln. Der Versuch, beides über ein wiederverwendetes Skript vorab zu füllen, ist der Punkt, an dem die Verwechslung meist beginnt.

Eine nützliche Diagnose ist, darauf zu achten, wann der Fehler auftritt. Wenn der Client stehen bleibt, bevor eine Netzwerkauthentifizierung beginnt, verdächtigen Sie die Schlüsseldatei, ihr Format oder die Passphrase. Wenn die TLS-Sitzung aufgebaut ist und das Gateway den Benutzer danach ablehnt, hat der Schlüssel seinen Job getan, und der Kontoaustausch ist das Problem.

Beide Geheimnisse aus der Shell-Historie heraushalten

Kommandozeilenargumente sind für andere lokale Benutzer über die Prozesstabelle lesbar und landen häufig in Shell-Historie, Skripten und Support-Transkripten. OpenConnect kann das Kontopasswort mit --passwd-on-stdin aus der Standardeingabe lesen, und die Schlüsselpassphrase kann aus einer interaktiven Abfrage oder einem Agenten statt aus einem Argument kommen. Keiner der Mechanismen macht das Geheimnis für sich sicher, aber beide halten es von den exponiertesten Stellen fern.

Dateien verdienen dieselbe Sorgfalt. Ein Skript, das eine Passphrase in eine temporäre Datei schreibt, sollte sie mit restriktiven Rechten anlegen, beim Beenden löschen und weltweit lesbare Verzeichnisse vermeiden. Eine Passphrase, die die Sitzung in einem temporären Verzeichnis überlebt, ist eine Kopie, die Sie zu erstellen vergessen haben. Umgebungsvariablen sind für Kindprozesse sichtbar und werden oft von Debug-Werkzeugen ausgegeben, sind also kein kostenloses Upgrade gegenüber Argumenten.

Diagnoseausgaben sind das stille Leck. Client-Logs mit höherer Ausführlichkeit können Anfragetexte oder Optionswerte zeigen, und ein kopiertes Terminal-Transkript lässt sich leicht in ein Ticket einfügen, also lesen Sie die Ausgabe, bevor Sie sie teilen.

Ein toter Desktop-Knopf ist ein anderer Fehler

Ein Desktop-VPN-Eintrag, der einen Spinner zeigt und dann nichts, ist meist überhaupt kein Authentifizierungsproblem. Der Knopf gehört zu einem Netzwerkmanager, einem Hersteller-Applet oder einem Plugin, das OpenConnect in Ihrem Namen startet, und eine fehlende Komponente oder ein unlesbares Profil können genau dieses Symptom erzeugen. Finden Sie heraus, welchen Prozess der Knopf startet, und lesen Sie dessen Fehler, bevor Sie Zugangsdaten anfassen.

Es ist verlockend, die Zertifikatsprüfung zu lockern oder eine Prüfung abzuschalten, wenn die GUI die Verbindung verweigert. Das verwandelt einen Client-Integrationsfehler in eine Sicherheitsherabstufung und behebt selten das Startproblem. Lassen Sie die Serverprüfung intakt, bestätigen Sie, dass das Profil auf das vorgesehene Gateway zeigt, und prüfen Sie, ob der Helfer, den die GUI erwartet, tatsächlich installiert ist.

Eine kurze Checkliste trennt die Fälle. Ein lokaler Fehler, bevor ein Paket das Gerät verlässt, deutet auf den Schlüssel oder die Client-Installation hin. Eine Ablehnung durch das Gateway nach der TLS-Sitzung deutet auf den Kontoaustausch hin. Ein Knopf, der den Client nie startet, deutet auf die Desktop-Integration hin. Drei verschiedene Fehler, von denen einer ein Passwort ist, das Sie gerade in das falsche Feld einfügen wollten.