OpenVPN PAM: ang argumento ng pag-login ay serbisyo, hindi user

Naidagdag ang isang user sa server, naipasok nang tama ang password, at nagtatapos pa rin ang koneksyon sa AUTH_FAILED. Karaniwang ipinapaliwanag ng linya ng plugin kung bakit: ang salita pagkatapos ng path ng plugin ay isang pangalan ng serbisyong PAM, at ito ang nagpapasya kung aling stack ng mga module ang sasagot sa tanong. Hindi ito username, at hindi ito pointer sa isang password file na OpenVPN ang mismong nagbabasa.

Ano ang pinipili ng ikalawang salita

Ang linya ng configuration ay kumukuha ng path ng plugin at isang argumento:

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

Ang argumentong iyon ay ipinapasa sa PAM library bilang pangalan ng serbisyo, kaya ang stack sa /etc/pam.d/openvpn ang tumatakbo. Isulat ang login doon at makukuha mo sa halip ang interactive na patakaran ng pag-login, kasama ang mga module na kasama ng patakarang iyon sa iyong distribusyon.

Gamitin ang path ng plugin na ibinibigay ng naka-install na pakete, hindi ang path na kinopya mula sa ibang host. Nag-iiba ang pangalan ng file at direktoryo sa bawat distribusyon, at ang maling path ay nabibigo sa pagsisimula na may error sa pag-load ng plugin, hindi sa authentication.

Saan talaga nagbabasa ng mga account ang stack

Ang PAM ay isang dispatcher. Inililista ng service file ang mga module sa pagkakasunod-sunod, at ang una na makakasagot ang nagpapasya sa resulta. Ang stack na tumatawag sa pam_unix ay nagbabasa ng local na account; ang stack na tumatawag sa isang LDAP o RADIUS module ay nagpapadala ng mga kredensyal sa ibang lugar.

Basahin ang file kung saan nire-resolve ang pangalan ng serbisyo, kasama ang lahat ng isinasama nito:

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

Kung ang stack ay nagde-delegate sa isang direktoryo, walang nagbabago kapag nagdagdag ng local na account. Kung nagbabasa ito ng local na account, wala ring nagbabago kapag gumawa ng user sa direktoryo. Dapat umiral ang account sa lugar kung saan tumitingin ang stack, at iyon ang buong diagnosis sa karamihan ng mga ulat na ito.

Isang pagtatangka, dalawang log

Iugnay ang isang nabigong koneksyon sa magkabilang panig. Ipinapakita ng OpenVPN log ang resulta ng plugin at ang pagtanggi ng client; ipinapakita ng authentication log ng system kung aling module ang tumakbo at ano ang pinasya nito. Ang pagbasa sa kanila sa parehong time window ang naghihiwalay sa nawawalang service file mula sa backend timeout. Ang puwang sa authentication log ay nangangahulugang hindi naabot ang stack.

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

Subukan ang serbisyo nang direkta gamit ang utility na nagsasalita ng PAM, para hindi mo sabay na i-debug ang VPN at ang stack. Ang matagumpay na direktang pagsubok na may parehong pangalan ng serbisyo at account ay nagpapaliit ng problema sa paraan ng pagpapasa ng kredensyal ng daemon, hindi sa account mismo.

pamtester openvpn alice authenticate

Kung ang direktang pagsubok ay nabigo gamit ang parehong kredensyal na gumagana sa console, hindi binabasa ng stack ang pinagmulan ng account na inaasahan mo. Kung nagtagumpay ito, tingnan ang pag-uusap na pinapatakbo ng plugin at ang aktwal na ipinadala ng client. Patakbuhin din ito nang isang beses na may sadyang maling password, para makita mo ang pagkakaiba ng pagtanggi at error ng module. Ang dalawang resultang iyon ay magkapareho sa VPN log at ganap na iba dito.

Mas mabuti ang hiwalay na serbisyo kaysa i-edit ang pag-login

Bigyan ang VPN ng sarili nitong service file kapag ang mga pangangailangan nito ay naiiba sa interactive na pag-login, na karaniwang nangyayari. Ang pag-edit ng login o common-auth ay nagbabago ng patakaran para sa bawat program na nagsasama sa kanila, at ang susunod na taong mag-de-debug ng walang kaugnayang problema sa pag-login ay mamamana ang iyong pagbabago.

Kopyahin ang mga module na kailangan mo sa isang maliit na service file, panatilihing tahasan ang pagkakasunod-sunod, at itala kung kanino ito. Ang file na iyon ang dapat suriin kapag ang pag-reset ng password ay tila walang epekto.

Ano ang ipinapadala ng client, at ano ang hindi

Ang client ay nagbibigay ng username at password sa pamamagitan ng sinusuportahang prompt o file nito. Ipinapasa ng server plugin ang mga halagang iyon sa PAM conversation; hindi niya ito binabasa mula sa configuration ng server. Ang linyang nasa gilid ng server na mukhang tumutukoy ng password ay hindi iyon ginagawa, at walang pag-edit ng profile ang gagawa ng account.

Maaaring magkasama ang username at password at ang mga certificate ng client, at ang pagpapagana ng PAM ay hindi dahilan para itigil ang pag-verify ng mga certificate. Panatilihin ang mga layer na nilayon ng deployment at ayusin lamang ang pinagmulan ng account.

Ang pagtanggap ay may dalawang panig: nagtagumpay ang inilaan na account, at nabibigo pa rin ang account na dapat tanggihan. Ang file README ng auth-pam plugin ay nagdodokumento ng argumento ng serbisyo at ng mga backend na maaari nitong pagsilbihan, at doon mo makukumpirma ang kaayusang sinusubukan mong buuin.