Rättelse: OpenVPN kunde inte läsa Auth-användarnamnet från standardindata

could not read Auth username from stdin ser ut som ett autentiseringsproblem och är det inte. OpenVPN försökte fråga efter användarnamnet på standardindata, hittade inget läsbart och stoppade innan det någonsin kontaktade servern. Kontot kan vara helt giltigt; processen har helt enkelt ingen att fråga.

Därför är det första användbara steget att bekräfta vad klienten läser, inte att försöka ansluta igen eller ändra inställningar på serversidan. Gå igenom kontrollerna nedan i ordning och stanna vid den första som misslyckas.

Läs felet som ett lokalt indatafel

När auth-user-pass visas utan ett filargument förväntar sig klienten att fråga. I ett interaktivt skal fungerar den frågan eftersom processen äger en terminal. Under systemd, ett cron-jobb eller en container är standardindata vanligtvis tom, och läsningen återvänder direkt med felet du ser.

Meddelandet namnger också fältet som misslyckades, användarnamn eller lösenord, vilket visar hur långt läsningen kom. Ett saknat användarnamn betyder att processen inte kunde läsa någonting alls. Ett saknat lösenord efter ett lyckat användarnamn betyder att indataströmmen tog slut mellan de två läsningarna, vilket är typiskt för en halvskriven fil eller ett stängt rör.

Bekräfta klientens egen bild innan du ändrar något annat. Kör den i förgrunden med samma konfiguration och samma användare, och se om frågan dyker upp. Om den gör det i ditt skal men inte under tjänstehanteraren är skillnaden indatakällan, inte inloggningsuppgifterna. En snabb jämförelse av unit-filen och din skal miljö visar vanligtvis vilken av dem som tillhandahåller en terminal.

Ge tjänsten en källa för inloggningsuppgifter som stöds

Den källa som stöds för obevakad drift är en fil med inloggningsuppgifter som skickas som argument till auth-user-pass. Filen läses som ren text: den första raden är användarnamnet, den andra är lösenordet. Peka på den med en absolut sökväg som /etc/openvpn/client/creds , så att tjänstekontots arbetskatalog inte kan ändra direktivets betydelse.

Behörigheter spelar lika stor roll som sökvägen. Filen måste vara läsbar för kontot som kör klienten och inte för alla andra, och den bör ägas av tjänstekontot eller av root med en grupp som omfattar tjänsten. Kontrollera läsbarheten som det kontot, utan att skriva ut innehållet.

En relativ sökväg är det tysta felet. Profilen kan ligga i en katalog medan systemd startar processen någon annanstans, så en fil som löses i ditt skal löses inte för tjänsten. Flytta inloggningsuppgifterna till en fast plats och referera till dem absolut. Starta sedan tjänsten en gång och bekräfta att samma sökväg används, i stället för att lita på profilredigerarens vy.

Om driftsättningen kräver en engångskod eller en annan interaktiv utmaning, avgör om klientens arbetsflöde verkligen stöder det obevakat. En fil med ett statiskt lösenord kan inte svara på en roterande kod, och att försöka igen med en fråga som inte kan besvaras tillför ingen information.

Varför script-security inte hjälper

script-security styr om klienten får köra skript och hur mycket den får skicka till dem, inklusive om ett lösenord kan ges till ett skript via en miljövariabel. Den säger ingenting om var användarnamn och lösenord kommer ifrån från början.

Att höja den till en högre nivå är en vanlig reflex eftersom meddelandet nämner Auth, men det ändrar skriptbehörigheter snarare än indatakällan, och det vidgar vad klienten får köra. Om ett hjälpskript är en del av designen, åtgärda indatakällan först och håll säkerhetsnivån på det lägsta värde som driftsättningen behöver.

Hanteringsgränssnittet är ett legitimt alternativ. En frontend kan ansluta till det, ta emot begäran om inloggningsuppgifter och svara med användarnamn och lösenord, så fungerar vissa GUI. Om du använder det, bind det till en lokal adress, skydda det med en hanteringslösenordsfil och begränsa vem som kan ansluta, eftersom det är en styrkanal för klienten.

Verifiera nästa steg efter att klienten har läst filen

När klienten kan läsa inloggningsuppgifterna är nästa fel ett verkligt utbyte med servern, och dess meddelande har en annan betydelse. Ett autentiseringsfel i det steget betyder att servern avvisade kontot; ett utmaningssvar betyder att servern vill ha en annan faktor. Behandla dem som nya problem och inte som samma sak upprepad.

Testa hela vägen som tjänsten kommer att köra den: samma konto, samma arbetskatalog, samma unit-miljö. En anslutning som bara fungerar när den startas från ditt skal är ett tecken på att en miljövariabel eller en terminal fortfarande är en del av flödet.

Håll sedan hemligheterna där de hör hemma. Lösenord i kommandoradsargument syns i processtabellen, och lösenord i felsökningsutdata hamnar i ärenden. Använd en skyddad fil eller hanteringsgränssnittet, håll loggarna på en nivå som inte upprepar inloggningsuppgifter, och byt filen när någon med åtkomst slutar.

Checklista: absolut sökväg till inloggningsuppgifterna, läsbar som tjänstekonto, ingen terminal krävs, script-security lämnat på minimum, hanteringsgränssnitt endast om det är bundet och autentiserat, och serverns svar som följer behandlas som en separat händelse.