OpenVPN PAM: pieteikšanās arguments ir pakalpojums, nevis lietotājs

Serverī tika pievienots lietotājs, parole tika ievadīta pareizi, un savienojums tomēr beidzas ar AUTH_FAILED. Spraudņa rinda parasti izskaidro kāpēc: vārds aiz spraudņa ceļa ir PAM pakalpojuma nosaukums, un tas nosaka, kura moduļu steķe atbild uz jautājumu. Tas nav lietotājvārds, un tas nav rādītājs uz paroles failu, kuru OpenVPN lasa pats.

Ko izvēlas otrais vārds

Konfigurācijas rinda ņem spraudņa ceļu un vienu argumentu:

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

Šis arguments tiek nodots PAM bibliotēkai kā pakalpojuma nosaukums, tāpēc tiek palaista steķe /etc/pam.d/openvpn. Ja tur ierakstīsiet login, jūs tā vietā iegūsiet interaktīvo pieteikšanās politiku ar tiem moduļiem, kurus šī politika ietver jūsu distribūcijā.

Izmantojiet spraudņa ceļu, ko nodrošina instalētā pakotne, nevis ceļu, kas nokopēts no cita resursdatora. Faila nosaukums un direktorijs dažādās distribūcijās atšķiras, un nepareizs ceļš neizdodas startēšanas laikā ar spraudņa ielādes kļūdu, nevis autentifikācijas laikā.

Kur steķe faktiski lasa kontus

PAM ir izsūtītājs. Pakalpojuma fails moduļus uzskaita secībā, un pirmais, kas spēj atbildēt, nosaka iznākumu. Steķe, kas izsauc pam_unix, lasa lokālos kontus; steķe, kas izsauc LDAP vai RADIUS moduli, nosūta akreditācijas datus pavisam citur.

Izlasiet failu, uz kuru atrisinās pakalpojuma nosaukums, tostarp visu, ko tas ietver:

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

Ja steķe deleģē direktorijam, lokāla konta pievienošana neko nemaina. Ja tā lasa lokālos kontus, arī lietotāja izveide direktorijā neko nemaina. Kontam ir jāpastāv tur, kur steķe skatās, un tā ir visa diagnostika lielākajā daļā šo ziņojumu.

Viens mēģinājums, divi žurnāli

Korelējiet vienu neizdevušos savienojumu abās pusēs. OpenVPN žurnāls parāda spraudņa rezultātu un klienta atteikumu; sistēmas autentifikācijas žurnāls parāda, kurš modulis darbojās un ko tas nolēma. Lasīt tos vienā laika logā ir tas, kas atdala trūkstošu pakalpojuma failu no aizmugures sistēmas noildzes. Tukšums autentifikācijas žurnālā nozīmē, ka steķe netika sasniegta vispār.

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

Pārbaudiet pakalpojumu tieši ar utilītu, kas runā PAM, lai jūs nedarītu atkļūdošanu gan VPN, gan steķē vienlaikus. Veiksmīga tieša pārbaude ar to pašu pakalpojuma nosaukumu un kontu sašaurina problēmu līdz tam, kā dēmons nodod akreditācijas datus, nevis pašam kontam.

pamtester openvpn alice authenticate

Ja tiešā pārbaude neizdodas ar tiem pašiem akreditācijas datiem, kas strādā konsolē, steķe nelasa jūsu pieņemto kontu avotu. Ja tā izdodas, apskatiet sarunu, ko vada spraudnis, un to, ko klients faktiski nosūtīja. Palaidiet to arī vienreiz ar tīši nepareizu paroli, lai jūs redzētu atšķirību starp atteikumu un moduļa kļūdu. Šie divi iznākumi VPN žurnālā izskatās identiski un šeit — pilnīgi atšķirīgi.

Atsevišķs pakalpojums ir labāks par pieteikšanās rediģēšanu

Dodiet VPN savu pakalpojuma failu, ja tā prasības atšķiras no interaktīvās pieteikšanās, kā tas parasti notiek. login vai common-auth rediģēšana maina politiku ikvienai programmai, kas tos ietver, un nākamais cilvēks, kas atkļūdos nesaistītu pieteikšanās problēmu, mantos jūsu izmaiņas.

Nokopējiet nepieciešamos moduļus mazā pakalpojuma failā, saglabājiet skaidru secību un atzīmējiet, kam tas pieder. Šis fails ir tas, kas jāpārbauda, kad paroles atiestatīšana, šķiet, nedod rezultātu.

Ko klients sūta un ko ne

Klients piegādā lietotājvārdu un paroli, izmantojot atbalstīto uzvedni vai failu. Servera spraudnis nodod šīs vērtības PAM sarunā; tas tās nelasa no servera konfigurācijas. Servera puses rinda, kas izskatās pēc paroles definēšanas, to nedara, un neviena profila rediģēšana neizveidos kontu.

Lietotājvārds un parole var pastāvēt līdzās klienta sertifikātiem, un PAM iespējošana nav iemesls pārtraukt sertifikātu pārbaudi. Saglabājiet slāņus, ko izvietošana bija paredzējusi, un labojiet tikai kontu avotu.

Pieņemšana ir divpusēja: paredzētais konts izdodas, un konts, kuram vajadzētu atteikt, joprojām neizdodas. Fails auth-pam spraudņa README dokumentē pakalpojuma argumentu un aizmugures sistēmas, ko tas var apkalpot, un tur ir vieta, kur apstiprināt izkārtojumu, ko mēģināt izveidot.