ProtectHome mot eit TOTP-frø: kvifor VPN-pålogginga feilar

Autentiseringsappen viser ein fersk sekssifra kode, VPN avviser han, og den same koden verifiserer fint når du testar han frå di eiga skal. Det gapet er heile historia. Ein PAM-modul som ikkje kan opne registreringsløyndomen, returnerer ein feil som ser identisk ut med ein feil kode, og tenestemiljøet som skjuler heimekatalogar er ei vanleg årsak. Før du lempar på noka løyve, må du avgjere kva av tre situasjonar du er i.

Kva av tre feil er dette?

Den første er ein løyndom modulen ikkje kan lese i det heile. Den andre er ein løyndom han kan lese, men ikkje oppdatere. Den tredje er ein kode som verkeleg er feil, vanlegvis på grunn av klokkedrift eller ein gjenbrukt verdi.

Skil dei ved å lese tenesteloggen og systemets autentiseringslogg for eitt mislykka forsøk, og stadfest deretter kva PAM-teneste innstikket lastar og kva modullinje den tenesta brukar. Ein generisk autentiseringsfeil skil dei ikkje, og ein vellukka manuell test gjer det heller ikkje, fordi skalet ditt ikkje er tenestemiljøet.

Filsystemvisinga til eininga er den vanlege skuldige når berre tenesta feilar.

systemctl show -p ProtectHome -p ProtectSystem -p ReadWritePaths [email protected]
ls -l /var/lib/vpn-otp/*/.google_authenticator 2>/dev/null | head -n 20

Alternativ A: flytt løyndomen ut av heimen

Når tenesta skjuler /home og du heller vil behalde den vernet, lagre løyndomen på ein stad der ho kan sjå han. Modulen godtek ein secret=-sti og ein user=-konto som utfører filoperasjonane, noko som lèt eit sentralt lager tene mange identitetar.

Dette er det ryddige alternativet, og det er det som treng mest omhu, fordi eit delt lager gjer éin katalog til sikkerheitsgrensa for kvar konto.

auth required pam_google_authenticator.so secret=/var/lib/vpn-otp/${USER}/.google_authenticator user=vpn-otp

Sjekk tre ting før du stolar på det: kontoen finst, arbeidsprosessen til modulen kan byte til han, og filene er hans med restriktive modusar. Ikkje bruk ~ eller ein sti med heimevariabel saman med user=, og ikkje slå av eigarskapskontrollane til modulen for å få ein sti til å verke. Hald passordfasen og resten av stakken intakt.

Alternativ B: lat fila liggje og opne ein sti

Viss løyndomen må bli i heimekatalogen til brukaren, treng eininga ei vising som inkluderer den eine katalogen utan å eksponere alle heimekatalogar på verten. Eit drop-in kan leggje til ein smalt avgrensa bind-mount under ein sandkasse-heim.

Dette held eigarskap per brukar som modell, på kostnad av ei einingendring som må gjennomgåast kvar gong sandkassen endrar seg.

To grenser er lette å oversjå. Ein skriveverna sti lagt til under ein katalog sandkassen skjuler, eksponerer han ikkje, fordi forelderen rett og slett ikkje er der. Og mountet må vere skrivbart viss modulen må oppdatere tilstand, noko som bringar det neste alternativet i spel. Skriv drop-in som ei separat fil i staden for å redigere den pakka eininga under /usr/lib, slik at ei pakkeoppgradering ikkje stille angrar det.

Alternativ C: behald sandkassen og fiks tilstandsskrivingar

Å lese løyndomen er berre halve autentiseringa. Modulen kan skrive om informasjon om tidsforskyving, gjenoppspelingsvern eller ein teljar, og ei fil som består lesekontrollen kan framleis feile på skrivinga.

Den feilen ser ut som ein dårleg kode ved neste forsøk i staden for ved dette, og difor blir han forveksla med klokkedrift.

Gi han sin eigen skrivbare katalog og peik løyndomsstien dit, i staden for å gjere heile heimekatalogen skrivbar. Stadfest eigaren av katalogen, den ledige plassen i filsystemet og om eininga avgrensar skrivingar andre stader. Test deretter to påfølgjande påloggingar, fordi den andre provar skrivestien og den første berre lesinga.

Stadfest som tenesta, ikkje som deg sjølv

Kvar kontroll som betyr noko, må køyre inne i sandkassen til eininga med identiteten til eininga.

Ein kommando som lukkast som root, fortel deg at fila finst og ingenting anna. Ei pålogging gjennom den faktiske tenesta fortel deg om modulen kan lese løyndomen, bruke han og skrive tilbake det han treng.

Til slutt, hald kravet intakt. Å leggje til eit nullpassord-alternativ, godta skriveverna feil eller fjerne sandkassen ville alle få symptomet til å forsvinne ved å endre policyen. Ein brukar som må leggje fram ein kode, skal framleis bli avvist når løyndomen er utilgjengeleg.