ProtectHome contra una llavor TOTP: per què falla l’inici de sessió VPN

L’autenticador mostra un codi nou de sis xifres, la VPN el rebutja i el mateix codi es verifica correctament quan el proves des de la teva pròpia consola. Aquesta diferència és tota la història. Un mòdul PAM que no pot obrir el secret d’inscripció retorna un error que sembla idèntic a un codi incorrecte, i l’entorn del servei que amaga els directoris personals n’és una causa habitual. Abans d’afluixar cap permís, decideix en quina de les tres situacions et trobes.

Quin d’aquests tres errors és?

El primer és un secret que el mòdul no pot llegir de cap manera. El segon és un secret que pot llegir però no actualitzar. El tercer és un codi que realment és incorrecte, normalment per una desviació del rellotge o un valor repetit.

Separa’ls llegint el registre del servei i el registre d’autenticació del sistema per a un intent fallit, i després confirma quin servei PAM carrega el connector i quina línia de mòdul fa servir aquest servei. Un missatge genèric de fallada d’autenticació no els distingeix, ni tampoc una prova manual correcta, perquè la teva consola no és l’entorn del servei.

La visió del sistema de fitxers de la unitat és el culpable habitual quan només falla el servei.

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

Opció A: treu el secret del directori personal

Quan el servei amaga /home i prefereixes mantenir aquesta protecció, desa el secret en un lloc on el pugui veure. El mòdul accepta una ruta secret= i un compte user= que fa les operacions de fitxers, cosa que permet que un magatzem central serveixi moltes identitats.

Aquesta és l’opció ordenada, i és la que necessita més cura, perquè un magatzem compartit fa d’un sol directori la frontera de seguretat per a cada compte.

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

Comprova tres coses abans de confiar-hi: el compte existeix, el treballador del mòdul hi pot canviar i els fitxers són seus amb modes restrictius. No facis servir ~ ni una ruta amb variable personal juntament amb user=, i no desactivis les comprovacions de propietat del mòdul per fer que una ruta funcioni. Mantén l’etapa de contrasenya i la resta de la pila intactes.

Opció B: deixa el fitxer i obre una ruta

Si el secret ha de quedar-se al directori personal de l’usuari, la unitat necessita una visió que inclogui aquest sol directori sense exposar tots els directoris personals de l’amfitrió. Un drop-in pot afegir un muntatge d’enllaç molt limitat sota un directori personal aïllat.

Això manté la propietat per usuari com a model, a costa d’un canvi de la unitat que s’ha de revisar sempre que canviï la caixa de sorra.

Dos límits són fàcils de passar per alt. Una ruta de només lectura afegida sota un directori que la caixa de sorra amaga no l’exposa, perquè el pare simplement no hi és. I el muntatge ha de ser escribible si el mòdul ha d’actualitzar l’estat, cosa que posa en joc l’opció següent. Escriu el drop-in com un fitxer separat en lloc d’editar la unitat empaquetada sota /usr/lib, perquè una actualització del paquet no el desfaci en silenci.

Opció C: mantén la caixa de sorra i arregla les escriptures d’estat

Llegir el secret és només la meitat de l’autenticació. El mòdul pot reescriure informació de desviació horària, protecció contra repetició o un comptador, i un fitxer que passa la comprovació de lectura encara pot fallar en l’escriptura.

Aquesta fallada sembla un codi dolent en el següent intent i no en aquest, per això es confon amb una desviació del rellotge.

Dona-li un directori escribible propi i apunta-hi la ruta del secret, en lloc de fer escribible tot el directori personal. Confirma el propietari del directori, l’espai lliure del sistema de fitxers i si la unitat restringeix escriptures en altres llocs. Després prova dos inicis de sessió consecutius, perquè el segon demostra la ruta d’escriptura i el primer només demostra la lectura.

Verifica com el servei, no com tu mateix

Cada comprovació que importa s’ha d’executar dins de la caixa de sorra de la unitat amb la identitat de la unitat.

Una ordre que funciona com a root et diu que el fitxer existeix i res més. Un inici de sessió pel servei real et diu si el mòdul pot llegir el secret, fer-lo servir i tornar a escriure el que necessita.

Finalment, mantén el requisit intacte. Afegir una opció de contrasenya nul·la, acceptar fallades de només lectura o eliminar la caixa de sorra farien desaparèixer el símptoma canviant la política. Un usuari a qui s’exigeix presentar un codi encara ha de ser rebutjat quan el secret és inaccessible.