Ungültige Secrets sind ein Container-Problem, keine Passwortregel
Ein abgelehnter Nachweis hat vielleicht nie das Gateway erreicht. Vergleichen Sie zuerst den Eingabecontainer, die Authentifizierungsstufe und das Konto selbst.
Die Meldung „ungültige Secrets“ führt meist zu einer Schlussfolgerung: Die VPN mag keine Sonderzeichen. Diese Schlussfolgerung ist meist falsch, denn die Meldung kommt oft aus der lokalen Verarbeitung, bevor irgendein Gateway das Konto angesehen hat. Zwei Entwürfe übergeben dasselbe Passwort, ein grafisches Feld und eine Datei mit Nachweisen, und sie scheitern an verschiedenen Stellen. Vergleichen Sie die Container, bevor Sie ein Passwort vereinfachen, das die ganze Zeit in Ordnung war.
Der Fehler kommt vor dem Gateway
Lokale Validierung, ein gesperrter Secret-Speicher, ein fehlender Agent und eine falsch aufgebaute Nachweisdatei erzeugen allesamt Fehler, die der Nutzer als eine einzige Ablehnung erlebt. Keiner davon betrifft den Authentifizierungsserver. Die Ablehnung des Gateways selbst ist ein eigenes Ereignis, und sie kommt meist mit einer anderen Meldung und zu einem anderen Zeitpunkt. Sie tritt auf, nachdem ein Tunnel besteht und Nachweise übertragen wurden.
Die erste Frage ist also nicht, welche Zeichen erlaubt sind, sondern wo der Versuch stehen geblieben ist. Ein Client, der nie eine Verbindung geöffnet hat, wurde von niemandem abgelehnt. Notieren Sie die beobachtete Stufe, denn jeder weitere Schritt hängt von dieser Einordnung ab.
Die Unterscheidung ändert auch, wer es repariert. Ein Containerproblem gehört dem Gerät und seinem Besitzer, eine Kontoablehnung dagegen demjenigen, der das Authentifizierungs-Backend betreibt.
Vergleichen Sie die Container, nicht die Zeichen
Ein grafisches Passwortfeld, ein Schlüsselbund-Eintrag, eine Nachweisdatei mit zwei Zeilen und ein Automatisierungs-Secret tragen jeweils denselben Wert in einem anderen Umschlag. Der Umschlag hat eigene Regeln, und genau diese Regeln brechen meist. Der Wert ist selten das Problem; der Transport des Werts ist es. Halten Sie die beiden Ideen getrennt, und die Diagnose wird kürzer.
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
Client-Optionen der OpenVPN-2.6-Community beschreiben diese zweizeilige Datei für auth-user-pass, einschließlich des Verhaltens, wenn die Passwortzeile fehlt: dann fragt der Client selbst nach. Dieses eine Detail erklärt eine ganze Klasse von Meldungen der Art „es fragt nach einem Passwort, das ich schon angegeben habe“. Es sagt Ihnen außerdem, dass eine leere zweite Zeile ein bedeutsamer Zustand ist und keine harmlose Formatierungswahl.
Das Quoting ist wieder eine eigene Ebene: Anführungszeichen in einer einfachen Nachweisdatei werden als Daten gespeichert, während eine Shell sie entfernt, bevor das Programm irgendetwas sieht. Dasselbe Zeichen ist an einer Stelle harmlos und an der anderen strukturell. Eine Tabelle kann Ihnen nicht sagen, welchen Container Ihr Client verwendet hat, daher lesen Sie die eigene Konfiguration des Clients, bevor Sie eine Zeile auswählen.
Auch Zeilenumbrüche sind strukturell. Eine Datei mit zeilengetrennten Feldern kann keinen Wert tragen, der einen Zeilenumbruch enthält, und das ist eine Grenze des Formats und kein Urteil über die Passwortstärke. Nutzen Sie den vom Deployment unterstützten Übertragungsweg, statt das Secret zurechtzustutzen, damit es in eine behelfsmäßige Datei passt.
Erstellen Sie die Nachweisdatei ohne Schäden durch die Shell
Der sicherste lokale Weg hält das Secret aus der Shell-Historie und aus der Argumentliste des Prozesses heraus. Lesen Sie beide Felder interaktiv und schreiben Sie dann die zwei Zeilen, die der Client erwartet. Alles andere kann in einer leicht prüfbaren Konfigurationsdatei bleiben.
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsDie ersten beiden Befehle lesen den Benutzernamen und dann das Passwort, ohne es anzuzeigen, der dritte schreibt beide Zeilen, der vierte beschränkt die Datei, und der letzte startet den Client mit dieser Datei. Beachten Sie, dass read -r Backslashes bewahrt, und genau das ist die Art Detail, die ein funktionierendes Passwort in ein scheiterndes verwandelt, wenn sie fehlt.
Vermeiden Sie es, die Datei mit einer nicht in Anführungszeichen gesetzten Variablen oder mit einem Here-Dokument voller Shell-Expansionen zu bauen. Beides kann Zeichen verändern, bevor sie die Datei erreichen, und der resultierende Fehler sieht wie eine VPN-Ablehnung aus, weil das Passwort auf der Platte tatsächlich anders ist als das, das Sie kennen. Wenn Sie das vermuten, vergleichen Sie die Bytelänge der Datei mit dem erwarteten Wert, ohne das Secret selbst auszugeben. Eine Abweichung von einem oder zwei Bytes ist die Signatur eines Quoting-Unfalls.
Lesen Sie die Stufe am ersten Fehler ab
Behalten Sie die erste konkrete Meldung eines Versuchs und ordnen Sie sie dann ein. Ein lokaler Validierungsfehler, ein fehlender privater Schlüssel, ein nicht verfügbarer Secret-Agent und ein Authentifizierungsfehler am Gateway sind vier verschiedene Ergebnisse mit vier verschiedenen Zuständigkeiten. Nur eines davon betrifft das Konto.
Wenn das Gateway tatsächlich einen korrekt übergebenen Nachweis ablehnt, prüfen Sie das Konto, das Authentifizierungs-Backend und jede erforderliche Challenge mit dem Administrator. Ein allgemeiner Authentifizierungsfehler nennt kein verbotenes Zeichen.
Stellen Sie den genehmigten Wert über den richtigen Mechanismus wieder her, statt ihn auf Buchstaben und Ziffern zu reduzieren. Die Passwortrichtlinie gehört dem Betreiber, und eine Umgehung, die sie still aushebelt, ist keine Reparatur. Sie verbirgt außerdem den eigentlichen Defekt vor der nächsten Person, die denselben Fehler mit einem schwächeren Passwort und ohne bessere Idee erleben wird.