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

Tre ting avgjør hvilken legitimasjonskilde du bør bruke: om en person sitter ved konsollen, om hemmeligheten kan ligge på disken, og om en annen prosess må svare på ledeteksten. Velger du feil, rapporterer klienten et stdin-problem mens passordet er helt gyldig, og det sender de fleste til serveren uten grunn. Velg veien først; feilmeldingene gir bare mening når du vet hvilken vei som lagde dem.

De tre betingelsene som avgjør det

Konsolledeteksten er den eneste veien som trenger et menneske, så den er den eneste som feiler stille i en systemd-enhet eller en container. Hvis en person starter klienten og skriver passordet, er ingen fil involvert og ingenting følsomt havner på disken. Hvis klienten starter ved oppstart, blir samme ledetekst en henging, og tidsavbruddet vises vanligvis som en generell tilkoblingsfeil i stedet for en legitimasjonsfeil.

En legitimasjonsfil er det riktige svaret når prosessen starter uten tilsyn og hemmeligheten kan overleve på disken under et kontrollert sett med rettigheter. Når hemmeligheten ikke skal skrives i det hele tatt - en policy med bare hvelv, et kortlivet token - trenger du en strøm som klienten kan åpne, som i praksis betyr prosessubstitusjon eller en hjelper som skriver til en fildeskriptor. Administrasjonsgrensesnittet dekker det fjerde tilfellet: en kontroller som allerede styrer tunnelens livssyklus og kan svare på spørsmål via en socket.

• Menneske ved konsollen, ingen automatisering: interaktiv ledetekst.
• Oppstart uten tilsyn, hemmeligheten kan lagres: legitimasjonsfil med modus 0600.
• Oppstart uten tilsyn, hemmeligheten kan ikke lagres: prosessubstitusjon eller en fd som en hemmelighetsagent skriver til.
• En annen prosess eier klienten: administrasjonsgrensesnitt.

Når to svar passer, velg det som holder hemmeligheten utenfor argv og utenfor shell-historikken. Et passord som sendes som programargument kan leses av enhver lokal bruker via prosesslisten, og den eksponeringen er vanskelig å angre.

Hva hver inngangsvei faktisk gjør

--auth-user-pass alene ber om et brukernavn og et passord ved konsollen. Gitt et filnavn tar klienten linje én som brukernavn og linje to som passord; ingenting støtter anførselstegn, kommentarer eller nøkkel-verdi-syntaks. Det er hele formatet, så den som redigerer det i forventning om en INI-fil, ødelegger det. En innebygd <auth-user-pass>-blokk inneholder de samme to linjene i profilen, noe som gjør profilen selv til en hemmelighet og plasserer den i samme håndteringsklasse som en privatnøkkel.

De to andre veiene er en strøm og en socket. OpenVPN trenger bare en lesbar fildeskriptor, så den godtar en prosessubstitusjon, en rørbasert /dev/fd-oppføring eller et filnavn som faktisk er en FIFO. Administrasjonsgrensesnittet er annerledes av natur: klienten spør en overvåkende prosess om verdiene i stedet for å lese dem selv. Den forskjellen betyr noe ved gjenoppkobling: en legitimasjonsfil, en FIFO som en hemmelighetshjelper kan skrive til igjen, og administrasjonsgrensesnittet kan levere på nytt uten et menneske; prosessubstitusjon kan ikke, fordi deskriptoren forbrukes ved første lesing.

Filen må være nøyaktig to linjer

To feilmoduser dekker de fleste ødelagte legitimasjonsfiler. En Windows-editor etterlater CRLF-linjeslutt, carriage return blir en del av passordet, og serveren avviser en verdi som ser riktig ut på skjermen. En tom andre linje - en tom linje der passordet skal være - etterlater klienten med et tomt passord, som serveren avviser selv om verdien på skjermen ser riktig ut. En ekstra ny linje etter passordet er harmløs. Skriv filen fra shellen, ikke fra en editor, og kontroller bytene:

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

Veien er like viktig som innholdet. En relativ vei løses mot prosessens arbeidskatalog, som for en tjeneste sjelden er katalogen der du testet. Bruk en absolutt vei, la filen være eid av kontoen som kjører klienten, og behold modus 0600 slik at gruppe og andre ikke kan lese den. OpenVPN 2.6-håndboken lister de godkjente formene for direktivet; sjekk den før du finner opp en tredje.

Test filen før du klandrer serveren. Å kjøre openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 skriver ut om filen ble åpnet og senere om legitimasjonen ble godtatt, noe som forteller deg hvilket lag du skal endre neste gang.

Strømmer, stdin og feilene de produserer

