OpenVPN PAM: die aanmeldingsargument is ’n diens, nie ’n gebruiker nie

’n Gebruiker is op die bediener bygevoeg, die wagwoord is korrek ingetik, en die verbinding eindig steeds met AUTH_FAILED. Die inprop-reël verduidelik gewoonlik waarom: die woord ná die inprop-lêerpad is ’n PAM-diensnaam, en dit bepaal watter stapel modules die vraag beantwoord. Dit is nie ’n gebruikersnaam nie, en dit is nie ’n verwysing na ’n wagwoordlêer wat OpenVPN self lees nie.

Wat die tweede woord kies

Die konfigurasiereël neem ’n inprop-lêerpad en een argument:

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

Daardie argument word as die diensnaam aan die PAM-biblioteek gegee, wat die stapel by /etc/pam.d/openvpn die een maak wat loop. Skryf login daar en jy kry eerder die interaktiewe aanmeldingsbeleid, met watter modules daardie beleid ook al op jou verspreiding insluit.

Gebruik die inprop-lêerpad wat die geïnstalleerde pakket voorsien, nie ’n pad wat van ’n ander gasheer gekopieer is nie. Die lêernaam en gids verskil tussen verspreidings, en ’n verkeerde pad misluk by die opstart met ’n inprop-laai-fout, nie by verifikasie nie.

Waar die stapel werklik rekeninge lees

PAM is ’n verspreider. Die dienslêer lys modules in volgorde, en die eerste een wat kan antwoord, bepaal die uitkoms. ’n Stapel wat pam_unix roep, lees plaaslike rekeninge; ’n stapel wat ’n LDAP- of RADIUS-module roep, stuur die geloofsbriewe heeltemal elders heen.

Lees die lêer waarna die diensnaam verwys, insluitend enigiets wat dit insluit:

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

As die stapel aan ’n gids delegeer, verander die toevoeging van ’n plaaslike rekening niks. As dit plaaslike rekeninge lees, verander die skep van die gebruiker in die gids ook niks. Die rekening moet bestaan waar die stapel kyk, en dit is die hele diagnose in die meeste van hierdie verslae.

Een poging, twee logboeke

Korreleer ’n enkele mislukte verbinding aan beide kante. Die OpenVPN-logboek wys die inprop se resultaat en die kliënt se verwerping; die stelsel-verifikasielogboek wys watter module geloop het en wat dit besluit het. Om hulle in dieselfde tydvenster te lees, is wat ’n ontbrekende dienslêer van ’n backend-tydsverloop skei. ’n Leemte in die verifikasielogboek beteken die stapel is glad nie bereik nie.

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

Toets die diens direk met ’n hulpmiddel wat PAM praat, sodat jy nie die VPN en die stapel terselfdertyd ontfout nie. ’n Suksesvolle direkte toets met dieselfde diensnaam en rekening vernou die probleem na hoe die daemon geloofsbriewe deurgee, nie na die rekening self nie.

pamtester openvpn alice authenticate

As die direkte toets misluk met dieselfde geloofsbriewe wat by ’n konsole werk, lees die stapel nie die rekeningbron wat jy aanvaar het nie. As dit slaag, kyk na die gesprek wat die inprop loop en na wat die kliënt werklik gestuur het. Loop dit ook een keer met ’n doelbewus verkeerde wagwoord, sodat jy die verskil tussen ’n weiering en ’n module-fout kan sien. Daardie twee uitkomste lyk identies in die VPN-logboek en heeltemal anders hier.

’n Toegewyde diens is beter as om die aanmelding te wysig

Gee die VPN sy eie dienslêer wanneer sy vereistes van interaktiewe aanmelding verskil, wat gewoonlik die geval is. Om login of common-auth te wysig, verander die beleid vir elke program wat hulle insluit, en die volgende persoon wat ’n onverwante aanmeldingsprobleem ontfout, erf jou verandering.

Kopieer die modules wat jy nodig het na ’n klein dienslêer, hou die volgorde eksplisiet, en noteer wie dit besit. Daardie lêer is die ding om na te kyk wanneer ’n wagwoordherstel geen effek blyk te hê nie.

Wat die kliënt stuur, en wat dit nie stuur nie

Die kliënt voorsien ’n gebruikersnaam en wagwoord deur sy ondersteunde opdrag of lêer. Die bediener-inprop gee daardie waardes aan die PAM-gesprek; dit lees hulle nie uit die bediener se konfigurasie nie. ’n Bediener-kant reël wat lyk of dit ’n wagwoord definieer, doen dit nie, en geen profielwysiging sal ’n rekening skep nie.

Gebruikersnaam en wagwoord kan saam met kliëntsertifikate bestaan, en om PAM te aktiveer is nie ’n rede om op te hou om sertifikate te verifieer nie. Hou die lae wat die ontplooiing bedoel het, en regstel net die rekeningbron.

Aanvaarding is tweeledig: die beoogde rekening slaag, en ’n rekening wat geweier moet word, misluk steeds. Die auth-pam-inprop se README dokumenteer die diens-argument en die backends wat dit kan bedien, en dit is die plek om die reëling te bevestig wat jy probeer bou.