OpenVPN PAM: logind-argumentet er en tjeneste, ikke en bruger

En bruger blev tilføjet på serveren, adgangskoden blev skrevet korrekt, og forbindelsen slutter stadig med AUTH_FAILED. Plugin-linjen forklarer normalt hvorfor: ordet efter plugin-stien er et PAM-tjenestenavn, og det afgør, hvilken stak af moduler der svarer på spørgsmålet. Det er ikke et brugernavn, og det er ikke en pegepind til en adgangskodefil, som OpenVPN læser selv.

Hvad det andet ord vælger

Konfigurationslinjen tager en plugin-sti og et argument:

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

Det argument sendes til PAM-biblioteket som tjenestenavn, hvilket gør stakken i /etc/pam.d/openvpn til den, der kører. Skriv login der, og du får i stedet den interaktive loginpolitik, med de moduler den politik nu engang indeholder på din distribution.

Brug den plugin-sti, den installerede pakke leverer, i stedet for en sti kopieret fra en anden vært. Filnavnet og mappen varierer mellem distributioner, og en forkert sti fejler ved opstart med en plugin-indlæsningsfejl, ikke ved godkendelse.

Hvor stakken faktisk læser konti

PAM er en dispatcher. Tjenestefilen oplister moduler i rækkefølge, og det første, der kan svare, afgør resultatet. En stak, der kalder pam_unix, læser lokale konti; en stak, der kalder et LDAP- eller RADIUS-modul, sender legitimationsoplysningerne helt andre steder hen.

Læs den fil, tjenestenavnet peger på, inklusive alt det, den inkluderer:

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

Hvis stakken delegerer til en mappe, ændrer tilføjelsen af en lokal konto intet. Hvis den læser lokale konti, ændrer oprettelsen af brugeren i mappen heller intet. Kontoen skal findes der, hvor stakken kigger, og det er hele diagnosen i de fleste af disse rapporter.

Ét forsøg, to logfiler

Korrelér en enkelt mislykket forbindelse på begge sider. OpenVPN-loggen viser plugin-resultatet og klientens afvisning; systemets godkendelseslog viser, hvilket modul der kørte, og hvad det besluttede. At læse dem i samme tidsvindue er det, der adskiller en manglende tjenestefil fra en backend-timeout. Et hul i godkendelsesloggen betyder, at stakken aldrig blev nået.

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

Test tjenesten direkte med et værktøj, der taler PAM, så du ikke fejlretter VPN og stak samtidig. En vellykket direkte test med samme tjenestenavn og konto indsnævrer problemet til, hvordan daemonen sender legitimationsoplysninger, ikke til kontoen selv.

pamtester openvpn alice authenticate

Hvis den direkte test fejler med de samme oplysninger, der virker i en konsol, læser stakken ikke den kontokilde, du antog. Hvis den lykkes, skal du se på den samtale, plugin'et kører, og på det, klienten faktisk sendte. Kør den også én gang med en bevidst forkert adgangskode, så du kan se forskellen mellem en afvisning og en modulfejl. De to udfald ser identiske ud i VPN-loggen og helt forskellige her.

En dedikeret tjeneste slår at redigere login

Giv VPN'en sin egen tjenestefil, når dens krav afviger fra interaktivt login, hvilket de normalt gør. Redigering af login eller common-auth ændrer politikken for alle programmer, der inkluderer dem, og den næste, der fejlretter et urelateret loginproblem, arver din ændring.

Kopiér de moduler, du har brug for, ind i en lille tjenestefil, hold rækkefølgen eksplicit, og notér, hvem der ejer den. Den fil er det, man skal tjekke, når en nulstilling af adgangskoden tilsyneladende ingen effekt har.

Hvad klienten sender, og hvad den ikke sender

Klienten leverer et brugernavn og en adgangskode via sin understøttede prompt eller fil. Server-plugin'et sender disse værdier videre til PAM-samtalen; det læser dem ikke fra serverens konfiguration. En server-side linje, der ser ud til at definere en adgangskode, gør det ikke, og ingen profilredigering opretter en konto.

Brugernavn og adgangskode kan eksistere sammen med klientcertifikater, og at aktivere PAM er ikke en grund til at stoppe med at verificere certifikater. Behold de lag, udrulningen havde til hensigt, og ret kun kontokilden.

Accept er tosidet: den tilsigtede konto lykkes, og en konto, der bør afvises, fejler stadig. Filen README for auth-pam-plugin'et dokumenterer tjenesteargumentet og de backends, den kan stå foran, og det er stedet at bekræfte den ordning, du forsøger at bygge.