auth-nocache med en legitimationsfil: hjälper det eller skadar det?

OpenVPN skriver vid start ut en varning som föreslår auth-nocache, och det frestande svaret är att lägga till alternativet och se raden försvinna. Det rådet förutsätter en interaktiv inloggning. När användarnamn och lösenord väl ligger i en fil ändras jämförelsen: alternativet slutar skydda den varaktiga kopian, och på en klient som släpper privilegier kan det senare bryta omförhandlingen. Två lagringsmodeller är värda att hålla isär innan du redigerar en profil.

Två sätt att svara på legitimationsförfrågan

Den första modellen är en människa som skriver in uppgifter i en terminal, eller ett administrationsgränssnitt som håller dem för sessionen. OpenVPN behåller den kopian för att kunna svara på nästa omförhandling utan att fråga igen, och det är precis vad varningen handlar om. Inget på disken är inblandat, så det enda som behöver skyddas är processen som håller värdet. Stäng klienten och kopian är borta med den.

Den andra modellen är auth-user-pass som pekar på en fil, där filen är lagret och klienten läser den när ett värde behövs. Det som exponeras här är inte processminnet utan rättigheterna och ägandet till den filen. Startvarningen kommer från direktiven i konfigurationen, inte från en kontroll av hur du levererar lösenordet, så den visas i båda modellerna och pekar inte ut någon av dem.

Resten av jämförelsen följer av den uppdelningen: minneshantering för den ena modellen, filhantering och processidentitet för den andra.

Vad auth-nocache faktiskt kastar

Med en interaktiv inloggning --auth-nocache tar bort den sparade kopian från minnet efter att den använts. Priset är en ny förfrågan vid varje omförhandlingsintervall, eftersom nästa omgång inte kan återanvända det som kastats.

Med filbaserad inloggning kan klienten läsa filen igen, så kastandet är mestadels osynligt. Det blir synligt på den enda plats där människor inte förväntar sig det: efter att daemonen släppt privilegier, om legitimationsfilen inte kan läsas av det konto den nu kör som.

Lägg till alternativet för att du förstår den avvägningen, inte för att en varning dök upp. Ett alternativ som läggs till för att göra en logg tystare är ett alternativ vars effekt ingen har mätt.

Där den filbaserade vägen brister

En klient som startar som root för att öppna tunneleenheten och sedan byter till user och group läser legitimationsfilen två gånger: en gång före bytet, en gång vid omförhandlingen som följer. Om filen har mod 600 och ägs av root misslyckas den andra läsningen, och felet visar sig en timme senare som ett autentiseringsfel som ser ut som ett serverproblem. Kontrollera klientloggen kring omförhandlingsintervallet och kontrollera sedan kontot och filen tillsammans.

stat -c '%a %U:%G' /etc/openvpn/client.creds
ps -o user:12,args -C openvpn | head

Båda raderna spelar roll. Den första säger vem som kan läsa filen, den andra säger vem den körande daemonen faktiskt är, och en diskrepans mellan dem förklarar ett fel som ingen mängd omskrivning av lösenordet kommer att åtgärda.

De praktiska rättelserna är oglamorösa: flytta filen till en katalog och en ägare som daemonens konto kan läsa, eller behåll den privilegierade läsningen och bekräfta att din klient bara läser en gång. Lös det inte genom att göra filen läsbar för alla.

Fallet som verkligen vill ha alternativet

En inloggning med engångskod vill ha auth-nocache av en annan anledning. En engångskod förbrukas av den första autentiseringen, så en cachad kopia är värdelös vid nästa omförhandling, och ett inaktuellt värde skulle till och med kunna spelas upp igen.

Det är en fråga om typen av legitimationsuppgift, inte om var den lagras. Ett statiskt lösenord i en skyddad fil har den motsatta profilen: det måste vara läsbart vid varje omförhandling, och skyddet du behöver sitter på filen.

Håll de två skälen åtskilda i profilkommentarerna, annars kommer nästa administratör att anta att alternativet finns där av det skäl han själv skulle ha valt.

Jämförelsen i ett beslut

Välj den interaktiva modellen när en människa är närvarande och färskhet spelar roll, och acceptera den upprepade förfrågan som priset. Välj filmodellen när klienten körs obevakad, och lägg ansträngningen på ägande, mod och privilegiesläpp i stället.

Ingen av modellerna gör ett lagrat lösenord säkert i sig, och ingen av dem gör startvarningen meningsfull.

Om varningen är det enda skälet till att du öppnade profilen, anteckna beslutet i stället för ett oförklarat alternativ: uppgifterna kommer från en fil som daemonens konto kan läsa, en omförhandling har setts lyckas, och avsnittet om omförhandling i OpenVPN 2.6-handboken lästes innan dess intervall ändrades. Den anteckningen överlever varje enskild flagga.