Remediere: OpenVPN nu a putut citi numele de utilizator Auth din intrarea standard

could not read Auth username from stdin pare o problemă de autentificare și nu este. OpenVPN a încercat să ceară numele de utilizator pe intrarea standard, nu a găsit nimic lizibil și s-a oprit înainte de a contacta vreodată serverul. Contul poate fi perfect valid; procesului pur și simplu îi lipsește cineva de întrebat.

De aceea, primul pas util este să confirmați ce citește clientul, nu să reîncercați conexiunea sau să modificați setări pe partea serverului. Parcurgeți verificările de mai jos în ordine și opriți-vă la prima care eșuează.

Citiți eroarea ca pe o defecțiune locală de intrare

Când auth-user-pass apare fără un argument de fișier, clientul se așteaptă să întrebe. Într-un shell interactiv acel prompt funcționează pentru că procesul deține un terminal. Sub systemd, un job cron sau un container, intrarea standard este de obicei goală, iar citirea se întoarce imediat cu eroarea pe care o vedeți.

Mesajul numește și câmpul care a eșuat, numele de utilizator sau parola, ceea ce arată cât de departe a ajuns citirea. Un nume de utilizator lipsă înseamnă că procesul nu a putut citi absolut nimic. O parolă lipsă după un nume de utilizator reușit înseamnă că fluxul de intrare s-a încheiat între cele două citiri, ceea ce este tipic pentru un fișier scris pe jumătate sau pentru o conductă închisă.

Confirmați viziunea clientului însuși înainte de a schimba altceva. Rulați-l în prim-plan cu aceeași configurație și același utilizator și observați dacă promptul apare. Dacă apare în shell-ul dumneavoastră dar nu sub managerul de servicii, diferența este sursa de intrare, nu credențialele. O comparație rapidă între fișierul unit și mediul shell-ului arată de obicei care dintre ele furnizează un terminal.

Oferiți serviciului o sursă de credențiale acceptată

Sursa acceptată pentru funcționarea nesupravegheată este un fișier de credențiale transmis ca argument către auth-user-pass. Fișierul este citit ca text simplu: prima linie este numele de utilizator, a doua este parola. Indicați-l cu o cale absolută, de exemplu /etc/openvpn/client/creds , astfel încât directorul de lucru al contului de serviciu să nu poată schimba sensul directivei.

Permisiunile contează la fel de mult ca calea. Fișierul trebuie să fie lizibil de contul care rulează clientul și nu de toți ceilalți, și ar trebui să aparțină contului de serviciu sau lui root cu un grup care include serviciul. Verificați lizibilitatea ca acel cont, fără a tipări conținutul.

O cale relativă este modul de eșec silențios. Profilul poate fi într-un director în timp ce systemd pornește procesul în altă parte, așa că un fișier care se rezolvă în shell-ul dumneavoastră nu se rezolvă pentru serviciu. Mutați credențialele într-o locație fixă și faceți referire la ele în mod absolut. Apoi porniți serviciul o dată și confirmați că se folosește aceeași cale, în loc să vă bazați pe vizualizarea editorului de profiluri.

Dacă implementarea necesită un cod de unică folosință sau o altă provocare interactivă, decideți dacă fluxul de lucru al clientului o acceptă cu adevărat nesupravegheat. Un fișier cu o parolă statică nu poate răspunde unui cod care se rotește, iar reîncercarea unui prompt fără răspuns nu adaugă informație.

De ce script-security nu va ajuta

script-security controlează dacă clientul poate rula scripturi și cât poate transmite acestora, inclusiv dacă o parolă poate fi dată unui script printr-o variabilă de mediu. Nu spune nimic despre de unde provin numele de utilizator și parola.

Ridicarea lui la un nivel superior este un reflex obișnuit pentru că mesajul menționează Auth, dar schimbă permisiunile scripturilor, nu sursa de intrare, și lărgește ce poate executa clientul. Dacă un script auxiliar face parte din proiect, remediați mai întâi sursa de intrare și mențineți nivelul de securitate la cea mai mică valoare de care are nevoie implementarea.

Interfața de gestionare este o alternativă legitimă. Un frontend se poate conecta la ea, poate primi cererea de credențiale și poate răspunde cu numele de utilizator și parola, așa funcționează unele GUI. Dacă o folosiți, legați-o de o adresă locală, protejați-o cu un fișier de parolă de gestionare și restricționați cine se poate conecta, pentru că este un canal de control al clientului.

Verificați etapa următoare după ce clientul citește fișierul

Odată ce clientul poate citi credențialele, următoarea defecțiune este un schimb real cu serverul, iar mesajul său are o semnificație diferită. O defecțiune de autentificare în acea etapă înseamnă că serverul a respins contul; un răspuns de provocare înseamnă că serverul vrea un alt factor. Tratați-le ca probleme noi, nu ca pe aceeași problemă repetată.

Testați întreaga cale așa cum o va rula serviciul: același cont, același director de lucru, același mediu unit. O conexiune care funcționează doar când este pornită din shell-ul dumneavoastră este un semn că o variabilă de mediu sau un terminal face încă parte din flux.

Apoi păstrați secretele unde le este locul. Parolele din argumentele liniei de comandă apar în tabelul proceselor, iar parolele din ieșirea de depanare ajung în tichete. Folosiți un fișier protejat sau interfața de gestionare, păstrați jurnalele la un nivel care nu repetă credențiale și rotiți fișierul când pleacă cineva cu acces.

Listă de verificare: cale absolută a credențialelor, lizibilă ca cont de serviciu, fără terminal necesar, script-security lăsat la minim, interfață de gestionare doar dacă este legată și autentificată, iar răspunsul serverului rezultat tratat ca un eveniment separat.