OpenVPN PAM: la ensaluta argumento estas servo, ne uzanto

Uzanto estis aldonita sur la servilo, la pasvorto estis tajpita ĝuste, kaj la konekto ankoraŭ finiĝas per AUTH_FAILED. La kromaĵa linio kutime klarigas kial: la vorto post la kromaĵa vojo estas PAM-serva nomo, kaj ĝi decidas, kiu stako de moduloj respondas la demandon. Ĝi ne estas uzantnomo, kaj ĝi ne estas montrilo al pasvorta dosiero, kiun OpenVPN mem legas.

Kion elektas la dua vorto

La agorda linio prenas kromaĵan vojon kaj unu argumenton:

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

Tiu argumento estas transdonita al la PAM-biblioteko kiel la serva nomo, kio igas la stakon ĉe /etc/pam.d/openvpn la rulanta. Skribu login tie kaj vi ricevas anstataŭe la interagan ensalutan politikon, kun ĉiuj moduloj, kiujn tiu politiko hazarde inkluzivas en via distribuo.

Uzu la kromaĵan vojon, kiun provizas la instalita pako, anstataŭ vojo kopiita de alia gastiganto. La dosiernomo kaj dosierujo diferencas inter distribuoj, kaj malĝusta vojo malsukcesas ĉe starto per kromaĵa ŝarĝa eraro, ne ĉe aŭtentigo.

Kie la stako efektive legas kontojn

PAM estas dispeĉero. La serva dosiero listigas modulojn laŭ ordo, kaj la unua, kiu povas respondi, decidas la rezulton. Stako, kiu vokas pam_unix, legas lokajn kontojn; stako, kiu vokas LDAP aŭ RADIUS modulon, sendas la legitimilojn tute aliloken.

Legu la dosieron, al kiu la serva nomo solviĝas, inkluzive de ĉio, kion ĝi inkluzivas:

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

Se la stako delegas al dosierujo, aldoni lokan konton ŝanĝas nenion. Se ĝi legas lokajn kontojn, krei la uzanton en la dosierujo ankaŭ ŝanĝas nenion. La konto devas ekzisti tie, kie la stako rigardas, kaj tio estas la tuta diagnozo en la plej multaj el ĉi tiuj raportoj.

Unu provo, du protokoloj

Koreligu unu malsukcesan konekton ambaŭflanke. La OpenVPN-protokolo montras la rezulton de la kromaĵo kaj la malakcepton de la kliento; la sistema aŭtentiga protokolo montras, kiu modulo rulis kaj kion ĝi decidis. Legi ilin en la sama tempofenestro estas tio, kio apartigas mankantan servan dosieron de backend-tempoŝtemo. Manko en la aŭtentiga protokolo signifas, ke la stako neniam estis atingita.

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

Testu la servon rekte per ilo, kiu parolas PAM, por ke vi ne sencimigu la VPN kaj la stakon samtempe. Sukcesa rekta testo kun la sama serva nomo kaj konto mallarĝigas la problemon al tio, kiel la demono transdonas legitimilojn, ne al la konto mem.

pamtester openvpn alice authenticate

Se la rekta testo malsukcesas kun la samaj legitimiloj, kiuj funkcias ĉe konzolo, la stako ne legas la kontan fonton, kiun vi supozis. Se ĝi sukcesas, rigardu la konversacion, kiun la kromaĵo rulas, kaj tion, kion la kliento efektive sendis. Rulu ĝin ankaŭ unufoje kun intence malĝusta pasvorto, por ke vi vidu la diferencon inter malakcepto kaj modula eraro. Tiuj du rezultoj aspektas identaj en la VPN-protokolo kaj tute malsamaj ĉi tie.

Dediĉita servo superas redakti la ensalutan

Donu al la VPN sian propran servan dosieron, kiam ĝiaj postuloj diferencas de interaga ensaluto, kion ili kutime faras. Redakti login aŭ common-auth ŝanĝas la politikon por ĉiu programo, kiu inkluzivas ilin, kaj la sekva persono, kiu sencimigos ne rilatan ensalutan problemon, heredas vian ŝanĝon.

Kopiu la modulojn, kiujn vi bezonas, en malgrandan servan dosieron, tenu la ordon eksplicita, kaj notu, kiu posedas ĝin. Tiu dosiero estas la afero kontrolenda, kiam pasvorta restarigo ŝajnas havi neniun efikon.

Kion la kliento sendas, kaj kion ĝi ne sendas

La kliento provizas uzantnomon kaj pasvorton per sia subtenata invito aŭ dosiero. La servila kromaĵo transdonas tiujn valorojn en la PAM-konversacion; ĝi ne legas ilin el la servila agordo. Servila linio, kiu aspektas kvazaŭ ĝi difinas pasvorton, ne faras tion, kaj neniu profila redakto kreos konton.

Uzantnomo kaj pasvorto povas kunekzisti kun klientaj atestiloj, kaj ebligi PAM ne estas kialo ĉesi kontroli atestilojn. Konservu la tavolojn, kiujn la deplojo intencis, kaj riparu nur la kontan fonton.

Akcepto estas dudirekta: la celita konto sukcesas, kaj konto, kiu devus esti rifuzita, ankoraŭ malsukcesas. La README de la kromaĵo auth-pam dokumentas la servan argumenton kaj la backend-ojn, kiujn ĝi povas fronti, kaj tio estas la loko por konfirmi la aranĝon, kiun vi provas konstrui.