OpenVPN-tjänsten fastnar vid frågan om lösenordet för den privata nyckeln: så åtgärdar du det

OpenVPN frågar efter lösenfrasen för den privata nyckeln på den lokala maskinen, så en fungerande inloggningsfil svarar aldrig på den. I en tjänst finns ingen terminal att skriva i, och starten hänger sig eller misslyckas med en journalpost som namnger indata i stället för orsaken. Två hemligheter är inblandade, och var och en behöver sin egen läsbara källa innan unit startas om. Genomgången nedan skiljer dem åt och kontrollerar sedan den identitet som faktiskt öppnar varje fil.

Skilj på de två frågorna

Nyckelns lösenfras dekrypterar den lokala privata nyckeln; kontouppgifterna autentiserar sessionen mot servern. De kommer från olika platser, misslyckas vid olika tillfällen och ger olika meddelanden. Att blanda ihop dem får folk att leta efter en återställning av lösenordet trots att kontot inte var inblandat. Läs frågetexten innan du ändrar något alternativ, eftersom formuleringen är den enda pålitliga ledtråden om vilken hemlighet som saknas.

I Community OpenVPN 2.x anger askpass en fil som håller nyckelns lösenfras på första raden, och auth-user-pass anger en fil med användarnamnet på en rad och lösenordet på nästa. Ingen av filerna kan uppfylla det andra alternativet. En skrivbordsapp eller en NetworkManager-profil kan förvara båda i sitt eget hemlighetslager, som en kommandoradsclient aldrig läser, så notera vilken klient du konfigurerar innan du skriver någon sökväg.

Peka båda alternativen mot läsbara filer

En profil som behöver båda indata slutar med tre filreferenser: den krypterade nyckeln, lösenfrasen som låser upp den och inloggningsparet. Lägg till dem utan att röra CA:n eller identitetskontrollerna, eftersom de avgör vem servern är och inte är en del av det här problemet. Om utrullningen inte använder kontouppgifter alls skapar auth-user-pass en indata som ingen kan tillhandahålla.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Alternativ utan argument beter sig annorlunda än alternativ med sökväg, och i en tjänst spelar skillnaden roll. En askpass utan argument läser fortfarande konsolen, och en auth-user-pass-fil med bara ett användarnamn lämnar fortfarande en lösenordsfråga väntande. När klienten blir en daemon kan den inte alls be en terminal om indata, så en tjänst som konfigurerats så startar inte.

Absoluta sökvägar tar bort frågan om arbetskatalogen men ger ingen åtkomst. Ägande, läge och genomgång kommer därefter, och alla tre kontrolleras mot det konto som processen körs som.

Läs unit:ens konfiguration före profilen

Det är unit:en, inte filen du redigerade, som avgör vilken konfiguration instansen laddar. Läs dess kommandorad och eventuella drop-ins och följ sedan arbetskatalogen till den profil som faktiskt används. En lösenfrasreferens som läggs till i en annan .ovpn-fil ändrar ingenting för den här instansen.

Tre skrivskyddade kommandon svarar på det mesta. Det första skriver ut unit:en och eventuella drop-ins, det andra identiteten och de sandlådeinställningar som binder processen, och det tredje vad den senaste starten faktiskt klagade på. Använd instansnamnet som finns på värden:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Var uppmärksam på ProtectHome och på profilens egna alternativ user, group och chroot. En fil under en hemkatalog kan vara läsbar i ditt skal och osynlig inuti tjänsten när hemkataloger döljs. Kontot som systemd startar med är inte alltid det konto som till slut öppnar nyckeln.

Bevisa att körtidsidentiteten kan öppna båda filerna

Att läsa läget räcker inte, eftersom varje katalog på vägen måste kunna passeras av samma identitet. Gå igenom sökvägen komponent för komponent och testa sedan öppningen som det konto processen använder. En fil med läget 600 som ägs av root fungerar bara så länge processen fortfarande är root, vilket inte stämmer efter den rättighetssänkning som många profiler gör. Två kommandon täcker genomgången och öppningen:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

Det första kommandot skriver ut läget för varje komponent och misslyckas där kontot inte kan passera; det andra svarar på den enda viktiga frågan, nämligen om körtidsidentiteten kan öppna filen för läsning. Ingen av dem skriver ut filinnehåll, och det är själva poängen när filen håller en lösenfras. Upprepa testet för inloggningsfilen, eftersom de två ofta lagras med olika ägare.

Om processen använder en chroot eller en begränsad namespace, kör samma test inifrån den vyn, annars beskriver svaret fel filsystem. En lösenfras som lagras under en dold hemkatalog är det vanliga exemplet på ett test som lyckas utanför unit:en och misslyckas inuti den.

Kontrollera den första starten och sedan en återanslutning

Starta instansen en gång och läs det första felet i stället för det sista. En saknad indatafil, en misslyckad nyckeldekryptering och en AUTH_FAILED från servern är tre olika händelser med tre olika åtgärder. Att rätta en behörighetsvarning bevisar ingenting om huruvida nyckeln låstes upp.

Journalraden talar om vilken av de tre du har. Åtgärden följer av vilken indata som misslyckades:

Testa sedan livscykeln du faktiskt behöver: en start vid boot och varje stödd återanslutning, inte bara en manuell start från ditt skal. Med auth-nocache kastas indata efter första användningen, så en senare återanslutning behöver fortfarande en läsbar källa. En nyckelring som låses upp vid skrivbordsinloggning är inte tillgänglig för en tjänst som startade innan någon loggade in, och det är den vanliga orsaken till att ett manuellt test lyckas och en omstart misslyckas. Om den första starten lyckas och en senare återanslutning misslyckas, läs journalen för återanslutningshändelsen innan du ändrar behörigheter igen.

Att lagra lösenfrasen bredvid nyckeln minskar vad krypteringen ger dig, så begränsa den filen och dess säkerhetskopior. Behandla borttagning av nyckelns lösenfras som ett separat beslut om inloggningsuppgifter, inte som åtgärden för en saknad indata. En utrullning som beror på mänskligt godkännande eller interaktiv MFA behöver sin stödda agent eller administrationsintegration; en permanent lagrad engångskod är ingen likvärdig ersättning.