OpenVPN-tjenesten stopper ved anmodningen om privatnøglens adgangsfrase: sådan rettes det

OpenVPN spørger efter privatnøglens adgangsfrase på den lokale maskine, så en fungerende loginfil svarer den aldrig på. I en tjeneste er der ingen terminal at skrive i, og starten hænger enten eller fejler med en journalpost, der navngiver inputtet frem for årsagen. Der er to hemmeligheder involveret, og hver især skal have sin egen læsbare kilde, før unit genstartes. Gennemgangen nedenfor skiller dem og kontrollerer derefter den identitet, der faktisk åbner hver fil.

Skeln mellem de to anmodninger

Nøglens adgangsfrase dekrypterer den lokale privatnøgle; kontooplysningerne autentificerer sessionen mod serveren. De kommer fra forskellige steder, fejler på forskellige tidspunkter og giver forskellige meddelelser. At forveksle dem sender folk til at lede efter en nulstilling af adgangskoden, selvom kontoen slet ikke var involveret. Læs anmodningsteksten, før du ændrer en indstilling, for formuleringen er det eneste pålidelige fingerpeg om, hvilken hemmelighed der mangler.

I Community OpenVPN 2.x angiver askpass en fil, der holder nøglens adgangsfrase på første linje, og auth-user-pass angiver en fil med brugernavnet på en linje og adgangskoden på den næste. Ingen af filerne kan opfylde den anden indstilling. En skrivebordsapp eller en NetworkManager-profil kan gemme begge i sit eget hemmelighedslager, som en kommandolinjeklient aldrig læser, så notér hvilken klient du konfigurerer, før du skriver en sti.

Peg begge indstillinger mod læsbare filer

En profil, der skal bruge begge input, ender med tre filreferencer: den krypterede nøgle, adgangsfrasen der låser den op, og loginparret. Tilføj dem uden at røre CA’en eller identitetskontrollerne, for dem afgør, hvem serveren er, og er ikke en del af dette problem. Hvis udrulningen slet ikke bruger kontooplysninger, skaber auth-user-pass et input, som ingen kan levere.

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

Indstillinger uden argument opfører sig anderledes end indstillinger med stier, og forskellen betyder noget i en tjeneste. En askpass uden argument læser stadig konsollen, og en auth-user-pass-fil med kun et brugernavn efterlader stadig en adgangskodeanmodning ventende. Når klienten daemoniserer, kan den slet ikke spørge en terminal om input, så en tjeneste konfigureret sådan kommer ikke op.

Absolutte stier fjerner spørgsmålet om arbejdsbiblioteket, men giver ikke adgang. Ejerskab, tilstand og gennemløb kommer derefter, og alle tre kontrolleres mod den konto, processen kører som.

Læs unit’ens konfiguration før profilen

Det er unit’en, ikke filen du redigerede, der afgør, hvilken konfiguration instansen indlæser. Læs dens kommandolinje og eventuelle drop-ins, og følg derefter arbejdsbiblioteket til den profil, der faktisk bruges. En adgangsfrase-reference, der føjes til en anden .ovpn-fil, ændrer intet for denne instans.

Tre skrivebeskyttede kommandoer besvarer det meste. Den første udskriver unit’en og eventuelle drop-ins, den anden udskriver den identitet og de sandbox-indstillinger, der binder processen, og den tredje udskriver, hvad den sidste start faktisk klagede over. Brug det instansnavn, der findes på værten:

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

Vær opmærksom på ProtectHome og på profilens egne indstillinger user, group og chroot. En fil under et hjemmebibliotek kan være læsbar i din shell og usynlig inde i tjenesten, når hjemmebiblioteker skjules. Den konto, systemd starter med, er ikke altid den konto, der ender med at åbne nøglen.

Bevis, at runtime-identiteten kan åbne begge filer

Det er ikke nok at læse tilstanden, for hvert bibliotek på stien skal kunne gennemløbes af den samme identitet. Gå stien igennem komponent for komponent, og prøv derefter åbningen som den konto, processen bruger. En fil med tilstand 600 ejet af root virker kun, mens processen stadig er root, hvilket ikke er sandt efter den rettighedsnedsættelse, mange profiler udfører. To kommandoer dækker gennemløbet og åbningen:

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

Den første kommando udskriver tilstanden for hver komponent og fejler, hvor kontoen ikke kan gennemløbe; den anden besvarer det eneste vigtige spørgsmål, nemlig om runtime-identiteten kan åbne filen til læsning. Ingen af dem udskriver filindhold, og det er pointen, når filen holder en adgangsfrase. Gentag testen for loginfilen, for de to gemmes ofte med forskelligt ejerskab.

Hvis processen bruger en chroot eller et begrænset namespace, skal du køre den samme test inde fra den visning, ellers beskriver svaret det forkerte filsystem. En adgangsfrase gemt under et skjult hjemmebibliotek er det sædvanlige eksempel på en test, der består uden for unit’en og fejler indeni.

Kontroller den første start, derefter en genopkobling

Start instansen én gang, og læs den første fejl i stedet for den sidste. En manglende inputfil, en mislykket nøgledekryptering og en AUTH_FAILED fra serveren er tre forskellige hændelser med tre forskellige rettelser. At rette en tilladelsesadvarsel beviser intet om, hvorvidt nøglen blev låst op.

Journalposten fortæller, hvilken af de tre du har. Rettelsen følger af, hvilket input der fejlede:

Test derefter den livscyklus, du faktisk har brug for: en start ved boot og enhver understøttet genopkobling, ikke kun en manuel start fra din shell. Med auth-nocache kasseres inputtet efter første brug, så en senere genopkobling har stadig brug for en læsbar kilde. En nøglering, der låses op ved skrivebordslogin, er ikke tilgængelig for en tjeneste, der startede, før nogen loggede ind, og det er den sædvanlige grund til, at en manuel test består og en genstart fejler. Hvis den første start lykkes, og en senere genopkobling fejler, så læs journalen for genopkoblingshændelsen, før du ændrer tilladelser igen.

At gemme adgangsfrasen ved siden af nøglen reducerer, hvad krypteringen køber dig, så begræns den fil og dens sikkerhedskopier. Behandl fjernelse af nøglens adgangsfrase som en separat legitimationsbeslutning i stedet for rettelsen for et manglende input. En udrulning, der afhænger af menneskelig godkendelse eller interaktiv MFA, har brug for sin understøttede agent eller administrationsintegration; en permanent gemt engangskode er ikke en tilsvarende erstatning.