OpenVPN auth-user-pass: fil, stdin eller ledetekst? Slik vel du

Tre ting avgjer kva legitimasjonskjelde du bør bruke: om ein person sit ved konsollen, om hemmelegheita kan liggje på disken, og om ein annan prosess må svare på ledeteksten. Vel du feil, rapporterer klienten eit stdin-problem medan passordet er heilt gyldig, og det sender dei fleste til tenaren utan grunn. Vel vegen først; feilmeldingane gir berre meining når du veit kva veg som laga dei.

Dei tre vilkåra som avgjer det

Konsolledeteksten er den einaste vegen som treng eit menneske, så han er den einaste som feilar stille i ei systemd-eining eller ein container. Viss ein person startar klienten og skriv passordet, er inga fil involvert og ingenting følsamt hamnar på disken. Viss klienten startar ved oppstart, blir same ledetekst ei henging, og tidsavbrotet viser seg vanlegvis som ein generell tilkoplingsfeil i staden for ein legitimasjonsfeil.

Ei legitimasjonsfil er det rette svaret når prosessen startar utan tilsyn og hemmelegheita kan overleve på disken under eit kontrollert sett med rettar. Når hemmelegheita ikkje skal skrivast i det heile - ein policy med berre kvelv, eit kortliva token - treng du ein straum som klienten kan opne, som i praksis tyder prosessubstitusjon eller ein hjelpar som skriv til ein fildeskriptor. Administrasjonsgrensesnittet dekkjer det fjerde tilfellet: ein kontrollør som allereie styrer livssyklusen til tunnelen og kan svare på spørsmål via ein socket.

• Menneske ved konsollen, inga automatisering: interaktiv ledetekst.
• Oppstart utan tilsyn, hemmelegheita kan lagrast: legitimasjonsfil med modus 0600.
• Oppstart utan tilsyn, hemmelegheita kan ikkje lagrast: prosessubstitusjon eller ein fd som ein hemmelegheitsagent skriv til.
• Ein annan prosess eig klienten: administrasjonsgrensesnitt.

Når to svar passar, vel det som held hemmelegheita utanfor argv og utanfor shell-historia. Eit passord som blir sendt som programargument kan lesast av kvar lokal brukar via prosesslista, og den eksponeringa er vanskeleg å angre.

Kva kvar inngangsveg faktisk gjer

--auth-user-pass åleine ber om eit brukarnamn og eit passord ved konsollen. Gitt eit filnamn tek klienten linje éin som brukarnamn og linje to som passord; ingenting støttar hermeteikn, kommentarar eller nøkkel-verdi-syntaks. Det er heile formatet, så den som redigerer det i vente om ei INI-fil, øydelegg det. Ein innebygd <auth-user-pass>-blokk inneheld dei same to linjene i profilen, noko som gjer profilen sjølv til ei hemmelegheit og plasserer han i same handteringsklasse som ein privatnøkkel.

Dei to andre vegane er ein straum og ein socket. OpenVPN treng berre ein lesbar fildeskriptor, så han godtek ein prosessubstitusjon, ei røyrdreven /dev/fd-oppføring eller eit filnamn som faktisk er ein FIFO. Administrasjonsgrensesnittet er annleis av natur: klienten spør ein overvakande prosess om verdiane i staden for å lese dei sjølv. Den skilnaden betyr noko ved gjenoppkopling: ei legitimasjonsfil, ein FIFO som ein hemmelegheitshjelpar kan skrive til igjen, og administrasjonsgrensesnittet kan levere på nytt utan eit menneske; prosessubstitusjon kan ikkje, fordi deskriptoren blir brukt opp ved første lesing.

Fila må vere nøyaktig to linjer

To feilmodusar dekkjer dei fleste øydelagde legitimasjonsfilene. Ein Windows-editor etterlèt CRLF-linjeslutt, carriage return blir ein del av passordet, og tenaren avviser ein verdi som ser rett ut på skjermen. Ei tom andre linje - ei tom linje der passordet skal vere - etterlèt klienten med eit tomt passord, som tenaren avviser sjølv om verdien på skjermen ser rett ut. Ei ekstra ny linje etter passordet er harmlaus. Skriv fila frå shellen, ikkje frå ein editor, og kontroller byta:

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

Vegen er like viktig som innhaldet. Ein relativ veg blir løyst mot arbeidskatalogen til prosessen, som for ei teneste sjeldan er katalogen der du testa. Bruk ein absolutt veg, la fila vere eigd av kontoen som køyrer klienten, og hald modus 0600 slik at gruppe og andre ikkje kan lese henne. OpenVPN 2.6-handboka listar dei godkjende formene for direktivet; sjekk henne før du finn opp ei tredje.

Test fila før du klandrar tenaren. Å køyre openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 skriv ut om fila vart opna og seinare om legitimasjonen vart godteken, noko som fortel deg kva lag du skal endre neste gong.

