OpenVPN PAM: it oanmeldingsargument is in tsjinst, gjin brûker

In brûker waard tafoege op 'e server, it wachtwurd waard goed yntypen, en de ferbining einiget dochs mei AUTH_FAILED. De ynstekkerrigel ferklearret meastentiids wêrom: it wurd efter it ynstekkerpaad is in PAM-tsjinstnamme, en it beslút hokker stapel fan modules it fraachstik beantwurdet. It is gjin brûkersnamme, en it is gjin oanwizing nei in wachtwurdbestân dat OpenVPN sels lêst.

Wat it twadde wurd kiest

De konfiguraasjerigel nimt in ynstekkerpaad en ien argumint:

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

Dat argumint wurdt oan 'e PAM-bibleteek jûn as de tsjinstnamme, wêrtroch de stapel yn /etc/pam.d/openvpn draait. Skriuw dêr login en jo krije ynstee it ynteraktive oanmeldbelied, mei hokker modules dat belied ek op jo distribúsje befettet.

Brûk it ynstekkerpaad dat it ynstalleare pakket leveret, net in paad dat fan in oare host kopiearre is. De bestânsnamme en map ferskille tusken distribúsjes, en in ferkeard paad mislearret by it starten mei in ynstekker-laadflater, net by autentikaasje.

Wêr't de stapel akkounts echt lêst

PAM is in trochstjoerder. It tsjinstbestân listet modules yn folchoarder op, en de earste dy't antwurdzje kin, beslút de útkomst. In stapel dy't pam_unix oanropt, lêst lokale akkounts; in stapel dy't in LDAP- of RADIUS-module oanropt, stjoert de legitimearringsgegevens hielendal earne oars hinne.

Lês it bestân dêr't de tsjinstnamme nei oplost, ynklusyf alles wat it befettet:

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

As de stapel delewearret nei in map, feroaret it tafoegjen fan in lokaal akkount neat. As er lokale akkounts lêst, feroaret it oanmeitsjen fan de brûker yn 'e map ek neat. It akkount moat bestean dêr't de stapel sjocht, en dat is de hiele diagnoaze yn 'e measte fan dizze rapporten.

Ien poging, twa logboeken

Korrelearje ien mislearre ferbining oan beide kanten. It OpenVPN-logboek toant it resultaat fan de ynstekker en it wegere fan 'e klant; it systeem-autentikaasjelogboek toant hokker module draaide en wat dy besletten hat. Se yn itselde tiidfinster lêze is wat in ûntbrekkend tsjinstbestân fan in backend-tydlimiet skiedt. In gat yn it autentikaasjelogboek betsjut dat de stapel hielendal net berikt waard.

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

Test de tsjinst direkt mei in helpmiddel dat PAM praat, sadat jo net tagelyk de VPN en de stapel debugge. In suksesfolle direkte test mei deselde tsjinstnamme en akkount beheint it probleem ta hoe't de daemon legitimearringsgegevens trochjaan, net ta it akkount sels.

pamtester openvpn alice authenticate

As de direkte test mislearret mei deselde legitimearringsgegevens dy't op in konsôle wurkje, lêst de stapel net de akkountboarne dy't jo oannommen. As it slagget, sjoch dan nei it petear dat de ynstekker fiert en nei wat de klant eins stjoerd hat. Rin it ek ien kear mei in bewust ferkeard wachtwurd, sadat jo it ferskil sjogge tusken in wegering en in moduleflater. Dy twa útkomsten lykje identyk yn it VPN-logboek en hielendal oars hjir.

In aparte tsjinst is better as it bewurkjen fan 'e oanmelding

Jou de VPN syn eigen tsjinstbestân as syn easken ferskille fan ynteraktive oanmelding, wat se meastentiids dogge. It bewurkjen fan login of common-auth feroaret it belied foar elk programma dat se befettet, en de folgjende persoan dy't in net-relatearre oanmeldprobleem debugget, erft jo wiziging.

Kopiearje de modules dy't jo nedich hawwe yn in lyts tsjinstbestân, hâld de folchoarder eksplisyt, en notearje wa't it hat. Dat bestân is it ding om te kontrolearjen as in wachtwurdweromsetting gjin effekt liket te hawwen.

Wat de klant stjoert, en wat net

De klant leveret in brûkersnamme en wachtwurd fia syn stipe oanfragen of bestân. De server-ynstekker jout dy wearden troch oan it PAM-petear; hy lêst se net út 'e konfiguraasje fan 'e server. In rigel oan 'e serverkant dy't liket as definiearret er in wachtwurd, docht dat net, en gjin profylbewurking sil in akkount meitsje.

Brûkersnamme en wachtwurd kinne njonken klantcertifikaten bestean, en PAM ynskeakelje is gjin reden om op te hâlden mei it ferifiearjen fan certifikaten. Hâld de lagen dy't de útrôl bedoelde, en reparearje allinnich de akkountboarne.

Akseptaasje is twasidich: it bedoelde akkount slagget, en in akkount dat wegerd wurde moat, mislearret noch altyd. It README fan de auth-pam-ynstekker dokumintearret it tsjinstargumint en de backends dy't it betsjinje kin, en dat is it plak om de regeling te befêstigjen dy't jo besykje te bouwen.