OpenVPN auth-user-pass: datoteka, stdin ali poziv? Kako izbrati

Kateri vir poverilnic uporabiti, odločajo tri stvari: ali pri konzoli sedi človek, ali lahko skrivnost živi na disku in ali mora na poziv odgovoriti drug proces. Če izberete napačno, odjemalec sporoči težavo s stdin, čeprav je geslo povsem veljavno, in to večino ljudi brez razloga pošlje na strežnik. Najprej izberite pot; sporočila o napakah imajo smisel šele, ko veste, katera pot jih je ustvarila.

Trije pogoji, ki to odločajo

Poziv v konzoli je edina pot, ki potrebuje človeka, zato je edina, ki v enoti systemd ali v vsebniku tiho odpove. Če človek zažene odjemalca in vpiše geslo, ni vključena nobena datoteka in nič občutljivega ne pride na disk. Če se odjemalec zažene ob zagonu, se isti poziv spremeni v zataknitev in časovna omejitev se običajno pokaže kot splošna napaka povezave, ne kot napaka poverilnic.

Datoteka s poverilnicami je pravi odgovor, ko se proces zažene brez nadzora in lahko skrivnost preživi na disku pod nadzorovanim naborom dovoljenj. Ko se skrivnost ne sme zapisati sploh - politika samo trezorja, kratkotrajni žeton - potrebujete tok, ki ga odjemalec lahko odpre, kar v praksi pomeni zamenjavo procesa ali pomočnika, ki piše v opisnik datoteke. Vmesnik za upravljanje pokriva četrti primer: krmilnik, ki že upravlja življenjski cikel tunela in lahko odgovarja na vprašanja prek vtičnice.

• Človek pri konzoli, brez avtomatizacije: interaktivni poziv.
• Zagon brez nadzora, skrivnost se sme shraniti: datoteka s poverilnicami z načinom 0600.
• Zagon brez nadzora, skrivnosti ni dovoljeno shraniti: zamenjava procesa ali fd, v katerega piše agent skrivnosti.
• Odjemalca ima v lasti drug proces: vmesnik za upravljanje.

Ko se ujemata dva odgovora, izberite tistega, ki skrivnost drži zunaj argv in zunaj zgodovine lupine. Geslo, posredovano kot argument programa, lahko prebere vsak lokalni uporabnik prek seznama procesov, in to izpostavljenost je težko preklicati.

Kaj vsaka vhodna pot v resnici počne

--auth-user-pass sam po sebi v konzoli zahteva uporabniško ime in geslo. Če dobi ime datoteke, odjemalec vzame prvo vrstico kot uporabniško ime in drugo kot geslo; nič ne podpira narekovajev, komentarjev ali sintakse ključ-vrednost. To je celoten format, zato vsak, ki ga ureja v pričakovanju datoteke INI, ga pokvari. Vgrajeni blok <auth-user-pass> vsebuje isti dve vrstici v profilu, kar naredi sam profil skrivnost in ga postavi v isti razred obravnave kot zasebni ključ.

Drugi dve poti sta tok in vtičnica. OpenVPN potrebuje le berljiv opisnik datoteke, zato bo sprejela zamenjavo procesa, vnos /dev/fd s cevjo ali ime datoteke, ki je v resnici FIFO. Vmesnik za upravljanje je drugačen po naravi: odjemalec sprašuje nadzorni proces za vrednosti, namesto da bi jih bral sam. Ta razlika je pomembna pri ponovnem povezovanju: datoteka s poverilnicami, FIFO, v katerega lahko pomočnik za skrivnosti znova piše, in vmesnik za upravljanje lahko znova dobavijo brez človeka; zamenjava procesa ne more, ker se opisnik porabi pri prvem branju.

Datoteka mora imeti natanko dve vrstici

Dva načina odpovedi pokrivata večino pokvarjenih datotek s poverilnicami. Urejevalnik v sistemu Windows pušča konce CRLF, povratek vozička postane del gesla in strežnik zavrne vrednost, ki je na zaslonu videti pravilna. Prazna druga vrstica - prazna vrstica tam, kjer bi moralo biti geslo - pusti odjemalca s praznim geslom, ki ga strežnik zavrne, čeprav je vrednost na zaslonu videti pravilna. Dodatna nova vrstica za geslom je neškodljiva. Datoteko pišite iz lupine, ne iz urejevalnika, in preverite bajte:

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

Pot je enako pomembna kot vsebina. Relativna pot se razreši glede na delovni imenik procesa, ki pri storitvi redko je imenik, kjer ste testirali. Uporabite absolutno pot, naredite datoteko lastništvo računa, ki poganja odjemalca, in ohranite način 0600, da je skupina in drugi ne morejo brati. Priročnik OpenVPN 2.6 navaja sprejete oblike direktive; preglejte ga, preden si izmislite tretjo.

Preizkusite datoteko, preden obtožite strežnik. Zagon openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 izpiše, ali je bila datoteka odprta in pozneje, ali so bile poverilnice sprejete, kar vam pove, kateri sloj spremeniti naslednjič.

