Storitev OpenVPN se ustavi pri zahtevi za geslo zasebnega ključa: kako to popraviti

OpenVPN zahteva geslo zasebnega ključa na lokalnem računalniku, zato delujoča prijavna datoteka nanj nikoli ne odgovori. V storitvi ni terminala za vpis, zagon pa se bodisi obesi bodisi spodleti z vnosom v journalu, ki imenuje vhod in ne vzroka. V igri sta dve skrivnosti in vsaka potrebuje svoj berljiv vir pred ponovnim zagonom unita. Spodnji potek ju loči in nato preveri identiteto, ki dejansko odpre vsako datoteko.

Ločite oba poziva

Geslo ključa dešifrira lokalni zasebni ključ; podatki računa overjajo sejo pri strežniku. Prihajajo z različnih mest, spodletijo v različnih trenutkih in dajejo različna sporočila. Njihova zamenjava pošlje ljudi iskati ponastavitev gesla, čeprav račun sploh ni bil udeležen. Preberite besedilo poziva, preden spremenite katero koli možnost, ker je formulacija edina zanesljiva namig, katera skrivnost manjka.

V Community OpenVPN 2.x askpass označuje datoteko, ki hrani geslo ključa v prvi vrstici, auth-user-pass pa datoteko z uporabniškim imenom v eni vrstici in geslom v naslednji. Nobena datoteka ne zadovolji druge možnosti. Namizna aplikacija ali profil NetworkManagerja lahko oba hrani v svojem shrambi skrivnosti, ki ga odjemalec iz ukazne vrstice nikoli ne bere, zato zabeležite, katerega odjemalca nastavljate, preden napišete katero koli pot.

Usmerite obe možnosti na berljive datoteke

Profil, ki potrebuje oba vhoda, na koncu dobi tri sklice na datoteke: šifriran ključ, geslo, ki ga odklene, in prijavni par. Dodajte jih, ne da bi se dotaknili CA ali preverjanj identitete, ker ta odločajo, kdo je strežnik, in niso del te težave. Če uvedba sploh ne uporablja podatkov računa, auth-user-pass ustvari vhod, ki ga nihče ne more zagotoviti.

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

Možnosti brez argumenta se obnašajo drugače kot možnosti s potjo, in v storitvi je ta razlika pomembna. askpass brez argumenta še vedno bere konzolo, datoteka auth-user-pass samo z uporabniškim imenom pa še vedno pušča zahtevo za geslo v čakanju. Ko odjemalec postane demon, od terminala sploh ne more več zahtevati vhoda, zato se tako nastavljena storitev ne zažene.

Absolutne poti odstranijo vprašanje delovnega imenika, ne dajo pa dostopa. Sledijo lastništvo, način in prehod, vsi trije pa se preverjajo glede na račun, pod katerim teče proces.

Preberite konfiguracijo unita pred profilom

Katero konfiguracijo naloži instanca, odloča unit, ne datoteka, ki ste jo urejali. Preberite njegovo ukazno vrstico in vse drop-in, nato sledite delovnemu imeniku do profila, ki se dejansko uporablja. Sklicevanje na geslo, dodano v drugo datoteko .ovpn, za to instanco ne spremeni ničesar.

Trije ukazi samo za branje odgovorijo na večino. Prvi izpiše unit in vse drop-in, drugi identiteto in nastavitve peskovnika, ki omejujejo proces, tretji pa, na kaj se je zadnji zagon dejansko pritožil. Uporabite ime instance, ki na gostitelju obstaja:

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

Bodite pozorni na ProtectHome in na lastne možnosti profila user, group in chroot. Datoteka v domačem imeniku je lahko v vaši lupini berljiva in znotraj storitve nevidna, ko se domači imeniki skrijejo. Račun, s katerim se zažene systemd, ni vedno račun, ki na koncu odpre ključ.

Dokažite, da lahko izvajalna identiteta odpre obe datoteki

Branje načina ni dovolj, ker mora biti vsak imenik na poti prehoden za isto identiteto. Prehodite pot komponento za komponento in nato preizkusite odpiranje kot račun, ki ga uporablja proces. Datoteka z načinom 600 v lasti roota deluje le, dokler je proces še root, kar po znižanju pravic, ki ga izvaja veliko profilov, ne velja več. Dva ukaza pokrivata prehod in odpiranje:

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

Prvi ukaz izpiše način vsake komponente in spodleti tam, kjer račun ne more prehoditi; drugi odgovori na edino pomembno vprašanje, ali lahko izvajalna identiteta datoteko odpre za branje. Noben ne izpiše vsebine datoteke, in prav to je bistvo, ko datoteka hrani geslo. Test ponovite za prijavno datoteko, ker se obe pogosto shranjujeta z različnim lastnikom.

Če proces uporablja chroot ali omejen namespace, zaženite isti test znotraj tega pogleda, sicer odgovor opisuje napačen datotečni sistem. Geslo, shranjeno pod skritim domačim imenikom, je običajen primer testa, ki uspe zunaj unita in spodleti znotraj njega.

Preverite prvi zagon, nato ponovno povezavo

Zaženite instanco enkrat in berite prvo napako, ne zadnje. Manjkajoča vhodna datoteka, neuspešno dešifriranje ključa in AUTH_FAILED s strežnika so trije različni dogodki s tremi različnimi popravki. Popravljanje opozorila o dovoljenjih ne dokaže ničesar o tem, ali je bil ključ odklenjen.

Vrstica v journalu pove, kateri od treh. Popravek sledi iz tega, kateri vhod je spodletel:

Nato preizkusite življenjski cikel, ki ga res potrebujete: zagon ob zagonu sistema in vsako podprto ponovno povezavo, ne le ročni zagon iz vaše lupine. Z auth-nocache se vhodi po prvi uporabi zavržejo, zato poznejša ponovna povezava še vedno potrebuje berljiv vir. Obroček ključev, odklenjen ob prijavi v namizje, ni na voljo storitvi, ki se je zagnala, preden se je kdo prijavil, in to je običajen razlog, da ročni test uspe, ponovni zagon pa spodleti. Če prvi zagon uspe in poznejša ponovna povezava spodleti, preberite journal za dogodek ponovne povezave, preden znova spremenite dovoljenja.

Shranjevanje gesla ob ključu zmanjša, kar vam daje šifriranje, zato omejite to datoteko in njene varnostne kopije. Odstranitev gesla ključa obravnavajte kot ločeno odločitev o poverilnicah, ne kot popravek manjkajočega vhoda. Uvedba, ki je odvisna od človeške odobritve ali interaktivne MFA, potrebuje podprtega agenta ali integracijo upravljanja; trajno shranjen enkratni kod ni enakovredna zamenjava.