OpenVPN auth-user-pass: failas, stdin ar raginys? Kaip pasirinkti

Trys dalykai nulemia, kurį prisijungimo duomenų šaltinį naudoti: ar prie konsolės sėdi žmogus, ar paslaptis gali gyventi diske ir ar kitas procesas turi atsakyti į raginimą. Pasirinkus neteisingai, klientas praneša apie stdin problemą, nors slaptažodis visiškai galioja, ir tai be priežasties nukreipia daugumą į serverį. Pirmiausia pasirinkite kelią; klaidų pranešimai turi prasmę tik tada, kai žinote, kuris kelias juos sukūrė.

Trys sąlygos, kurios tai nulemia

Konsolės raginimas yra vienintelis kelias, kuriam reikia žmogaus, todėl jis vienintelis tyliai sugenda systemd įrenginyje ar konteineryje. Jei žmogus paleidžia klientą ir įveda slaptažodį, joks failas nedalyvauja ir niekas jautraus nepatenka į diską. Jei klientas paleidžiamas įkrovimo metu, tas pats raginimas tampa pakibimu, o laiko limitas paprastai pasirodo kaip bendra ryšio klaida, o ne prisijungimo duomenų klaida.

Prisijungimo duomenų failas yra teisingas atsakymas, kai procesas paleidžiamas be priežiūros ir paslaptis gali išlikti diske pagal kontroliuojamą leidimų rinkinį. Kai paslapties apskritai negalima įrašyti - tik saugyklos politika, trumpalaikis žetonas - reikia srauto, kurį klientas gali atidaryti, o tai praktiškai reiškia proceso pakeitimą arba pagalbinę priemonę, rašančią į failo deskriptorių. Valdymo sąsaja apima ketvirtą atvejį: valdiklį, kuris jau valdo tunelio gyvavimo ciklą ir gali atsakyti į klausimus per socket.

• Žmogus prie konsolės, jokio automatizavimo: interaktyvus raginimas.
• Paleidimas be priežiūros, paslaptį galima saugoti: prisijungimo duomenų failas su 0600 režimu.
• Paleidimas be priežiūros, paslapties saugoti negalima: proceso pakeitimas arba fd, į kurį rašo paslapčių agentas.
• Kitam procesui priklauso klientas: valdymo sąsaja.

Kai tinka du atsakymai, rinkitės tą, kuris laiko paslaptį už argv ir už shell istorijos ribų. Slaptažodį, perduotą kaip programos argumentą, gali perskaityti bet kuris vietinis naudotojas per procesų sąrašą, ir šį atskleidimą sunku atšaukti.

Ką iš tikrųjų daro kiekvienas įvesties kelias

--auth-user-pass vienas pats konsolėje prašo naudotojo vardo ir slaptažodžio. Gavęs failo vardą, klientas pirmą eilutę ima kaip naudotojo vardą, o antrą - kaip slaptažodį; niekas nepalaiko kabučių, komentarų ar rakto-reikšmės sintaksės. Tai yra visas formatas, todėl kas jį redaguoja tikėdamasis INI failo, jį sugadina. Įterptas <auth-user-pass> blokas laiko tas pačias dvi eilutes profilyje, o tai paverčia patį profilį paslaptimi ir priskiria jį tai pačiai tvarkymo klasei kaip privatus raktas.

Kiti du keliai yra srautas ir socket. OpenVPN reikia tik skaitomo failo deskriptoriaus, todėl jis priims proceso pakeitimą, vamzdžiu paremtą /dev/fd įrašą arba failo vardą, kuris iš tikrųjų yra FIFO. Valdymo sąsaja skiriasi savo prigimtimi: klientas klausia prižiūrinčio proceso reikšmių, o ne skaito jas pats. Šis skirtumas svarbus persijungiant: prisijungimo duomenų failas, FIFO, į kurį paslapčių pagalbinė priemonė gali vėl įrašyti, ir valdymo sąsaja gali vėl tiekti be žmogaus; proceso pakeitimas negali, nes deskriptorius sunaudojamas pirmo skaitymo metu.

Failas turi būti tiksliai dvi eilutės

Dvi gedimo rūšys apima daugumą sugadintų prisijungimo duomenų failų. Windows redaktorius palieka CRLF pabaigas, vežimėlio grąžinimas tampa slaptažodžio dalimi, ir serveris atmeta reikšmę, kuri ekrane atrodo teisinga. Tuščia antra eilutė - tuščia eilutė ten, kur turėtų būti slaptažodis - palieka klientą su tuščiu slaptažodžiu, kurį serveris atmeta, nors ekrane reikšmė atrodo teisinga. Papildomas naujos eilutės simbolis po slaptažodžio yra nekenksmingas. Rašykite failą iš shell, o ne iš redaktoriaus, ir patikrinkite baitus:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

Kelias svarbus tiek pat, kiek turinys. Santykinis kelias sprendžiamas proceso darbinio katalogo atžvilgiu, o paslaugai tai retai būna katalogas, kuriame testavote. Naudokite absoliutų kelią, padarykite failą klientą paleidžiančios paskyros nuosavybe ir laikykite 0600 režimą, kad grupė ir kiti negalėtų jo perskaityti. OpenVPN 2.6 vadove išvardytos priimtinos direktyvos formos; patikrinkite jį prieš išrasdami trečią.

Išbandykite failą prieš kaltindami serverį. Paleidus openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 išspausdinama, ar failas buvo atidarytas ir vėliau, ar prisijungimo duomenys buvo priimti, o tai pasako, kurį sluoksnį keisti toliau.

Srautai, stdin ir jų sukeliamos klaidos

