OpenVPN PAM: Das Login-Argument ist ein Dienst, kein Benutzer

Ein Benutzer wurde auf dem Server angelegt, das Passwort wurde korrekt eingegeben, und die Verbindung endet trotzdem mit AUTH_FAILED. Die Plugin-Zeile erklärt meist, warum: Das Wort nach dem Plugin-Pfad ist ein PAM-Dienstname, und es entscheidet, welcher Stapel von Modulen die Frage beantwortet. Es ist kein Benutzername und kein Zeiger auf eine Passwortdatei, die OpenVPN selbst liest.

Was das zweite Wort auswählt

Die Konfigurationszeile nimmt einen Plugin-Pfad und ein Argument:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

Dieses Argument wird der PAM-Bibliothek als Dienstname übergeben, wodurch der Stapel unter /etc/pam.d/openvpn ausgeführt wird. Schreiben Sie dort login, erhalten Sie stattdessen die interaktive Login-Richtlinie, mit welchen Modulen diese Richtlinie auf Ihrer Distribution auch immer ausgestattet ist.

Verwenden Sie den Plugin-Pfad, den das installierte Paket bereitstellt, nicht einen von einem anderen Host kopierten Pfad. Dateiname und Verzeichnis unterscheiden sich zwischen Distributionen, und ein falscher Pfad schlägt beim Start mit einem Plugin-Ladefehler fehl, nicht bei der Authentifizierung.

Wo der Stapel Konten tatsächlich liest

PAM ist ein Verteiler. Die Dienstdatei listet Module der Reihe nach auf, und das erste, das antworten kann, entscheidet über das Ergebnis. Ein Stapel, der pam_unix aufruft, liest lokale Konten; ein Stapel, der ein LDAP- oder RADIUS-Modul aufruft, schickt die Anmeldedaten ganz woanders hin.

Lesen Sie die Datei, zu der der Dienstname auflöst, einschließlich alles, was sie einbindet:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

Wenn der Stapel an ein Verzeichnis delegiert, ändert das Anlegen eines lokalen Kontos nichts. Wenn er lokale Konten liest, ändert das Anlegen des Benutzers im Verzeichnis ebenso wenig. Das Konto muss dort existieren, wo der Stapel nachsieht, und das ist in den meisten dieser Berichte die ganze Diagnose.

Ein Versuch, zwei Protokolle

Korrelieren Sie eine einzelne fehlgeschlagene Verbindung auf beiden Seiten. Das OpenVPN-Protokoll zeigt das Plugin-Ergebnis und die Ablehnung durch den Client; das System-Authentifizierungsprotokoll zeigt, welches Modul lief und was es entschied. Beide im selben Zeitfenster zu lesen, ist das, was eine fehlende Dienstdatei von einem Backend-Timeout trennt. Eine Lücke im Authentifizierungsprotokoll bedeutet, dass der Stapel überhaupt nie erreicht wurde.

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

Testen Sie den Dienst direkt mit einem Werkzeug, das PAM spricht, damit Sie nicht gleichzeitig das VPN und den Stapel debuggen. Ein erfolgreicher direkter Test mit demselben Dienstnamen und Konto verengt das Problem darauf, wie der Daemon Anmeldedaten weitergibt, nicht auf das Konto selbst.

pamtester openvpn alice authenticate

Schlägt der direkte Test mit denselben Anmeldedaten fehl, die an einer Konsole funktionieren, liest der Stapel nicht die angenommene Kontenquelle. Gelingt er, sehen Sie sich die Konversation an, die das Plugin führt, und das, was der Client tatsächlich gesendet hat. Führen Sie ihn auch einmal mit einem absichtlich falschen Passwort aus, damit Sie den Unterschied zwischen einer Ablehnung und einem Modulfehler sehen. Diese beiden Ergebnisse sehen im VPN-Protokoll identisch und hier völlig unterschiedlich aus.

Ein eigener Dienst ist besser als das Bearbeiten von Login

Geben Sie dem VPN eine eigene Dienstdatei, wenn seine Anforderungen von der interaktiven Anmeldung abweichen, was sie meist tun. Das Bearbeiten von login oder common-auth ändert die Richtlinie für jedes Programm, das sie einbindet, und der Nächste, der ein unabhängiges Login-Problem debuggt, erbt Ihre Änderung.

Kopieren Sie die benötigten Module in eine kleine Dienstdatei, halten Sie die Reihenfolge explizit und notieren Sie, wem sie gehört. Diese Datei ist das, was man prüft, wenn ein Passwort-Reset wirkungslos zu sein scheint.

Was der Client sendet und was nicht

Der Client liefert Benutzername und Passwort über seine unterstützte Eingabeaufforderung oder Datei. Das Server-Plugin reicht diese Werte in die PAM-Konversation weiter; es liest sie nicht aus der Serverkonfiguration. Eine serverseitige Zeile, die ein Passwort zu definieren scheint, tut das nicht, und keine Profilbearbeitung legt ein Konto an.

Benutzername und Passwort können neben Client-Zertifikaten bestehen, und PAM zu aktivieren ist kein Grund, mit der Prüfung von Zertifikaten aufzuhören. Behalten Sie die Schichten bei, die das Deployment vorgesehen hat, und reparieren Sie nur die Kontenquelle.

Akzeptanz ist zweiseitig: Das vorgesehene Konto gelingt, und ein Konto, das abgelehnt werden sollte, scheitert weiterhin. Die README des auth-pam-Plugins dokumentiert das Dienst-Argument und die Backends, die es bedienen kann, und dort bestätigen Sie die Anordnung, die Sie aufbauen wollen.