Straum, stdin og feila dei produserer

Å pipe passordet inn er det første dei fleste prøver, og vegen med flest overraskingar. Prosessubstitusjon fungerer fordi klienten berre treng ein lesbar deskriptor: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Å sende /dev/stdin fungerer berre når stdin framleis er open og lesbar i det augneblinken klienten spør, noko som ikkje stemmer i ein pipeline som allereie har brukt han opp.

ERROR: could not read Auth username from stdin har to ulike årsaker. På nokre 2.3.x-klientar kom meldinga frå ein stdin-handteringsfeil som seinare 2.3-utgjevingar retta, så ein så gamal klient blir berre betre av å oppgradere. På ein noverande klient tyder same ordlyden at klienten bad om konsollinndata og stdin ikkje var ein terminal - nøyaktig situasjonen i ei systemd-eining, ein cron-jobb eller ein container starta utan -t.

auth-nocache legg til ei tredje løkke som ser ut som eit øydelagt passord. Det kastar legitimasjonen ut av minnet etter bruk, så ei gjenoppkopling utløyst av ei nettverksendring har ingenting å spele av på nytt, og ledeteksten kjem tilbake. Det er direktivet som verkar som designa. auth-nocache endrar kva klienten held i minnet, ikkje kva tenaren eller identitetsleverandøren meiner om kontoen, så heile rettinga er å levere den same fila på nytt, lesen på nytt ved omstart - og for ei administrert tilkopling bør den leveransen kome frå det godkjende hemmelegheitslageret, ikkje eit passord i eit skript.

Administrasjonsgrensesnittet når ein annan prosess eig ledeteksten

Ein kontrollør som allereie overvakar tunnelen, kan også svare på spørsmåla hans. Start klienten med --management 127.0.0.1 7505, les statuslinjene, og følg med på >PASSWORD:Need 'Auth' username/password. Kontrolløren svarar med username "Auth" alice etterfølgd av password "Auth" ... på separate kommandolinjer. 'Auth'-tokenet gientar identifikatoren frå førespurnaden og må stemme, elles blir svaret ignorert og klienten ventar.

Prisen er ein tilstandsmaskin du no eig: rekkjefølgja på tilkoplingar, omstart av klienten og ein lokal socket som andre brukarar på verten ikkje skal nå. Det du kjøper, er ein legitimasjon levert ved køyretid, utan fil på disken og utan ein ledetekst som kan henge. Viss ingenting anna i stakken din allereie snakkar protokollen, legg denne vegen til ein komponent som må vedlikehaldast.

Feil som ser ut som legitimasjonsproblem

Eit TLS-handtrykk som aldri blir fullført, eller VERIFY ERROR: depth=0, error=certificate signature failure, er eit tillitsproblem og skjer før noko brukarnamn blir lese. Ein proto tcp-klient retta mot ein UDP-lyttar feilar på same stad: pakkane når aldri autentiseringsfasen, så kvart passord ser feil ut ved assosiasjon. Hald sertifikatverifiseringa på før legitimasjonen blir send, ein kjend ledetekst seier ingenting om kven som får passordet. Sjekk sertifikatkjeda, common name og transporten før du rører legitimasjonen.

Shell-feil i skriptet som set saman profilen er det andre falske sporet. Eit manglande mellomrom inne i [ ! -f "$file" ] gir command not found, skriptet stoppar tidleg, profilen blir aldri bygd på nytt, og klienten startar med den førre. Den feilen høyrer til shellen, ikkje autentiseringa, og uansett kor mange gonger du skriv passordet på nytt, forsvinn han ikkje.

Ikkje kvar ledetekst i denne flyten er denne legitimasjonen. Ein passfrase for ein privatnøkkel, ei HTTP-proxy-innlogging og passordet til tenesta er tre ulike hemmelegheiter som blir spurde om i ulike fasar, og ein nøkkelpassfrase blir vanlegvis handtert av klienten eller ein agent i staden for auth-user-pass. Viss ledeteksten dukkar opp før TLS-økta er oppe, svarar du på feil spørsmål og inga kontotilbakestilling hjelper. Når feil ledetekst er utelukka, byrjar dei gjenverande kontrollane på det tidlegaste laget:

• Les den første protokollfeilen, ikkje den siste legitimasjonslinja: TLS, så autentisering, så push.
• Stadfest at fila er to linjer, ikkje har carriage returns og blir referert med ein absolutt veg.
• Stadfest at profilen og kommandolinja ikkje er usamde om direktivet.
• Skil "legitimasjon godteken" frå "trafikk flyt" - ruting og DNS er eit seinare lag.

Når klienten når push-fasen, slutt å sjå på legitimasjonen og byrja å lese rutene og DNS-tenarane tenaren sende. Det er det neste problemet, og det har ingenting å gjere med passordet du nettopp retta.