Serviciul OpenVPN se blochează la cererea parolei cheii private: cum se repară

OpenVPN cere fraza de acces a cheii private pe mașina locală, așa că un fișier de autentificare funcțional nu îi răspunde niciodată. Într-un serviciu nu există terminal pentru tastare, iar pornirea fie se blochează, fie eșuează cu o intrare în journal care numește intrarea, nu cauza. Sunt implicate două secrete, iar fiecare are nevoie de propria sursă lizibilă înainte de repornirea unit-ului. Parcursul de mai jos le separă, apoi verifică identitatea care deschide efectiv fiecare fișier.

Distingeți cele două cereri

Fraza de acces a cheii decriptează cheia privată locală; datele contului autentifică sesiunea la server. Ele vin din locuri diferite, eșuează în momente diferite și produc mesaje diferite. Confundarea lor trimite oamenii să caute resetarea parolei deși contul nu era implicat. Citiți textul cererii înainte de a schimba orice opțiune, fiindcă formularea este singurul indiciu de încredere despre ce secret lipsește.

În Community OpenVPN 2.x, askpass indică un fișier care ține fraza de acces a cheii pe prima linie, iar auth-user-pass indică un fișier cu numele de utilizator pe o linie și parola pe următoarea. Niciunul dintre fișiere nu satisface cealaltă opțiune. O aplicație desktop sau un profil NetworkManager pot păstra ambele în propriul depozit de secrete, pe care un client din linia de comandă nu îl citește niciodată, așa că notați ce client configurați înainte de a scrie vreo cale.

Îndreptați ambele opțiuni spre fișiere lizibile

Un profil care are nevoie de ambele intrări ajunge cu trei referințe la fișiere: cheia criptată, fraza de acces care o deblochează și perechea de autentificare. Adăugați-le fără să atingeți CA sau verificările de identitate, fiindcă acestea decid cine este serverul și nu fac parte din această problemă. Dacă implementarea nu folosește deloc date de cont, adăugarea auth-user-pass creează o intrare pe care nimeni nu o poate furniza.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Opțiunile fără argument se comportă diferit de cele cu cale, iar într-un serviciu diferența contează. Un askpass fără argument citește tot consola, iar un fișier auth-user-pass cu doar un nume de utilizator lasă tot o cerere de parolă în așteptare. Odată ce clientul devine daemon, nu mai poate cere deloc intrare de la terminal, așa că un serviciu configurat astfel nu pornește.

Căile absolute elimină întrebarea despre directorul de lucru, dar nu acordă acces. Urmează proprietatea, modul și traversarea, iar toate trei sunt verificate față de contul sub care rulează procesul.

Citiți configurația unit-ului înainte de profil

Unit-ul, nu fișierul pe care îl editați, decide ce configurație încarcă instanța. Citiți linia de comandă și orice drop-in, apoi urmați directorul de lucru până la profilul folosit efectiv. O referință la fraza de acces adăugată în alt fișier .ovpn nu schimbă nimic pentru această instanță.

Trei comenzi doar-citire răspund la cea mai mare parte. Prima afișează unit-ul și orice drop-in, a doua identitatea și setările de sandbox care leagă procesul, iar a treia ce a reclamat efectiv ultima pornire. Folosiți numele de instanță care există pe gazdă:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Fiți atenți la ProtectHome și la opțiunile proprii ale profilului user, group și chroot. Un fișier dintr-un director home poate fi lizibil în shell-ul dvs. și invizibil în serviciu după ce directoarele home sunt ascunse. Contul cu care pornește systemd nu este mereu contul care deschide la final cheia.

Dovediți că identitatea de execuție poate deschide ambele fișiere

Citirea modului nu este suficientă, fiindcă fiecare director de pe cale trebuie să fie traversabil de aceeași identitate. Parcurgeți calea componentă cu componentă, apoi testați deschiderea ca contul folosit de proces. Un fișier cu modul 600 deținut de root funcționează doar cât timp procesul este încă root, ceea ce nu mai e adevărat după coborârea privilegiilor pe care o fac multe profiluri. Două comenzi acoperă traversarea și deschiderea:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

Prima comandă afișează modul fiecărei componente și eșuează acolo unde contul nu poate traversa; a doua răspunde la singura întrebare importantă, dacă identitatea de execuție poate deschide fișierul pentru citire. Niciuna nu afișează conținutul fișierului, și exact asta contează când fișierul ține o frază de acces. Repetați testul pentru fișierul de autentificare, fiindcă cele două sunt des stocate cu proprietari diferiți.

Dacă procesul folosește un chroot sau un namespace restricționat, rulați același test din interiorul acelei vederi, altfel răspunsul descrie sistemul de fișiere greșit. O frază de acces păstrată sub un director home ascuns este exemplul obișnuit de test care trece în afara unit-ului și eșuează înăuntru.

Verificați prima pornire, apoi o reconectare

Porniți instanța o dată și citiți primul eșec, nu ultimul. Un fișier de intrare lipsă, o decriptare a cheii eșuată și un AUTH_FAILED de la server sunt trei evenimente diferite cu trei reparații diferite. Repararea unui avertisment de permisiuni nu dovedește nimic despre dacă cheia a fost deblocată.

Linia din journal spune care dintre cele trei. Reparația decurge din ce intrare a eșuat:

Apoi testați ciclul de viață de care aveți într-adevăr nevoie: o pornire la boot și orice reconectare acceptată, nu doar o pornire manuală din shell-ul dvs. Cu auth-nocache intrările sunt aruncate după prima utilizare, așa că o reconectare ulterioară are tot nevoie de o sursă lizibilă. Un inel de chei deblocat la autentificarea desktop nu este disponibil pentru un serviciu care a pornit înainte ca cineva să se autentifice, iar acesta este motivul obișnuit pentru care un test manual trece și o repornire eșuează. Dacă prima pornire reușește și o reconectare ulterioară eșuează, citiți journal-ul pentru evenimentul de reconectare înainte de a schimba din nou permisiuni.

Păstrarea frazei de acces lângă cheie reduce ceea ce vă oferă criptarea, așa că restricționați acel fișier și copiile lui de siguranță. Tratați eliminarea frazei de acces a cheii ca o decizie separată privind credențialele, nu ca reparația pentru o intrare lipsă. O implementare care depinde de aprobare umană sau de MFA interactivă are nevoie de agentul sau integrarea de administrare acceptată; un cod de unică folosință salvat permanent nu este un substitut echivalent.