OpenVPN auth-user-pass: datoteka, stdin ili upit? Kako odabrati

Tri stvari odlučuju koju vjerodajnicu koristiti: sjedi li osoba za konzolom, smije li tajna živjeti na disku i mora li drugi proces odgovoriti na upit. Pogriješite li, klijent prijavi problem sa stdinom dok je lozinka posve valjana, što većinu ljudi bez razloga šalje na poslužitelj. Prvo odaberite put; poruke o pogrešci imaju smisla tek kad znate koji ih je put proizveo.

Tri uvjeta koja to odlučuju

Upit u konzoli jedini je put koji treba čovjeka, pa je jedini koji tiho zakaže u systemd unit-u ili kontejneru. Ako osoba pokrene klijent i upiše lozinku, datoteka nije uključena i ništa osjetljivo ne završi na disku. Ako se klijent pokrene pri podizanju sustava, isti se upit pretvori u zastoj, a istek vremena obično se pojavi kao općenita pogreška veze, a ne kao pogreška vjerodajnica.

Datoteka s vjerodajnicama pravi je odgovor kad se proces pokreće bez nadzora i tajna smije preživjeti na disku pod kontroliranim skupom dopuštenja. Kad se tajna ne smije uopće zapisati - politika samo trezora, kratkotrajni token - potreban vam je tok koji klijent može otvoriti, što u praksi znači zamjenu procesa ili pomoćnika koji piše u datotečni deskriptor. Upravljačko sučelje pokriva četvrti slučaj: kontroler koji već upravlja životnim ciklusom tunela i može odgovarati na pitanja preko utičnice.

• Čovjek za konzolom, bez automatizacije: interaktivni upit.
• Pokretanje bez nadzora, tajna se smije spremiti: datoteka s vjerodajnicama s modom 0600.
• Pokretanje bez nadzora, tajna se ne smije spremiti: zamjena procesa ili fd u koji piše agent za tajne.
• Drugi proces posjeduje klijent: upravljačko sučelje.

Kad odgovaraju dva odgovora, odaberite onaj koji drži tajnu izvan argva i izvan povijesti ljuske. Lozinku predanu kao argument programa može pročitati svaki lokalni korisnik kroz popis procesa, a to je izlaganje teško poništiti.

Što svaki ulazni put zapravo radi

--auth-user-pass sam po sebi traži korisničko ime i lozinku u konzoli. Kad dobije naziv datoteke, klijent uzima prvi redak kao korisničko ime, a drugi kao lozinku; ništa ne podržava navodnike, komentare ni sintaksu ključ-vrijednost. To je cijeli format, pa ga svatko tko ga uređuje očekujući INI datoteku razbija. Ugrađeni blok <auth-user-pass> drži ista dva retka unutar profila, što sam profil čini tajnom i stavlja ga u istu klasu rukovanja kao privatni ključ.

Druga su dva puta tok i utičnica. OpenVPN treba samo čitljiv datotečni deskriptor, pa će prihvatiti zamjenu procesa, unos /dev/fd podržan cijevi ili naziv datoteke koji je zapravo FIFO. Upravljačko sučelje različito je po naravi: klijent pita nadzorni proces za vrijednosti umjesto da ih čita sam. Ta je razlika važna pri ponovnom spajanju: datoteka s vjerodajnicama, FIFO u koji pomoćnik za tajne može ponovno pisati i upravljačko sučelje mogu ponovno dostaviti bez osobe; zamjena procesa ne može, jer se deskriptor troši pri prvom čitanju.

Datoteka mora imati točno dva retka

Dva načina kvara pokrivaju većinu pokvarenih datoteka s vjerodajnicama. Windows uređivač ostavlja CRLF završetke, povratak reda postaje dio lozinke i poslužitelj odbija vrijednost koja na zaslonu izgleda ispravno. Prazan drugi redak - prazan redak ondje gdje pripada lozinka - ostavlja klijent s praznom lozinkom, koju poslužitelj odbija iako vrijednost na zaslonu izgleda ispravno. Dodatni novi redak nakon lozinke nije štetan. Pišite datoteku iz ljuske, ne iz uređivača, i provjerite bajtove:

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

Put je jednako važan kao sadržaj. Relativni put rješava se prema radnom direktoriju procesa, koji za uslugu rijetko je direktorij u kojem ste testirali. Upotrijebite apsolutni put, neka datoteka pripada računu koji pokreće klijent i držite mod 0600 da je grupa i ostali ne mogu čitati. Priručnik za OpenVPN 2.6 navodi prihvaćene oblike direktive; provjerite ga prije nego izmislite treći.

Testirajte datoteku prije nego okrivite poslužitelj. Pokretanje openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 ispisuje je li datoteka otvorena i, kasnije, jesu li vjerodajnice prihvaćene, što vam kaže koji sloj sljedeće mijenjati.

Tokovi, stdin i pogreške koje proizvode