Tokovi, stdin in napake, ki jih ustvarjajo

Pošiljanje gesla skozi cev je prva stvar, ki jo večina poskusi, in pot z največ presenečenji. Zamenjava procesa deluje, ker odjemalec potrebuje le berljiv opisnik: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Posredovanje /dev/stdin deluje le, ko je stdin v trenutku, ko odjemalec vpraša, še odprt in berljiv, kar v cevovodu, ki ga je že porabil, ne velja.

ERROR: could not read Auth username from stdin ima dva različna vzroka. Pri nekaterih odjemalcih 2.3.x je sporočilo izhajalo iz napake pri obdelavi stdin, ki so jo poznejše izdaje 2.3 popravile, zato se tako star odjemalec izboljša le z nadgradnjo. Pri sodobnem odjemalcu ista formulacija pomeni, da je odjemalec zahteval vnos iz konzole in stdin ni bil terminal - natanko situacija v enoti systemd, opravilu cron ali vsebniku, zagnanem brez -t.

auth-nocache doda tretjo zanko, ki je videti kot pokvarjeno geslo. Po uporabi vrže poverilnice iz spomina, zato ponovna povezava, ki jo sproži sprememba omrežja, nima česa predvajati in poziv se vrne. To je direktiva, ki deluje, kot je zasnovana. auth-nocache spremeni, kaj odjemalec hrani v spominu, ne pa, kaj strežnik ali ponudnik identitete misli o računu, zato je celotno popravilo znova dobaviti isto datoteko, znova prebrano ob ponovnem zagonu - in pri upravljani povezavi mora ta dobava priti iz odobrenega skladišča skrivnosti, ne iz gesla v skriptu.

Vmesnik za upravljanje, ko ima poziv v lasti drug proces

Krmilnik, ki že nadzoruje tunel, lahko odgovori tudi na njegova vprašanja. Zaženite odjemalca z --management 127.0.0.1 7505, berite vrstice stanja in spremljajte >PASSWORD:Need 'Auth' username/password. Krmilnik odgovori z username "Auth" alice, ki mu sledi password "Auth" ... v ločenih ukaznih vrsticah. Žeton 'Auth' ponovi identifikator iz zahteve in se mora ujemati, sicer se odgovor prezre in odjemalec čaka.

Cena je končni avtomat, ki ga zdaj imate: vrstni red povezav, ponovni zagoni odjemalca in lokalna vtičnica, do katere drugi uporabniki na gostitelju ne smejo priti. Kar kupite, so poverilnice, dobavljene med izvajanjem, brez datoteke na disku in brez poziva, ki se lahko zatakne. Če nič drugega v vašem skladu že ne govori tega protokola, ta pot doda komponento za vzdrževanje.

Odpovedi, ki so videti kot težave s poverilnicami

TLS rokovanje, ki se nikoli ne konča, ali VERIFY ERROR: depth=0, error=certificate signature failure, je težava zaupanja in se zgodi, preden je prebrano katero koli uporabniško ime. Odjemalec proto tcp, usmerjen na poslušalec UDP, odpove na istem mestu: paketi nikoli ne dosežejo faze preverjanja pristnosti, zato je vsako geslo videti napačno zaradi povezave. Ohranite preverjanje potrdil vključeno, preden se poverilnice pošljejo; znan poziv ne pove ničesar o tem, kdo prejme geslo. Preverite verigo potrdil, skupno ime in transport, preden se dotaknete poverilnic.

Napake lupine v skriptu, ki sestavi profil, so druga lažna sled. Manjkajoči presledek v [ ! -f "$file" ] ustvari command not found, skript se ustavi zgodaj, profil se nikoli ne obnovi in odjemalec se zažene s prejšnjim. Ta napaka pripada lupini, ne preverjanju pristnosti, in nobeno prepisovanje gesla je ne odpravi.

Ni vsak poziv v tem toku ta poverilnica. Geslo zasebnega ključa, prijava prek proxyja HTTP in geslo storitve so tri različne skrivnosti, zahtevane v različnih fazah, in geslo ključa običajno obravnava odjemalec ali agent, ne auth-user-pass. Če se poziv pojavi, preden je seja TLS vzpostavljena, odgovarjate na napačno vprašanje in nobeno ponastavljanje računa ne pomaga. Ko je napačen poziv izključen, se preostala preverjanja začnejo na najzgodnejšem sloju:

• Preberite prvo napako protokola, ne zadnje vrstice poverilnic: TLS, nato preverjanje pristnosti, nato push.
• Potrdite, da ima datoteka dve vrstici, ne vsebuje povratkov vozička in je navedena z absolutno potjo.
• Potrdite, da se profil in ukazna vrstica ne razhajata glede direktive.
• Ločite "poverilnice sprejete" od "promet teče" - usmerjanje in DNS sta poznejši sloj.

Ko odjemalec doseže fazo push, nehajte gledati poverilnice in začnite brati poti in strežnike DNS, ki jih je poslal strežnik. To je naslednja težava in nima nič skupnega z geslom, ki ste ga pravkar popravili.