OpenVPN PAM: het loginargument is een dienst, geen gebruiker

Er is een gebruiker op de server toegevoegd, het wachtwoord is correct getypt, en de verbinding eindigt nog steeds met AUTH_FAILED. De pluginregel legt meestal uit waarom: het woord na het plugin-pad is een PAM-dienstnaam, en dat bepaalt welke stack van modules de vraag beantwoordt. Het is geen gebruikersnaam, en het is geen verwijzing naar een wachtwoordbestand dat OpenVPN zelf leest.

Wat het tweede woord kiest

De configuratieregel neemt een plugin-pad en één argument:

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

Dat argument wordt aan de PAM-bibliotheek doorgegeven als de dienstnaam, waardoor de stack in /etc/pam.d/openvpn degene is die draait. Schrijf daar login en je krijgt in plaats daarvan het interactieve loginbeleid, met welke modules dat beleid op jouw distributie ook bevat.

Gebruik het plugin-pad dat het geïnstalleerde pakket levert, niet een pad dat van een andere host is gekopieerd. De bestandsnaam en map verschillen per distributie, en een verkeerd pad faalt bij het opstarten met een plugin-laadfout, niet bij de authenticatie.

Waar de stack de accounts werkelijk leest

PAM is een doorgever. Het dienstbestand somt de modules in volgorde op, en de eerste die kan antwoorden bepaalt de uitkomst. Een stack die pam_unix aanroept, leest lokale accounts; een stack die een LDAP- of RADIUS-module aanroept, stuurt de inloggegevens ergens anders heen.

Lees het bestand waarnaar de dienstnaam verwijst, inclusief alles wat het bevat:

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

Als de stack aan een map delegeert, verandert het toevoegen van een lokaal account niets. Als hij lokale accounts leest, verandert het aanmaken van de gebruiker in de map ook niets. Het account moet bestaan waar de stack kijkt, en dat is in de meeste van deze rapporten de hele diagnose.

Eén poging, twee logboeken

Correleer één mislukte verbinding aan beide kanten. Het OpenVPN-logboek toont het pluginresultaat en de weigering van de client; het systeem-authenticatielogboek toont welke module liep en wat die besloot. Ze in hetzelfde tijdvenster lezen is wat een ontbrekend dienstbestand onderscheidt van een backend-time-out. Een gat in het authenticatielogboek betekent dat de stack nooit is bereikt.

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

Test de dienst rechtstreeks met een hulpprogramma dat PAM spreekt, zodat je niet tegelijk de VPN en de stack debugt. Een geslaagde directe test met dezelfde dienstnaam en hetzelfde account beperkt het probleem tot hoe de daemon inloggegevens doorgeeft, niet tot het account zelf.

pamtester openvpn alice authenticate

Als de directe test faalt met dezelfde inloggegevens die op een console werken, leest de stack niet de accountbron die je aannam. Als hij slaagt, kijk dan naar het gesprek dat de plugin voert en naar wat de client werkelijk heeft verzonden. Voer hem ook één keer uit met een opzettelijk verkeerd wachtwoord, zodat je het verschil ziet tussen een weigering en een modulfout. Die twee uitkomsten zien er in het VPN-logboek identiek uit en hier volstrekt verschillend.

Een eigen dienst is beter dan het bewerken van login

Geef de VPN een eigen dienstbestand wanneer de eisen afwijken van interactief inloggen, wat meestal zo is. Het bewerken van login of common-auth verandert het beleid voor elk programma dat ze bevat, en de volgende persoon die een ongerelateerd loginprobleem debugt, erft je wijziging.

Kopieer de modules die je nodig hebt naar een klein dienstbestand, houd de volgorde expliciet en noteer wie de eigenaar is. Dat bestand is wat je controleert wanneer een wachtwoordreset geen effect lijkt te hebben.

Wat de client verzendt, en wat niet

De client levert een gebruikersnaam en wachtwoord via zijn ondersteunde prompt of bestand. De server-plugin geeft die waarden door aan het PAM-gesprek; hij leest ze niet uit de serverconfiguratie. Een regel aan de serverkant die lijkt een wachtwoord te definiëren, doet dat niet, en geen profielbewerking maakt een account aan.

Gebruikersnaam en wachtwoord kunnen naast clientcertificaten bestaan, en PAM inschakelen is geen reden om te stoppen met het verifiëren van certificaten. Behoud de lagen die de uitrol bedoelde en repareer alleen de accountbron.

Acceptatie is tweezijdig: het bedoelde account slaagt, en een account dat geweigerd zou moeten worden, faalt nog steeds. Het bestand README van de auth-pam-plugin documenteert het dienstargument en de backends die het kan bedienen, en dat is de plek om de opzet te bevestigen die je probeert te bouwen.