Å pipe passordet inn er det første de fleste prøver, og veien med flest overraskelser. Prosessubstitusjon fungerer fordi klienten bare trenger en lesbar deskriptor: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). Å sende /dev/stdin fungerer bare når stdin fortsatt er åpen og lesbar i det øyeblikket klienten spør, noe som ikke stemmer i en pipeline som allerede har forbrukt den.

ERROR: could not read Auth username from stdin har to forskjellige årsaker. På enkelte 2.3.x-klienter kom meldingen fra en stdin-håndteringsfeil som senere 2.3-utgivelser rettet, så en så gammel klient blir bare bedre av å oppgradere. På en nåværende klient betyr samme ordlyd at klienten ba om konsollinndata og stdin ikke var en terminal - nøyaktig situasjonen i en systemd-enhet, en cron-jobb eller en container startet uten -t.

auth-nocache legger til en tredje løkke som ser ut som et ødelagt passord. Det kaster legitimasjonen ut av minnet etter bruk, så en gjenoppkobling utløst av en nettverksendring ikke har noe å spille av på nytt, og ledeteksten kommer tilbake. Det er direktivet som virker som designet. auth-nocache endrer hva klienten beholder i minnet, ikke hva serveren eller identitetsleverandøren mener om kontoen, så hele rettelsen er å levere den samme filen på nytt, lest på nytt ved omstart - og for en administrert tilkobling bør den leveransen komme fra det godkjente hemmelighetslageret, ikke et passord i et skript.

Administrasjonsgrensesnittet når en annen prosess eier ledeteksten

En kontroller som allerede overvåker tunnelen, kan også svare på spørsmålene dens. Start klienten med --management 127.0.0.1 7505, les statuslinjene, og følg med på >PASSWORD:Need 'Auth' username/password. Kontrolleren svarer med username "Auth" alice etterfulgt av password "Auth" ... på separate kommandolinjer. 'Auth'-tokenet gjentar identifikatoren fra forespørselen og må stemme, ellers ignoreres svaret og klienten venter.

Prisen er en tilstandsmaskin du nå eier: rekkefølgen på tilkoblinger, omstarter av klienten og en lokal socket som andre brukere på verten ikke skal nå. Det du kjøper, er en legitimasjon levert ved kjøretid, uten fil på disken og uten en ledetekst som kan henge. Hvis ingenting annet i stakken din allerede snakker protokollen, legger denne veien til en komponent som må vedlikeholdes.

Feil som ser ut som legitimasjonsproblemer

Et TLS-håndtrykk som aldri fullføres, eller VERIFY ERROR: depth=0, error=certificate signature failure, er et tillitsproblem og skjer før noe brukernavn leses. En proto tcp-klient rettet mot en UDP-lytter feiler på samme sted: pakkene når aldri autentiseringsfasen, så hvert passord ser feil ut ved assosiasjon. Hold sertifikatverifiseringen på før legitimasjonen sendes; en kjent ledetekst sier ingenting om hvem som mottar passordet. Sjekk sertifikatkjeden, common name og transporten før du rører legitimasjonen.

Shell-feil i skriptet som setter sammen profilen er det andre falske sporet. En manglende mellomrom inne i [ ! -f "$file" ] gir command not found, skriptet stopper tidlig, profilen bygges aldri på nytt, og klienten starter med den forrige. Den feilen tilhører shellen, ikke autentiseringen, og uansett hvor mange ganger du skriver passordet på nytt, forsvinner den ikke.

Ikke hver ledetekst i denne flyten er denne legitimasjonen. En passfrase for en privatnøkkel, en HTTP-proxy-innlogging og tjenestens passord er tre forskjellige hemmeligheter som spørres om i forskjellige faser, og en nøkkelpassfrase håndteres vanligvis av klienten eller en agent i stedet for auth-user-pass. Hvis ledeteksten dukker opp før TLS-økten er oppe, svarer du på feil spørsmål og ingen kontotilbakestilling hjelper. Når feil ledetekst er utelukket, begynner de gjenværende kontrollene på det tidligste laget:

• Les den første protokollfeilen, ikke den siste legitimasjonslinjen: TLS, så autentisering, så push.
• Bekreft at filen er to linjer, ikke har carriage returns og refereres med en absolutt vei.
• Bekreft at profilen og kommandolinjen ikke er uenige om direktivet.
• Skill "legitimasjon godtatt" fra "trafikk flyter" - ruting og DNS er et senere lag.

Når klienten når push-fasen, slutt å se på legitimasjonen og begynn å lese rutene og DNS-serverne serveren sendte. Det er det neste problemet, og det har ingenting å gjøre med passordet du nettopp rettet.