OpenVPN PAM: argumentul de autentificare este un serviciu, nu un utilizator

Un utilizator a fost adăugat pe server, parola a fost tastată corect, iar conexiunea se termină totuși cu AUTH_FAILED. Linia pluginului explică de obicei de ce: cuvântul de după calea pluginului este un nume de serviciu PAM, iar el decide ce stivă de module răspunde întrebării. Nu este un nume de utilizator și nu este un indicator către un fișier de parole pe care OpenVPN îl citește singur.

Ce selectează al doilea cuvânt

Linia de configurare ia o cale de plugin și un argument:

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

Argumentul este transmis bibliotecii PAM ca nume de serviciu, ceea ce face ca stiva din /etc/pam.d/openvpn să fie cea care rulează. Dacă scrieți login acolo, obțineți în schimb politica de autentificare interactivă, cu modulele pe care acea politică le include în distribuția dumneavoastră.

Folosiți calea pluginului oferită de pachetul instalat, nu o cale copiată de pe alt host. Numele fișierului și directorul diferă între distribuții, iar o cale greșită eșuează la pornire cu o eroare de încărcare a pluginului, nu la autentificare.

De unde citește stiva de fapt conturile

PAM este un dispecer. Fișierul de serviciu listează modulele în ordine, iar primul care poate răspunde decide rezultatul. O stivă care apelează pam_unix citește conturi locale; o stivă care apelează un modul LDAP sau RADIUS trimite credențialele cu totul altundeva.

Citiți fișierul în care se rezolvă numele serviciului, inclusiv tot ce include:

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

Dacă stiva delegă către un director, adăugarea unui cont local nu schimbă nimic. Dacă citește conturi locale, crearea utilizatorului în director nu schimbă nimic nici ea. Contul trebuie să existe acolo unde se uită stiva, și acesta este întregul diagnostic în majoritatea acestor rapoarte.

O încercare, două jurnale

Corelați o singură conexiune eșuată pe ambele părți. Jurnalul OpenVPN arată rezultatul pluginului și respingerea clientului; jurnalul de autentificare al sistemului arată ce modul a rulat și ce a decis. Citirea lor în aceeași fereastră de timp este ceea ce separă un fișier de serviciu lipsă de un timeout al backendului. O lacună în jurnalul de autentificare înseamnă că stiva nu a fost atinsă deloc.

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

Testați serviciul direct cu un utilitar care vorbește PAM, ca să nu depanați VPN-ul și stiva în același timp. Un test direct reușit cu același nume de serviciu și cont restrânge problema la modul în care demonul transmite credențialele, nu la contul în sine.

pamtester openvpn alice authenticate

Dacă testul direct eșuează cu aceleași credențiale care funcționează într-o consolă, stiva nu citește sursa de conturi pe care ați presupus-o. Dacă reușește, priviți conversația pe care o duce pluginul și ce a trimis clientul de fapt. Rulați-l și o dată cu o parolă intenționat greșită, ca să vedeți diferența dintre o respingere și o eroare de modul. Aceste două rezultate arată identic în jurnalul VPN și complet diferit aici.

Un serviciu dedicat bate editarea autentificării

Dați VPN-ului propriul fișier de serviciu atunci când cerințele lui diferă de autentificarea interactivă, ceea ce se întâmplă de obicei. Editarea login sau common-auth schimbă politica pentru fiecare program care le include, iar următoarea persoană care depanează o problemă de autentificare fără legătură moștenește modificarea dumneavoastră.

Copiați modulele de care aveți nevoie într-un fișier de serviciu mic, păstrați ordinea explicită și notați cine îl deține. Acel fișier este lucrul de verificat atunci când o resetare de parolă pare să nu aibă niciun efect.

Ce trimite clientul și ce nu trimite

Clientul furnizează un nume de utilizator și o parolă prin promptul sau fișierul său acceptat. Pluginul de server transmite acele valori în conversația PAM; nu le citește din configurația serverului. O linie din partea serverului care pare să definească o parolă nu face asta, iar nicio editare de profil nu va crea un cont.

Numele de utilizator și parola pot coexista cu certificatele de client, iar activarea PAM nu este un motiv să nu mai verificați certificatele. Păstrați straturile pe care implementarea le-a dorit și reparați doar sursa de conturi.

Acceptarea este bidirecțională: contul dorit reușește, iar un cont care ar trebui refuzat eșuează în continuare. Fișierul README al pluginului auth-pam documentează argumentul de serviciu și backendurile pe care le poate deservi, și acolo se confirmă aranjamentul pe care încercați să îl construiți.