Slaptažodžio nukreipimas į vamzdį yra pirmas dalykas, kurį bando dauguma, ir kelias su daugiausia netikėtumų. Proceso pakeitimas veikia todėl, kad klientui reikia tik skaitomo deskriptoriaus: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). /dev/stdin perdavimas veikia tik tada, kai stdin vis dar atidarytas ir skaitomas tuo metu, kai klientas klausia, o tai netiesa vamzdyne, kuris jau jį sunaudojo.

ERROR: could not read Auth username from stdin turi dvi skirtingas priežastis. Kai kuriuose 2.3.x klientuose pranešimas kilo iš stdin tvarkymo defekto, kurį ištaisė vėlesni 2.3 leidimai, todėl toks senas klientas pagerėja tik atnaujinus. Dabartiniame kliente ta pati formuluotė reiškia, kad klientas paprašė konsolės įvesties ir stdin nebuvo terminalas - būtent tokia situacija systemd įrenginyje, cron užduotyje ar konteineryje, paleistame be -t.

auth-nocache prideda trečią ciklą, kuris atrodo kaip sugedęs slaptažodis. Jis išmeta prisijungimo duomenis iš atminties po naudojimo, todėl tinklo pakeitimo sukeltam persijungimui nėra ko perleisti ir raginimas grįžta. Tai yra direktyva, veikianti taip, kaip suprojektuota. auth-nocache keičia tai, ką klientas laiko atmintyje, o ne tai, ką serveris ar tapatybės teikėjas mano apie paskyrą, todėl visas pataisymas yra vėl tiekti tą patį failą, per naują perskaitytą paleidžiant - o valdomam ryšiui tas tiekimas turėtų ateiti iš patvirtintos paslapčių saugyklos, o ne iš slaptažodžio scenarijuje.

Valdymo sąsaja, kai raginimas priklauso kitam procesui

Valdiklis, kuris jau prižiūri tunelį, gali atsakyti ir į jo klausimus. Paleiskite klientą su --management 127.0.0.1 7505, skaitykite būsenos eilutes ir stebėkite >PASSWORD:Need 'Auth' username/password. Valdiklis atsako username "Auth" alice ir po to password "Auth" ... atskiromis komandų eilutėmis. 'Auth' žetonas pakartoja užklausos identifikatorių ir turi sutapti, kitaip atsakymas ignoruojamas ir klientas laukia.

Kaina yra būsenos mašina, kurią dabar turite: jungčių tvarka, kliento paleidimai iš naujo ir vietinis socket, kurio kiti naudotojai hoste neturėtų pasiekti. Tai, ką perkate, yra vykdymo metu tiekti prisijungimo duomenys, be failo diske ir be raginimo, kuris gali pakibti. Jei niekas kitas jūsų stacke jau nekalba šiuo protokolu, šis kelias prideda komponentą, kurį reikia prižiūrėti.

Gedimai, kurie atrodo kaip prisijungimo duomenų problemos

TLS rankos paspaudimas, kuris niekada nebaigiamas, arba VERIFY ERROR: depth=0, error=certificate signature failure, yra pasitikėjimo problema ir įvyksta prieš perskaitant bet kokį naudotojo vardą. proto tcp klientas, nukreiptas į UDP klausytoją, sugenda toje pačioje vietoje: paketai niekada nepasiekia autentifikavimo etapo, todėl kiekvienas slaptažodis atrodo neteisingas dėl asociacijos. Laikykite sertifikatų tikrinimą įjungtą prieš siunčiant prisijungimo duomenis; pažįstamas raginimas nieko nesako apie tai, kas gauna slaptažodį. Patikrinkite sertifikatų grandinę, bendrą vardą ir transportą prieš liesdami prisijungimo duomenis.

Shell klaidos scenarijuje, kuris surenka profilį, yra kita klaidinga pėdsaka. Trūkstamas tarpas [ ! -f "$file" ] viduje sukuria command not found, scenarijus sustoja anksti, profilis niekada neatkuriamas, ir klientas paleidžiamas su ankstesniu. Ta klaida priklauso shell, o ne autentifikavimui, ir joks slaptažodžio perrašymas jos nepanaikins.

Ne kiekvienas šio srauto raginimas yra šie prisijungimo duomenys. Privataus rakto slaptafrazė, HTTP proxy prisijungimas ir paslaugos slaptažodis yra trys skirtingos paslaptys, prašomos skirtingose fazėse, o rakto slaptafrazę paprastai tvarko klientas arba agentas, o ne auth-user-pass. Jei raginimas pasirodo prieš TLS sesijai atsirandant, atsakote į neteisingą klausimą ir joks paskyros atstatymas nepadės. Pašalinus neteisingą raginimą, likusios patikros prasideda nuo ankstyviausio sluoksnio:

• Skaitykite pirmą protokolo klaidą, o ne paskutinę prisijungimo duomenų eilutę: TLS, tada autentifikavimas, tada push.
• Patvirtinkite, kad failas yra dvi eilutės, neturi vežimėlio grąžinimų ir nurodytas absoliučiu keliu.
• Patvirtinkite, kad profilis ir komandų eilutė nesipriešina dėl direktyvos.
• Atskirkite "prisijungimo duomenys priimti" nuo "srautas teka" - maršrutizavimas ir DNS yra vėlesnis sluoksnis.

Kai klientas pasiekia push fazę, nustokite žiūrėti į prisijungimo duomenis ir pradėkite skaityti maršrutus bei DNS serverius, kuriuos atsiuntė serveris. Tai kita problema, ir ji neturi nieko bendra su slaptažodžiu, kurį ką tik pataisėte.