ProtectHome kontra en TOTP-seed: hvorfor VPN-loginet fejler

Autentificeringsappen viser en frisk sekscifret kode, VPN afviser den, og den samme kode verificeres fint, når du tester fra din egen shell. Det gab er hele historien. Et PAM-modul, der ikke kan åbne tilmeldingshemmeligheden, returnerer en fejl, der ser identisk ud med en forkert kode, og det servicemiljø, der skjuler hjemmebiblioteker, er en almindelig årsag. Beslut, hvilken af tre situationer du er i, før du lemper på en tilladelse.

Hvilken af tre fejl er det?

Den første er en hemmelighed, som modulet slet ikke kan læse. Den anden er en hemmelighed, det kan læse, men ikke opdatere. Den tredje er en kode, der virkelig er forkert, oftest på grund af urdrift eller en genbrugt værdi.

Adskil dem ved at læse servicejournalen og systemets godkendelseslog for ét mislykket forsøg, og bekræft derefter, hvilken PAM-tjeneste plugin'et indlæser, og hvilken modullinje den tjeneste bruger. En generisk godkendelsesfejl skelner dem ikke, og en vellykket manuel test gør heller ikke, fordi din shell ikke er tjenestens miljø.

Unitens filsystemvisning er den sædvanlige synder, når kun tjenesten fejler.

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

Mulighed A: flyt hemmeligheden ud af hjemmet

Når tjenesten skjuler /home, og du hellere vil beholde den beskyttelse, skal du opbevare hemmeligheden et sted, den kan se. Modulet accepterer en secret=-sti og en user=-konto, der udfører filoperationerne, hvilket lader et centralt lager betjene mange identiteter.

Dette er den pæne mulighed, og den kræver mest omhu, fordi et delt lager gør ét bibliotek til sikkerhedsgrænsen for hver konto.

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

Kontrollér tre ting, før du stoler på det: kontoen findes, modulets arbejdsproces kan skifte til den, og filerne ejes af den med stramme tilstande. Brug ikke ~ eller en sti med hjemvariabel sammen med user=, og deaktiver ikke modulets ejerskabskontroller for at få en sti til at virke. Hold adgangskodefasen og resten af stakken intakt.

Mulighed B: lad filen blive og åbn en sti

Hvis hemmeligheden skal blive i brugerens hjemmebibliotek, har uniten brug for en visning, der omfatter netop det bibliotek uden at blotte alle hjemmebiblioteker på værten. Et drop-in kan tilføje et snævert afgrænset bind-mount under et sandkasse-hjem.

Det bevarer ejerskab per bruger som model, på bekostning af en unitændring, der skal gennemgås, hver gang sandkassen ændres.

To grænser er lette at overse. En skrivebeskyttet sti, der tilføjes under et bibliotek, som sandkassen skjuler, afslører det ikke, fordi forælderen simpelthen ikke er der. Og mountet skal være skrivbart, hvis modulet skal opdatere tilstand, hvilket bringer den næste mulighed i spil. Skriv drop-in som en separat fil i stedet for at redigere den pakkede unit under /usr/lib, så en pakkeopgradering ikke stiltiende fortryder det.

Mulighed C: behold sandkassen og ret tilstandsskrivninger

At læse hemmeligheden er kun halvdelen af godkendelsen. Modulet kan genskrive tidsforskydningsinformation, genafspilningsbeskyttelse eller en tæller, og en fil, der består læsekontrollen, kan stadig fejle skrivningen.

Den fejl ligner en dårlig kode ved næste forsøg i stedet for ved dette, og derfor forveksles den med urdrift.

Giv den sit eget skrivbare bibliotek, og peg hemmelighedens sti derhen i stedet for at gøre hele hjemmebiblioteket skrivbart. Bekræft bibliotekets ejer, filsystemets ledige plads og om uniten begrænser skrivninger andre steder. Test derefter to på hinanden følgende logins, fordi det andet beviser skrivestien, og det første kun beviser læsningen.

Verificér som tjenesten, ikke som dig selv

Hver kontrol, der betyder noget, skal køre inde i unitens sandkasse med unitens identitet.

En kommando, der lykkes som root, fortæller dig, at filen findes, og intet andet. Et login gennem den faktiske tjeneste fortæller dig, om modulet kan læse hemmeligheden, bruge den og skrive tilbage, hvad det har brug for.

Til sidst skal du holde kravet intakt. At tilføje en nulpunktsadgangskode, acceptere skrivebeskyttede fejl eller fjerne sandkassen ville alle få symptomet til at forsvinde ved at ændre politikken. En bruger, der skal fremvise en kode, skal stadig afvises, når hemmeligheden er utilgængelig.