Retting: OpenVPN kunne ikke lese Auth-brukernavnet fra standard inndata

could not read Auth username from stdin ser ut som et autentiseringsproblem og er det ikke. OpenVPN prøvde å spørre om brukernavnet på standard inndata, fant ingenting lesbart og stoppet før det noen gang kontaktet serveren. Kontoen kan være helt gyldig; prosessen har rett og slett ingen å spørre.

Derfor er det første nyttige trinnet å bekrefte hva klienten leser, ikke å prøve tilkoblingen på nytt eller endre innstillinger på serversiden. Gå gjennom kontrollene nedenfor i rekkefølge, og stopp ved den første som feiler.

Les feilen som en lokal inndatafeil

Når auth-user-pass vises uten et filargument, forventer klienten å spørre. I et interaktivt skall fungerer den forespørselen fordi prosessen eier en terminal. Under systemd, en cron-jobb eller en container er standard inndata vanligvis tom, og lesingen kommer straks tilbake med feilen du ser.

Meldingen navngir også feltet som feilet, brukernavn eller passord, noe som viser hvor langt lesingen kom. Et manglende brukernavn betyr at prosessen ikke kunne lese noe i det hele tatt. Et manglende passord etter et vellykket brukernavn betyr at inndatastrømmen tok slutt mellom de to lesingene, noe som er typisk for en halvskrevet fil eller et lukket rør.

Bekreft klientens eget syn før du endrer noe annet. Kjør den i forgrunnen med samme konfigurasjon og samme bruker, og se om forespørselen vises. Hvis den gjør det i skallet ditt, men ikke under tjenestebehandleren, er forskjellen inndatakilden, ikke legitimasjonsdataene. En rask sammenligning av unit-filen og skallmiljøet ditt viser vanligvis hvilken av dem som gir en terminal.

Gi tjenesten en støttet kilde for legitimasjonsdata

Den støttede kilden for uovervåket drift er en legitimasjonsfil som sendes som argument til auth-user-pass. Filen leses som ren tekst: den første linjen er brukernavnet, den andre er passordet. Pek på den med en absolutt sti som /etc/openvpn/client/creds , slik at tjenestekontoens arbeidskatalog ikke kan endre betydningen av direktivet.

Tillatelser betyr like mye som stien. Filen må kunne leses av kontoen som kjører klienten, og ikke av alle andre, og den bør eies av tjenestekontoen eller av root med en gruppe som omfatter tjenesten. Kontroller lesbarheten som den kontoen, uten å skrive ut innholdet.

En relativ sti er den stille feilmodusen. Profilen kan ligge i én katalog mens systemd starter prosessen et annet sted, så en fil som løses i skallet ditt, løses ikke for tjenesten. Flytt legitimasjonsdataene til et fast sted og referer til dem absolutt. Start deretter tjenesten én gang og bekreft at samme sti brukes, i stedet for å stole på profileditoren.

Hvis utrullingen krever en engangskode eller en annen interaktiv utfordring, avgjør om klientens arbeidsflyt faktisk støtter det uovervåket. En fil med et statisk passord kan ikke svare på en roterende kode, og å prøve en forespørsel som ikke kan besvares på nytt tilfører ingen informasjon.

Hvorfor script-security ikke hjelper

script-security styrer om klienten kan kjøre skript og hvor mye den kan sende til dem, inkludert om et passord kan gis til et skript via en miljøvariabel. Den sier ingenting om hvor brukernavn og passord kommer fra i utgangspunktet.

Å heve den til et høyere nivå er en vanlig refleks fordi meldingen nevner Auth, men det endrer skripttillatelser snarere enn inndatakilden, og utvider hva klienten kan kjøre. Hvis et hjelpeskript er en del av designet, fiks inndatakilden først og hold sikkerhetsnivået på den laveste verdien utrullingen trenger.

Administrasjonsgrensesnittet er et legitimt alternativ. En frontend kan koble til det, motta forespørselen om legitimasjonsdata og svare med brukernavn og passord, slik noen GUI-er fungerer. Hvis du bruker det, bind det til en lokal adresse, beskytt det med en administrasjonspassordfil og begrens hvem som kan koble til, fordi det er en kontrollkanal for klienten.

Verifiser neste trinn etter at klienten har lest filen

Når klienten kan lese legitimasjonsdataene, er neste feil en ekte utveksling med serveren, og meldingen har en annen betydning. En autentiseringsfeil på det trinnet betyr at serveren avviste kontoen; et utfordringssvar betyr at serveren vil ha en annen faktor. Behandle dem som nye problemer i stedet for det samme gjentatt.

Test hele veien slik tjenesten vil kjøre den: samme konto, samme arbeidskatalog, samme unit-miljø. En tilkobling som bare fungerer når den startes fra skallet ditt, er et tegn på at en miljøvariabel eller en terminal fortsatt er en del av flyten.

Hold deretter hemmelighetene der de hører hjemme. Passord i kommandolinjeargumenter vises i prosesslisten, og passord i feilsøkingsutdata ender i saker. Bruk en beskyttet fil eller administrasjonsgrensesnittet, hold loggene på et nivå som ikke gjentar legitimasjonsdata, og bytt filen når noen med tilgang slutter.

Sjekkliste: absolutt sti til legitimasjonsdata, lesbar som tjenestekonto, ingen terminal påkrevd, script-security latt være på minimum, administrasjonsgrensesnitt bare hvis det er bundet og autentisert, og serverresponsen som følger behandles som en separat hendelse.