OpenVPN PAM: argumenti i hyrjes është një shërbim, jo një përdorues

Një përdorues u shtua në server, fjalëkalimi u shkrua saktë, dhe lidhja prapë përfundon me AUTH_FAILED. Rreshti i shtojcës zakonisht shpjegon pse: fjala pas shtegut të shtojcës është emër shërbimi PAM, dhe ajo vendos cila stivë modulësh i përgjigjet pyetjes. Nuk është emër përdoruesi, dhe nuk është tregues për një skedar fjalëkalimesh që OpenVPN e lexon vetë.

Çfarë zgjedh fjala e dytë

Rreshti i konfigurimit merr një shteg shtojce dhe një argument:

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

Ky argument i kalohet bibliotekës PAM si emri i shërbimit, çka bën që stiva në /etc/pam.d/openvpn të jetë ajo që ekzekutohet. Shkruani login atje dhe në vend të saj merrni politikën interaktive të hyrjes, me modulët që ajo politikë përfshin në shpërndarjen tuaj.

Përdorni shtegun e shtojcës që ofron paketa e instaluar, jo një shteg të kopjuar nga një host tjetër. Emri i skedarit dhe drejtoria ndryshojnë midis shpërndarjeve, dhe një shteg i gabuar dështon në nisje me një gabim ngarkimi të shtojcës, jo në vërtetim.

Ku i lexon stiva llogaritë në të vërtetë

PAM është një shpërndarës. Skedari i shërbimit i liston modulët me radhë, dhe i pari që mund të përgjigjet vendos rezultatin. Një stivë që thërret pam_unix lexon llogari lokale; një stivë që thërret një modul LDAP ose RADIUS i dërgon kredencialet diku tjetër krejt.

Lexoni skedarin ku zgjidhet emri i shërbimit, duke përfshirë çdo gjë që ai përfshin:

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

Nëse stiva i delegon një drejtorie, shtimi i një llogarie lokale nuk ndryshon asgjë. Nëse lexon llogari lokale, krijimi i përdoruesit në drejtori nuk ndryshon asgjë as ai. Llogaria duhet të ekzistojë atje ku shikon stiva, dhe ky është i gjithë diagnostikimi në shumicën e këtyre raporteve.

Një provë, dy regjistra

Ndërlidhni një lidhje të dështuar në të dyja anët. Regjistri i OpenVPN tregon rezultatin e shtojcës dhe refuzimin e klientit; regjistri i vërtetimit të sistemit tregon cili modul u ekzekutua dhe çfarë vendosi. Leximi i tyre në të njëjtën dritare kohe është ajo që ndan një skedar shërbimi që mungon nga një afat kohor i backend-it. Një boshllëk në regjistrin e vërtetimit do të thotë që stiva nuk u arrit kurrë.

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

Provoni shërbimin drejtpërdrejt me një mjet që flet PAM, që të mos korrigjoni njëkohësisht VPN-në dhe stivën. Një provë e drejtpërdrejtë e suksesshme me të njëjtin emër shërbimi dhe llogari e ngushton problemin te mënyra se si daemoni i kalon kredencialet, jo te llogaria vetë.

pamtester openvpn alice authenticate

Nëse prova e drejtpërdrejtë dështon me të njëjtat kredenciale që funksionojnë në një konsolë, stiva nuk po lexon burimin e llogarive që supozuat. Nëse ka sukses, shikoni bisedën që zhvillon shtojca dhe atë që dërgoi vërtet klienti. Ekzekutojeni edhe një herë me një fjalëkalim qëllimisht të gabuar, që të shihni ndryshimin midis një refuzimi dhe një gabimi moduli. Këto dy rezultate duken njësoj në regjistrin e VPN-së dhe krejt ndryshe këtu.

Një shërbim i dedikuar është më i mirë se redaktimi i hyrjes

Jepini VPN-së skedarin e vet të shërbimit kur kërkesat e tij ndryshojnë nga hyrja interaktive, çka zakonisht ndodh. Redaktimi i login ose common-auth ndryshon politikën për çdo program që i përfshin, dhe personi tjetër që korrigjon një problem hyrjeje të palidhur do të trashëgojë ndryshimin tuaj.

Kopjoni modulët që ju nevojiten në një skedar të vogël shërbimi, mbani rendin të qartë dhe shënoni kush e zotëron. Ai skedar është gjëja që duhet kontrolluar kur një rivendosje fjalëkalimi duket se nuk ka asnjë efekt.

Çfarë dërgon klienti, dhe çfarë nuk dërgon

Klienti furnizon një emër përdoruesi dhe fjalëkalim përmes kërkesës ose skedarit të tij të mbështetur. Shtojca e serverit i kalon ato vlera në bisedën PAM; nuk i lexon nga konfigurimi i serverit. Një rresht në anën e serverit që duket se përcakton një fjalëkalim nuk e bën këtë, dhe asnjë redaktim profili nuk do të krijojë një llogari.

Emri i përdoruesit dhe fjalëkalimi mund të bashkëjetojnë me certifikatat e klientit, dhe aktivizimi i PAM nuk është arsye për të ndaluar verifikimin e certifikatave. Mbani shtresat që parashikonte vendosja dhe rregulloni vetëm burimin e llogarive.

Pranimi është i dyanshëm: llogaria e synuar ka sukses, dhe një llogari që duhet refuzuar prapë dështon. Skedari README i shtojcës auth-pam dokumenton argumentin e shërbimit dhe backend-et që mund të shërbejë, dhe aty është vendi për të konfirmuar rregullimin që po përpiqeni të ndërtoni.