OpenVPN-tenesta stoppar ved spørsmålet om passordet til den private nøkkelen: slik rettar du det

OpenVPN spør etter passfrasen til den private nøkkelen på den lokale maskinen, så ei fungerande innloggingsfil svarar aldri på det. I ei teneste finst det ingen terminal å skrive i, og oppstarten hengjer eller feilar med ei journaloppføring som nemner inndataene og ikkje årsaka. To løyndomar er involvert, og kvar av dei treng si eiga lesbare kjelde før unit blir starta på nytt. Gjennomgangen nedanfor skil dei, og kontrollerer deretter identiteten som faktisk opnar kvar fil.

Skil dei to spørsmåla

Passfrasen til nøkkelen dekrypterer den lokale private nøkkelen; kontoopplysningane autentiserer økta mot serveren. Dei kjem frå ulike stader, feilar på ulike tidspunkt og gir ulike meldingar. Å forveksle dei sender folk til å leite etter tilbakestilling av passord når kontoen ikkje var involvert i det heile. Les teksten i spørsmålet før du endrar noka innstilling, fordi ordlyden er det einaste pålitelege hintet om kva løyndom som manglar.

I Community OpenVPN 2.x peikar askpass på ei fil som held passfrasen til nøkkelen på første linje, og auth-user-pass på ei fil med brukarnamnet på éi linje og passordet på den neste. Ingen av filene kan oppfylle den andre innstillinga. Eit skrivebordsprogram eller ein NetworkManager-profil kan oppbevare begge i sitt eige løyndomslager, som ein kommandolinjeklient aldri les, så noter kva klient du konfigurerer før du skriv ein sti.

Peik begge innstillingane mot lesbare filer

Ein profil som treng begge inndataa endar opp med tre filreferansar: den krypterte nøkkelen, passfrasen som låser han opp, og innloggingsparet. Legg dei til utan å røre CA-en eller identitetskontrollane, fordi dei avgjer kven serveren er og ikkje er ein del av dette problemet. Viss utrullinga ikkje brukar kontoopplysningar i det heile, lagar auth-user-pass ei 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

Innstillingar utan argument oppfører seg annleis enn innstillingar med sti, og skilnaden betyr noko i ei teneste. Ein askpass utan argument les framleis konsollen, og ei auth-user-pass-fil med berre eit brukarnamn lèt framleis eit passordspørsmål vente. Når klienten daemoniserer, kan han ikkje be ein terminal om inndata i det heile, så ei teneste konfigurert slik kjem ikkje opp.

Absolutte stiar fjernar spørsmålet om arbeidskatalogen, men gir ikkje tilgang. Eigarskap, modus og gjennomgang kjem deretter, og alle tre blir kontrollerte mot kontoen prosessen køyrer som.

Les konfigurasjonen til unit før profilen

Det er unit, ikkje fila du redigerte, som avgjer kva konfigurasjon instansen lastar. Les kommandolinja og eventuelle drop-ins, og følg deretter arbeidskatalogen til profilen som faktisk blir brukt. Ein passfrase-referanse som blir lagd til i ei anna .ovpn-fil endrar ingenting for denne instansen.

Tre skriveverna kommandoar svarar på det meste. Den første skriv ut unit og eventuelle drop-ins, den andre identiteten og sandkasseinnstillingane som bind prosessen, og den tredje kva den siste oppstarten faktisk klaga over. Bruk instansnamnet som finst på verten:

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

Ver merksam på ProtectHome og på dei eigne innstillingane til profilen user, group og chroot. Ei fil under ein heimkatalog kan vere lesbar i skalet ditt og usynleg inne i tenesta når heimkatalogar blir gøymde. Kontoen systemd startar med er ikkje alltid kontoen som til slutt opnar nøkkelen.

Prov at køyretidsidentiteten kan opne begge filene

Å lese modusen er ikkje nok, fordi kvar katalog på stien må kunne gjennomgåast av same identitet. Gå stien gjennom komponent for komponent, og test deretter opninga som kontoen prosessen brukar. Ei fil med modus 600 eigd av root verkar berre medan prosessen framleis er root, noko som ikkje stemmer etter rettigheitsnedgangen mange profilar gjer. To kommandoar dekkjer gjennomgangen og opninga:

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 skriv ut modusen til kvar komponent og feilar der kontoen ikkje kan gå gjennom; den andre svarar på det einaste viktige spørsmålet, nemleg om køyretidsidentiteten kan opne fila for lesing. Ingen av dei skriv ut filinnhald, og det er poenget når fila held ein passfrase. Gjenta testen for innloggingsfila, fordi dei to ofte blir lagra med ulikt eigarskap.

Viss prosessen brukar ein chroot eller eit avgrensa namespace, køyr den same testen innanfrå den visninga, elles skildrar svaret feil filsystem. Ein passfrase lagra under ein gøymd heimkatalog er det vanlege dømet på ein test som går gjennom utanfor unit og feilar inni han.

Kontroller den første oppstarten, deretter ei gjenoppkobling

Start instansen éin gong og les den første feilen i staden for den siste. Ei manglande inndatafil, ei mislykka nøkkeldekr yptering og ein AUTH_FAILED frå serveren er tre ulike hendingar med tre ulike reparasjonar. Å rette ei tilgangsåtvaring provar ingenting om korvidt nøkkelen vart låst opp.

Journal-linja fortel kva av dei tre du har. Reparasjonen følgjer av kva inndata som feila:

Test deretter livssyklusen du faktisk treng: ein oppstart ved boot og kvar støtta gjenoppkobling, ikkje berre ein manuell oppstart frå skalet ditt. Med auth-nocache blir inndataa kasta etter første bruk, så ei seinare gjenoppkobling treng framleis ei lesbar kjelde. Ein nøkkelring som blir låst opp ved skrivebordsinnlogging er ikkje tilgjengeleg for ei teneste som starta før nokon logga inn, og det er den vanlege grunnen til at ein manuell test går gjennom og ein omstart feilar. Viss den første oppstarten lukkast og ei seinare gjenoppkobling feilar, les journalen for gjenoppkoblingshendinga før du endrar tilgangar igjen.

Å lagre passfrasen ved sida av nøkkelen reduserer kva krypteringa gir deg, så avgrens den fila og tryggleikskopiane. Handsame fjerning av passfrasen til nøkkelen som ei eiga legitimasjonsavgjerd i staden for reparasjonen for ei manglande inndata. Ei utrulling som er avhengig av menneskeleg godkjenning eller interaktiv MFA treng sin støtta agent eller administrasjonsintegrasjon; ein permanent lagra eingongskode er ikkje ein likeverdig erstatning.