Rettelse: OpenVPN kunne ikke læse Auth-brugernavnet fra standardinput

could not read Auth username from stdin ligner et godkendelsesproblem og er det ikke. OpenVPN forsøgte at spørge om brugernavnet på standardinput, fandt intet læsbart og stoppede, før det nogensinde kontaktede serveren. Kontoen kan være helt gyldig; processen har simpelthen ingen at spørge.

Derfor er det første nyttige skridt at bekræfte, hvad klienten læser, ikke at prøve forbindelsen igen eller ændre indstillinger på serversiden. Gå gennem kontrollerne nedenfor i rækkefølge, og stop ved den første, der fejler.

Læs fejlen som en lokal inputfejl

Når auth-user-pass optræder uden et filargument, forventer klienten at spørge. I en interaktiv shell virker den prompt, fordi processen ejer en terminal. Under systemd, et cron-job eller en container er standardinput normalt tom, og læsningen vender straks tilbage med den fejl, du ser.

Meddelelsen angiver også det felt, der fejlede, brugernavn eller adgangskode, hvilket fortæller, hvor langt læsningen nåede. Et manglende brugernavn betyder, at processen slet ikke kunne læse noget. Et manglende adgangskode efter et vellykket brugernavn betyder, at inputstrømmen sluttede mellem de to læsninger, hvilket er typisk for en halvskrevet fil eller et lukket rør.

Bekræft klientens eget syn, før du ændrer noget andet. Kør den i forgrunden med samme konfiguration og samme bruger, og se, om prompten vises. Hvis den gør i din shell men ikke under tjenestestyringen, er forskellen inputkilden, ikke legitimationsoplysningerne. En hurtig sammenligning af unit-filen og dit shell-miljø viser normalt, hvilken der leverer en terminal.

Giv tjenesten en understøttet kilde til legitimationsoplysninger

Den understøttede kilde til uovervåget drift er en legitimationsfil, der sendes som argument til auth-user-pass. Filen læses som ren tekst: den første linje er brugernavnet, den anden er adgangskoden. Peg på den med en absolut sti som /etc/openvpn/client/creds , så tjenestekontoens arbejdsmappe ikke kan ændre direktivets betydning.

Tilladelser betyder lige så meget som stien. Filen skal kunne læses af den konto, der kører klienten, og ikke af alle andre, og den bør ejes af tjenestekontoen eller af root med en gruppe, der omfatter tjenesten. Kontroller læsbarheden som den konto uden at udskrive indholdet.

En relativ sti er den stille fejltilstand. Profilen kan ligge i én mappe, mens systemd starter processen et andet sted, så en fil, der findes i din shell, findes ikke for tjenesten. Flyt legitimationsoplysningerne til et fast sted, og referer til dem absolut. Start derefter tjenesten én gang, og bekræft, at samme sti bruges, i stedet for at stole på profileditorens visning.

Hvis udrulningen kræver en engangskode eller en anden interaktiv udfordring, skal du beslutte, om klientens arbejdsgang faktisk understøtter det uovervåget. En fil med en statisk adgangskode kan ikke svare på en roterende kode, og gentagne forsøg på en prompt, der ikke kan besvares, tilføjer ingen information.

Hvorfor script-security ikke hjælper

script-security styrer, om klienten må køre scripts, og hvor meget den må give dem, herunder om en adgangskode kan gives til et script via en miljøvariabel. Den siger intet om, hvor brugernavn og adgangskode kommer fra i første omgang.

At hæve den til et højere niveau er en almindelig refleks, fordi meddelelsen nævner Auth, men det ændrer scripttilladelser snarere end inputkilden og udvider, hvad klienten må udføre. Hvis et hjælpescript er en del af designet, skal du først rette inputkilden og holde sikkerhedsniveauet på den laveste værdi, som udrulningen har brug for.

Styringsgrænsefladen er et legitimt alternativ. En frontend kan forbinde til den, modtage anmodningen om legitimationsoplysninger og svare med brugernavn og adgangskode, hvilket er, hvordan nogle GUI'er fungerer. Hvis du bruger den, skal du binde den til en lokal adresse, beskytte den med en styringsadgangskodefil og begrænse, hvem der kan forbinde, fordi det er en kontrolkanal for klienten.

Bekræft næste trin, efter at klienten har læst filen

Når klienten kan læse legitimationsoplysningerne, er den næste fejl en reel udveksling med serveren, og dens meddelelse har en anden betydning. En godkendelsesfejl på det trin betyder, at serveren afviste kontoen; et udfordringssvar betyder, at serveren vil have en anden faktor. Behandl dem som nye problemer i stedet for det samme gentaget.

Test hele vejen, som tjenesten vil køre den: samme konto, samme arbejdsmappe, samme unit-miljø. En forbindelse, der kun virker, når den startes fra din shell, er et tegn på, at en miljøvariabel eller en terminal stadig er en del af flowet.

Hold derefter hemmelighederne, hvor de hører hjemme. Adgangskoder i kommandolinjeargumenter vises i procestabellen, og adgangskoder i fejlretningsoutput ender i sager. Brug en beskyttet fil eller styringsgrænsefladen, hold logfiler på et niveau, der ikke gentager legitimationsoplysninger, og skift filen, når nogen med adgang forlader.

Tjekliste: absolut sti til legitimationsoplysninger, læsbar som tjenestekonto, ingen terminal påkrævet, script-security efterladt på minimum, styringsgrænseflade kun hvis den er bundet og godkendt, og det resulterende serversvar behandles som en separat hændelse.