OpenVPN-tjenesten stopper ved forespørselen om passordet til den private nøkkelen: slik retter du det

OpenVPN spør etter passfrasen til den private nøkkelen på den lokale maskinen, så en fungerende innloggingsfil svarer aldri på det. I en tjeneste finnes det ingen terminal å skrive i, og oppstarten henger eller feiler med en journaloppføring som navngir inndataene og ikke årsaken. To hemmeligheter er involvert, og hver av dem trenger sin egen lesbare kilde før unit startes på nytt. Gjennomgangen nedenfor skiller dem, og kontrollerer deretter identiteten som faktisk åpner hver fil.

Skill de to forespørslene

Nøkkelens passfrase dekrypterer den lokale private nøkkelen; kontoopplysningene autentiserer økten mot serveren. De kommer fra ulike steder, feiler på ulike tidspunkt og gir ulike meldinger. Å forveksle dem sender folk til å lete etter tilbakestilling av passord når kontoen ikke var involvert i det hele tatt. Les forespørselsteksten før du endrer noen innstilling, fordi ordlyden er det eneste pålitelige hintet om hvilken hemmelighet som mangler.

I Community OpenVPN 2.x angir askpass en fil som holder nøkkelens passfrase på første linje, og auth-user-pass angir en fil med brukernavnet på én linje og passordet på den neste. Ingen av filene kan tilfredsstille den andre innstillingen. Et skrivebordsprogram eller en NetworkManager-profil kan oppbevare begge i sitt eget hemmelighetslager, som en kommandolinjeklient aldri leser, så noter hvilken klient du konfigurerer før du skriver en sti.

Pek begge innstillingene mot lesbare filer

En profil som trenger begge inndataene ender opp med tre filreferanser: den krypterte nøkkelen, passfrasen som låser den opp, og innloggingsparet. Legg dem til uten å røre CA-en eller identitetskontrollene, fordi de avgjør hvem serveren er og ikke er en del av dette problemet. Hvis utrullingen ikke bruker kontoopplysninger i det hele tatt, lager auth-user-pass en inndata 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

Innstillinger uten argument oppfører seg annerledes enn innstillinger med sti, og forskjellen betyr noe i en tjeneste. En askpass uten argument leser fortsatt konsollen, og en auth-user-pass-fil med bare et brukernavn lar fortsatt en passordforespørsel vente. Når klienten daemoniserer, kan den ikke be en terminal om inndata i det hele tatt, så en tjeneste konfigurert slik kommer ikke opp.

Absolutte stier fjerner spørsmålet om arbeidskatalogen, men gir ikke tilgang. Eierskap, modus og gjennomgang kommer deretter, og alle tre kontrolleres mot kontoen prosessen kjører som.

Les unit-ens konfigurasjon før profilen

Det er unit-en, ikke filen du redigerte, som avgjør hvilken konfigurasjon instansen laster. Les kommandolinjen og eventuelle drop-ins, og følg deretter arbeidskatalogen til profilen som faktisk brukes. En passfrase-referanse som legges til i en annen .ovpn-fil endrer ingenting for denne instansen.

Tre skrivebeskyttede kommandoer svarer på det meste. Den første skriver ut unit-en og eventuelle drop-ins, den andre identiteten og sandkasseinnstillingene som binder prosessen, og den tredje hva den siste oppstarten faktisk klaget over. Bruk instansnavnet som finnes på verten:

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

Vær oppmerksom på ProtectHome og på profilens egne innstillinger user, group og chroot. En fil under en hjemmekatalog kan være lesbar i skallet ditt og usynlig inne i tjenesten når hjemmekataloger skjules. Kontoen systemd starter med er ikke alltid kontoen som til slutt åpner nøkkelen.

Bevis at kjøretidsidentiteten kan åpne begge filene

Å lese modusen er ikke nok, fordi hver katalog på stien må kunne gjennomgås av samme identitet. Gå stien gjennom komponent for komponent, og test deretter åpningen som kontoen prosessen bruker. En fil med modus 600 eid av root virker bare mens prosessen fortsatt er root, noe som ikke stemmer etter rettighetsnedgangen mange profiler gjør. To kommandoer dekker gjennomgangen og åpningen:

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

Den første kommandoen skriver ut modusen til hver komponent og feiler der kontoen ikke kan gå gjennom; den andre svarer på det eneste viktige spørsmålet, nemlig om kjøretidsidentiteten kan åpne filen for lesing. Ingen av dem skriver ut filinnhold, og det er poenget når filen holder en passfrase. Gjenta testen for innloggingsfilen, fordi de to ofte lagres med ulikt eierskap.

Hvis prosessen bruker en chroot eller et begrenset namespace, kjør den samme testen inne fra den visningen, ellers beskriver svaret feil filsystem. En passfrase lagret under en skjult hjemmekatalog er det vanlige eksempelet på en test som består utenfor unit-en og feiler inni den.

Kontroller den første oppstarten, deretter en gjenoppkobling

Start instansen én gang og les den første feilen i stedet for den siste. En manglende inndatafil, en mislykket nøkkeldekryptering og en AUTH_FAILED fra serveren er tre ulike hendelser med tre ulike reparasjoner. Å rette en tillatelsesadvarsel beviser ingenting om hvorvidt nøkkelen ble låst opp.

Journal-linjen forteller hvilken av de tre du har. Reparasjonen følger av hvilken inndata som feilet:

Test deretter livssyklusen du faktisk trenger: en oppstart ved boot og enhver støttet gjenoppkobling, ikke bare en manuell oppstart fra skallet ditt. Med auth-nocache forkastes inndataene etter første bruk, så en senere gjenoppkobling trenger fortsatt en lesbar kilde. En nøkkelring som låses opp ved skrivebordsinnlogging er ikke tilgjengelig for en tjeneste som startet før noen logget inn, og det er den vanlige grunnen til at en manuell test består og en omstart feiler. Hvis den første oppstarten lykkes og en senere gjenoppkobling feiler, les journalen for gjenoppkoblingshendelsen før du endrer tillatelser igjen.

Å lagre passfrasen ved siden av nøkkelen reduserer hva krypteringen gir deg, så begrens den filen og sikkerhetskopiene. Behandle fjerning av nøkkelens passfrase som en egen legitimasjonsbeslutning i stedet for reparasjonen for en manglende inndata. En utrulling som avhenger av menneskelig godkjenning eller interaktiv MFA trenger sin støttede agent eller administrasjonsintegrasjon; en permanent lagret engangskode er ikke en likeverdig erstatning.