Slanje lozinke kroz cijev prvo je što većina ljudi pokuša i put s najviše iznenađenja. Zamjena procesa radi jer klijentu treba samo čitljiv deskriptor: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Predavanje /dev/stdin radi samo dok je stdin još otvoren i čitljiv u trenutku kad klijent pita, što u cjevovodu koji ga je već potrošio nije točno.

ERROR: could not read Auth username from stdin ima dva različita uzroka. Na nekim klijentima 2.3.x poruka je dolazila od kvara u rukovanju stdinom koji su kasnija 2.3 izdanja ispravila, pa klijent stare dobi napreduje samo nadogradnjom. Na suvremenom klijentu ista formulacija znači da je klijent zatražio konzolni unos i da stdin nije bio terminal - upravo situacija u systemd unit-u, zadatku cron ili kontejneru pokrenutom bez -t.

auth-nocache dodaje treću petlju koja izgleda kao pokvarena lozinka. Odbacuje vjerodajnice iz memorije nakon upotrebe, pa ponovno spajanje potaknuto promjenom mreže nema što reproducirati i upit se vraća. To je direktiva koja radi kako je projektirana. auth-nocache mijenja što klijent drži u memoriji, a ne što poslužitelj ili davatelj identiteta misli o računu, pa je cijela ispravka ponovno dostavljanje iste datoteke, ponovno pročitane pri restartu - a za upravljanu vezu ta dostava treba doći iz odobrenog spremišta tajni, ne iz lozinke u skripti.

Upravljačko sučelje kad drugi proces posjeduje upit

Kontroler koji već nadzire tunel može odgovarati i na njegova pitanja. Pokrenite klijent s --management 127.0.0.1 7505, čitajte retke stanja i pazite na >PASSWORD:Need 'Auth' username/password. Kontroler odgovara s username "Auth" alice nakon čega slijedi password "Auth" ... na zasebnim naredbenim recima. Token 'Auth' ponavlja identifikator iz zahtjeva i mora se podudarati, inače se odgovor zanemaruje i klijent čeka.

Cijena je stroj stanja koji sada posjedujete: redoslijed veza, ponovna pokretanja klijenta i lokalna utičnica do koje drugi korisnici na računalu ne smiju doći. Ono što kupujete su vjerodajnice dostavljene u vrijeme izvođenja, bez datoteke na disku i bez upita koji se može objesiti. Ako ništa drugo u vašem skupu već ne govori protokol, ovaj put dodaje komponentu za održavanje.

Kvarovi koji izgledaju kao problemi s vjerodajnicama

TLS rukovanje koje nikad ne završi, ili VERIFY ERROR: depth=0, error=certificate signature failure, problem je povjerenja i događa se prije nego što se pročita bilo koje korisničko ime. Klijent proto tcp usmjeren na UDP slušatelj zakaže na istom mjestu: paketi nikad ne dođu do faze provjere autentičnosti, pa svaka lozinka izgleda pogrešno po asocijaciji. Držite provjeru certifikata uključenom prije slanja vjerodajnica; poznati upit ne govori ništa o tome kome lozinka stiže. Provjerite lanac certifikata, uobičajeno ime i prijenos prije nego dotaknete vjerodajnice.

Pogreške ljuske u skripti koja sastavlja profil drugi su lažni trag. Nedostajući razmak unutar [ ! -f "$file" ] proizvodi command not found, skripta se zaustavi rano, profil se nikad ne ponovno izgradi i klijent se pokrene s prethodnim. Ta pogreška pripada ljusci, ne provjeri autentičnosti, i nikakvo ponovno upisivanje lozinke je neće ukloniti.

Nije svaki upit u ovom toku ova vjerodajnica. Lozinka privatnog ključa, prijava kroz HTTP proxy i lozinka usluge tri su različite tajne koje se traže u različitim fazama, a lozinku ključa obično obrađuje klijent ili agent, a ne auth-user-pass. Ako se upit pojavi prije nego što je TLS sesija uspostavljena, odgovarate na pogrešno pitanje i nikakvo poništavanje računa neće pomoći. Kad je pogrešan upit isključen, preostale provjere počinju od najranijeg sloja:

• Čitajte prvu pogrešku protokola, ne zadnji redak s vjerodajnicama: TLS, zatim provjera autentičnosti, zatim push.
• Potvrdite da datoteka ima dva retka, nema povrataka reda i da je navedena apsolutnim putem.
• Potvrdite da se profil i naredbeni redak ne razilaze o direktivi.
• Odvojite "vjerodajnice prihvaćene" od "promet teče" - usmjeravanje i DNS su kasniji sloj.

Kad klijent dođe do faze push, prestanite gledati vjerodajnice i počnite čitati rute i DNS poslužitelje koje je poslužitelj poslao. To je sljedeći problem i nema nikakve veze s lozinkom koju ste upravo ispravili.