OpenVPN auth-user-pass: fil, stdin eller prompt? Sådan vælger du

Tre ting afgør, hvilken legitimationskilde du bør bruge: om der sidder en person ved konsollen, om hemmeligheden må ligge på disken, og om en anden proces skal svare på prompten. Vælger du forkert, rapporterer klienten et stdin-problem, mens adgangskoden er helt gyldig, og det sender de fleste til serveren uden grund. Vælg stien først; fejlmeddelelserne giver kun mening, når du ved, hvilken sti der skabte dem.

De tre betingelser, der afgør det

Konsolprompten er den eneste sti, der kræver et menneske, så den er den eneste, der fejler stille i en systemd unit eller en container. Hvis en person starter klienten og skriver adgangskoden, er der ingen fil involveret, og intet følsomt lander på disken. Hvis klienten starter ved opstart, bliver samme prompt til et hang, og timeouten vises normalt som en generisk forbindelsesfejl snarere end en legitimationsfejl.

En legitimationsfil er det rigtige svar, når processen starter uden opsyn, og hemmeligheden må overleve på disken under et kontrolleret sæt rettigheder. Når hemmeligheden slet ikke må skrives - en politik med kun et vault, et kortlivet token - har du brug for en strøm, som klienten kan åbne, hvilket i praksis betyder proceserstatning eller en hjælper, der skriver til en fildeskriptor. Administrationsgrænsefladen dækker det fjerde tilfælde: en controller, der allerede styrer tunnelens livscyklus og kan svare på spørgsmål via en socket.

• Menneske ved konsollen, ingen automatisering: interaktiv prompt.
• Opstart uden opsyn, hemmeligheden må gemmes: legitimationsfil med mode 0600.
• Opstart uden opsyn, hemmeligheden må ikke gemmes: proceserstatning eller en fd, som en hemmelighedsagent skriver til.
• En anden proces ejer klienten: administrationsgrænseflade.

Når to svar passer, vælg det, der holder hemmeligheden ude af argv og ude af shell-historikken. En adgangskode, der sendes som programargument, kan læses af enhver lokal bruger via proceslisten, og den eksponering er svær at fortryde.

Hvad hver inputsti faktisk gør

--auth-user-pass alene beder om et brugernavn og en adgangskode ved konsollen. Givet et filnavn tager klienten linje et som brugernavn og linje to som adgangskode; intet understøtter citater, kommentarer eller nøgle-værdi-syntaks. Det er hele formatet, så enhver, der redigerer det i forventning om en INI-fil, ødelægger det. En inline <auth-user-pass> blok indeholder de samme to linjer i profilen, hvilket gør profilen selv til en hemmelighed og placerer den i samme håndteringsklasse som en privat nøgle.

De to andre stier er en strøm og en socket. OpenVPN har kun brug for en læsbar fildeskriptor, så den accepterer en proceserstatning, en rørbaseret /dev/fd post eller et filnavn, der faktisk er en FIFO. Administrationsgrænsefladen er anderledes af natur: klienten spørger en overvågende proces om værdierne i stedet for selv at læse dem. Den forskel betyder noget ved genopkobling: en legitimationsfil, en FIFO som en hemmelighedshjælper kan skrive til igen, og administrationsgrænsefladen kan levere igen uden en person; proceserstatning kan ikke, fordi deskriptoren forbruges ved første læsning.

Filen skal være præcis to linjer

To fejltilstande dækker de fleste ødelagte legitimationsfiler. En Windows-editor efterlader CRLF-endelser, carriage return bliver en del af adgangskoden, og serveren afviser en værdi, der ser korrekt ud på skærmen. En tom anden linje - en tom linje, hvor adgangskoden hører til - efterlader klienten med en tom adgangskode, som serveren afviser, selv om værdien på skærmen ser rigtig ud. En ekstra ny linje efter adgangskoden er harmløs. Skriv filen fra shellen, ikke fra en editor, og kontroller bytes:

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

Stien betyder lige så meget som indholdet. En relativ sti opgøres mod processens arbejdskatalog, som for en tjeneste sjældent er det katalog, du testede i. Brug en absolut sti, lad filen være ejet af den konto, der kører klienten, og behold mode 0600, så gruppe og andre ikke kan læse den. OpenVPN 2.6-manualen viser de accepterede former for direktivet; tjek den, før du opfinder en tredje.

Test filen, før du bebrejder serveren. At køre openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 udskriver, om filen blev åbnet, og senere, om legitimationsoplysningerne blev accepteret, hvilket fortæller dig, hvilket lag du skal ændre næste gang.

Strømme, stdin og de fejl, de giver

