Behebung: OpenVPN konnte den Auth-Benutzernamen nicht von der Standardeingabe lesen
Die Meldung „could not read Auth username from stdin“ von OpenVPN ist ein lokaler Eingabefehler. Geben Sie dem Dienst eine lesbare Quelle für Anmeldedaten; script-security hat damit nichts zu tun.
could not read Auth username from stdin sieht nach einem Authentifizierungsproblem aus und ist keines. OpenVPN versuchte, den Benutzernamen über die Standardeingabe abzufragen, fand nichts Lesbares und hielt an, bevor es je den Server kontaktierte. Das Konto kann vollkommen gültig sein; dem Prozess fehlt einfach jemand, den er fragen kann.
Deshalb ist der erste sinnvolle Schritt zu bestätigen, was der Client liest, und nicht, die Verbindung erneut zu versuchen oder Servereinstellungen zu ändern. Gehen Sie die folgenden Prüfungen der Reihe nach durch und halten Sie bei der ersten an, die fehlschlägt.
Lesen Sie den Fehler als lokalen Eingabefehler
Wenn auth-user-pass ohne ein Dateiargument auftritt, erwartet der Client eine Abfrage. In einer interaktiven Shell funktioniert diese Abfrage, weil der Prozess ein Terminal besitzt. Unter systemd, einem Cron-Job oder einem Container ist die Standardeingabe meist leer, und das Lesen kehrt sofort mit dem Fehler zurück, den Sie sehen.
Die Meldung nennt außerdem das Feld, das fehlgeschlagen ist, Benutzername oder Passwort, was zeigt, wie weit das Lesen gekommen ist. Ein fehlender Benutzername bedeutet, dass der Prozess überhaupt nichts lesen konnte. Ein fehlendes Passwort nach einem erfolgreichen Benutzernamen bedeutet, dass der Eingabestrom zwischen den beiden Lesevorgängen endete, was typisch für eine halb geschriebene Datei oder eine geschlossene Pipe ist.
Bestätigen Sie die Sicht des Clients selbst, bevor Sie etwas anderes ändern. Führen Sie ihn im Vordergrund mit derselben Konfiguration und demselben Benutzer aus und beobachten Sie, ob die Abfrage erscheint. Erscheint sie in Ihrer Shell, aber nicht unter dem Dienstmanager, liegt der Unterschied in der Eingabequelle, nicht in den Anmeldedaten. Ein schneller Vergleich der Unit-Datei mit Ihrer Shell-Umgebung zeigt meist, welche von beiden ein Terminal bereitstellt.
Geben Sie dem Dienst eine unterstützte Quelle für Anmeldedaten
Die unterstützte Quelle für unbeaufsichtigten Betrieb ist eine Datei mit Anmeldedaten, die als Argument an auth-user-pass übergeben wird. Die Datei wird als reiner Text gelesen: Die erste Zeile ist der Benutzername, die zweite das Passwort. Verweisen Sie mit einem absoluten Pfad darauf, etwa /etc/openvpn/client/creds , damit das Arbeitsverzeichnis des Dienstkontos die Bedeutung der Direktive nicht verändern kann.
Berechtigungen sind ebenso wichtig wie der Pfad. Die Datei muss für das Konto lesbar sein, das den Client ausführt, und nicht für alle anderen, und sie sollte dem Dienstkonto oder root gehören, mit einer Gruppe, die den Dienst einschließt. Prüfen Sie die Lesbarkeit als dieses Konto, ohne den Inhalt auszugeben.
Ein relativer Pfad ist der stille Fehlermodus. Das Profil kann in einem Verzeichnis liegen, während systemd den Prozess woanders startet, sodass eine Datei, die in Ihrer Shell aufgelöst wird, für den Dienst nicht aufgelöst wird. Verschieben Sie die Anmeldedaten an einen festen Ort und verweisen Sie absolut darauf. Starten Sie dann den Dienst einmal und bestätigen Sie, dass derselbe Pfad verwendet wird, statt der Ansicht des Profileditors zu vertrauen.
Wenn die Bereitstellung einen Einmalcode oder eine andere interaktive Abfrage erfordert, entscheiden Sie, ob der Arbeitsablauf des Clients dies tatsächlich unbeaufsichtigt unterstützt. Eine Datei mit einem statischen Passwort kann einen rotierenden Code nicht beantworten, und eine unbeantwortbare Abfrage erneut zu versuchen, liefert keine Information.
Warum script-security nicht hilft
script-security steuert, ob der Client Skripte ausführen darf und wie viel er an sie übergeben darf, einschließlich der Frage, ob ein Passwort über eine Umgebungsvariable an ein Skript weitergegeben werden kann. Woher Benutzername und Passwort ursprünglich kommen, sagt es nicht.
Die Stufe zu erhöhen ist ein häufiger Reflex, weil die Meldung Auth erwähnt, aber es ändert Skriptberechtigungen statt der Eingabequelle und erweitert, was der Client ausführen darf. Wenn ein Hilfsskript Teil des Entwurfs ist, reparieren Sie zuerst die Eingabequelle und halten Sie die Sicherheitsstufe auf dem niedrigsten Wert, den die Bereitstellung braucht.
Die Management-Schnittstelle ist eine legitime Alternative. Ein Frontend kann sich damit verbinden, die Anmeldedaten-Anfrage empfangen und mit Benutzername und Passwort antworten, so funktionieren einige GUIs. Wenn Sie sie nutzen, binden Sie sie an eine lokale Adresse, schützen Sie sie mit einer Management-Passwortdatei und beschränken Sie, wer sich verbinden darf, denn sie ist ein Steuerkanal für den Client.
Prüfen Sie die nächste Stufe, nachdem der Client die Datei gelesen hat
Sobald der Client die Anmeldedaten lesen kann, ist der nächste Fehler ein echter Austausch mit dem Server, und seine Meldung hat eine andere Bedeutung. Ein Authentifizierungsfehler in dieser Phase bedeutet, dass der Server das Konto abgelehnt hat; eine Challenge-Antwort bedeutet, dass der Server einen weiteren Faktor will. Behandeln Sie beides als neue Probleme und nicht als dasselbe wiederholt.
Testen Sie den ganzen Weg so, wie der Dienst ihn ausführen wird: dasselbe Konto, dasselbe Arbeitsverzeichnis, dieselbe Unit-Umgebung. Eine Verbindung, die nur funktioniert, wenn sie aus Ihrer Shell gestartet wird, ist ein Zeichen dafür, dass eine Umgebungsvariable oder ein Terminal noch Teil des Ablaufs ist.
Bewahren Sie die Geheimnisse dann dort auf, wo sie hingehören. Passwörter in Kommandozeilenargumenten erscheinen in der Prozesstabelle, und Passwörter in Debug-Ausgaben landen in Tickets. Nutzen Sie eine geschützte Datei oder die Management-Schnittstelle, halten Sie Protokolle auf einer Stufe, die keine Anmeldedaten wiedergibt, und wechseln Sie die Datei, wenn jemand mit Zugriff das Team verlässt.
Checkliste: absoluter Pfad zu den Anmeldedaten, lesbar als Dienstkonto, kein Terminal erforderlich, script-security auf dem Minimum belassen, Management-Schnittstelle nur, wenn sie gebunden und authentifiziert ist, und die resultierende Serverantwort als separates Ereignis behandelt.