OpenVPN PAM: hoja ya kuingia ni huduma, si mtumiaji

Mtumiaji aliongezwa kwenye seva, nenosiri liliandikwa ipasavyo, na muunganisho bado unaishia na AUTH_FAILED. Mstari wa programu-jalizi kwa kawaida hueleza kwa nini: neno baada ya njia ya programu-jalizi ni jina la huduma ya PAM, na huamua rafu ipi ya moduli inayojibu swali. Si jina la mtumiaji, na si kielekezi cha faili la nenosiri ambalo OpenVPN hulisoma lenyewe.

Neno la pili huchagua nini

Mstari wa usanidi huchukua njia ya programu-jalizi na hoja moja:

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

Hoja hiyo hupewa maktaba ya PAM kama jina la huduma, jambo ambalo hufanya rafu iliyo /etc/pam.d/openvpn iwe ndiyo inayoendeshwa. Andika login hapo na badala yake utapata sera ya kuingia inayoshirikiana, pamoja na moduli ambazo sera hiyo inajumuisha kwenye usambazaji wako.

Tumia njia ya programu-jalizi inayotolewa na kifurushi kilichosakinishwa, si njia iliyonakiliwa kutoka kwa mwenyeji mwingine. Jina la faili na saraka hutofautiana kati ya usambazaji, na njia isiyo sahihi hushindwa wakati wa kuanza kwa hitilafu ya upakiaji wa programu-jalizi, si wakati wa uthibitishaji.

Rafu husoma akaunti wapi hasa

PAM ni msambazaji. Faili la huduma huorodhesha moduli kwa mpangilio, na ile ya kwanza inayoweza kujibu huamua matokeo. Rafu inayoiita pam_unix husoma akaunti za ndani; rafu inayoiita moduli ya LDAP au RADIUS hutuma vitambulisho mahali pengine kabisa.

Soma faili ambalo jina la huduma hutatua kwenda kwake, likijumuisha kila kitu linalojumuisha:

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

Ikiwa rafu inakabidhi kwa saraka, kuongeza akaunti ya ndani hakubadilishi kitu. Ikiwa inasoma akaunti za ndani, kuunda mtumiaji kwenye saraka pia hakubadilishi kitu. Akaunti lazima iwepo mahali rafu inatazama, na hilo ndilo uchunguzi wote katika ripoti nyingi hizi.

Jaribio moja, kumbukumbu mbili

Unganisha muunganisho mmoja ulioshindwa kwa pande zote mbili. Kumbukumbu ya OpenVPN huonyesha matokeo ya programu-jalizi na kukataliwa na mteja; kumbukumbu ya uthibitishaji ya mfumo huonyesha ni moduli gani iliendeshwa na iliamua nini. Kuzisoma katika dirisha moja la muda ndiko kunakotenganisha faili la huduma linalokosekana na muda wa mwisho wa backend. Pengo katika kumbukumbu ya uthibitishaji humaanisha kwamba rafu haikufikiwa kamwe.

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

Jaribu huduma moja kwa moja kwa chombo kinachozungumza PAM, ili usirekebishe VPN na rafu kwa wakati mmoja. Jaribio la moja kwa moja lililofanikiwa lenye jina la huduma na akaunti sawa hupunguza tatizo hadi jinsi daemon inavyopitisha vitambulisho, si kwa akaunti yenyewe.

pamtester openvpn alice authenticate

Ikiwa jaribio la moja kwa moja linashindwa na vitambulisho vile vile vinavyofanya kazi kwenye konsoli, rafu haisomi chanzo cha akaunti ulichodhani. Ikiwa linafanikiwa, tazama mazungumzo ambayo programu-jalizi inaendesha na kile mteja alichotuma hasa. Iendeshe pia mara moja na nenosiri lililokosewa kwa makusudi, ili uone tofauti kati ya kukataa na hitilafu ya moduli. Matokeo hayo mawili yanaonekana sawa katika kumbukumbu ya VPN na tofauti kabisa hapa.

Huduma maalum ni bora kuliko kuhariri kuingia

Ipe VPN faili la huduma yake mwenyewe wakati mahitaji yake yanatofautiana na kuingia kwa mwingiliano, jambo ambalo kwa kawaida hufanya. Kuhariri login au common-auth hubadilisha sera kwa kila programu inayozijumuisha, na mtu anayefuata kurekebisha tatizo la kuingia lisilohusiana atarithi mabadiliko yako.

Nakili moduli unazohitaji kwenye faili ndogo la huduma, weka mpangilio wazi, na andika ni nani anamiliki. Faili hilo ndilo la kukagua wakati kuweka upya nenosiri kunaonekana kutokuwa na athari.

Mteja hutuma nini, na hatumi nini

Mteja hutoa jina la mtumiaji na nenosiri kupitia ombi au faili lake linalotumika. Programu-jalizi ya seva hupitisha thamani hizo kwenye mazungumzo ya PAM; haisomi kutoka kwenye usanidi wa seva. Mstari wa upande wa seva unaoonekana kufafanua nenosiri haufanyi hivyo, na hakuna uhariri wa profile utakaounda akaunti.

Jina la mtumiaji na nenosiri vinaweza kuwepo pamoja na vyeti vya mteja, na kuwezesha PAM si sababu ya kuacha kuthibitisha vyeti. Weka tabaka ambazo usambazaji ulikusudia na rekebisha chanzo cha akaunti pekee.

Kukubali ni kwa pande mbili: akaunti inayokusudiwa inafanikiwa, na akaunti inayopaswa kukataliwa bado inashindwa. Faili README ya programu-jalizi ya auth-pam hueleza hoja ya huduma na backend ambazo inaweza kuhudumia, na hapo ndipo mahali pa kuthibitisha mpangilio unaojaribu kujenga.