At pibe adgangskoden ind er det første, de fleste prøver, og den sti med flest overraskelser. Proceserstatning virker, fordi klienten kun har brug for en læsbar deskriptor: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS"). At sende /dev/stdin virker kun, når stdin stadig er åben og læsbar i det øjeblik, klienten spørger, hvilket ikke er tilfældet i en pipeline, der allerede har forbrugt den.

ERROR: could not read Auth username from stdin har to forskellige årsager. På nogle 2.3.x-klienter kom meddelelsen fra en stdin-håndteringsfejl, som senere 2.3-udgivelser rettede, så en så gammel klient bliver kun bedre ved at opgradere. På en nuværende klient betyder samme ordlyd, at klienten bad om konsolinput, og at stdin ikke var en terminal - præcis situationen i en systemd unit, et cron-job eller en container startet uden -t.

auth-nocache tilføjer en tredje løkke, der ser ud som en ødelagt adgangskode. Det smider legitimationsoplysningerne ud af hukommelsen efter brug, så en genopkobling udløst af en netværksændring ikke har noget at afspille, og prompten vender tilbage. Det er direktivet, der virker som designet. auth-nocache ændrer, hvad klienten beholder i hukommelsen, ikke hvad serveren eller identitetsudbyderen mener om kontoen, så hele rettelsen er at levere den samme fil igen, genlæst ved genstart - og for en administreret forbindelse bør den levering komme fra det godkendte hemmelighedslager, ikke en adgangskode i et script.

Administrationsgrænsefladen, når en anden proces ejer prompten

En controller, der allerede overvåger tunnelen, kan også svare på dens spørgsmål. Start klienten med --management 127.0.0.1 7505, læs tilstandslinjerne, og hold øje med >PASSWORD:Need 'Auth' username/password. Controlleren svarer med username "Auth" alice efterfulgt af password "Auth" ... på separate kommandolinjer. 'Auth'-tokenet gentager identifikatoren fra anmodningen og skal matche, ellers ignoreres svaret, og klienten venter.

Prisen er en tilstandsmaskine, du nu ejer: forbindelsesrækkefølge, klientgenstarter og en lokal socket, som andre brugere på værten ikke må nå. Det, du køber, er en legitimationsoplysning leveret ved kørsel, uden fil på disken og uden en prompt, der kan hænge. Hvis intet andet i din stak allerede taler protokollen, tilføjer denne sti en komponent, der skal vedligeholdes.

Fejl, der ligner legitimationsproblemer

Et TLS-håndtryk, der aldrig fuldføres, eller VERIFY ERROR: depth=0, error=certificate signature failure, er et tillidsproblem og sker, før noget brugernavn læses. En proto tcp-klient rettet mod en UDP-lytter fejler samme sted: pakkerne når aldrig godkendelsesfasen, så enhver adgangskode ser forkert ud ved association. Hold certifikatverifikation slået til, før legitimationsoplysningen sendes; en velkendt prompt siger intet om, hvem der modtager adgangskoden. Tjek certifikatkæden, common name og transporten, før du rører legitimationsoplysningen.

Shell-fejl i scriptet, der sammensætter profilen, er det anden falske spor. En manglende mellemrum inde i [ ! -f "$file" ] giver command not found, scriptet stopper tidligt, profilen genopbygges aldrig, og klienten starter med den forrige. Den fejl tilhører shellen, ikke godkendelsen, og uanset hvor mange gange du skriver adgangskoden igen, forsvinder den ikke.

Ikke enhver prompt i dette forløb er denne legitimationsoplysning. En passphrase til en privat nøgle, et HTTP-proxy-login og tjenestens adgangskode er tre forskellige hemmeligheder, der spørges om i forskellige faser, og en nøglepassphrase håndteres normalt af klienten eller en agent i stedet for auth-user-pass. Hvis prompten vises, før TLS-sessionen er oppe, svarer du på det forkerte spørgsmål, og ingen kontonulstilling hjælper. Når den forkerte prompt er udelukket, begynder de resterende kontroller ved det tidligste lag:

• Læs den første protokolfejl, ikke den sidste legitimationslinje: TLS, så godkendelse, så push.
• Bekræft, at filen er to linjer, ikke har carriage returns, og refereres med en absolut sti.
• Bekræft, at profilen og kommandolinjen ikke er uenige om direktivet.
• Adskil "legitimation accepteret" fra "trafik flyder" - routing og DNS er et senere lag.

Når klienten når push-fasen, stop med at kigge på legitimationsoplysninger og begynd at læse de ruter og DNS-servere, serveren sendte. Det er det næste problem, og det har intet at gøre med den adgangskode, du netop har rettet.