ProtectHome fronte a unha semente TOTP: por que falla o inicio de sesión VPN

O autenticador mostra un código novo de seis díxitos, a VPN rexéitao e o mesmo código verifícase sen problemas cando o proba desde o seu propio shell. Esa fenda é toda a historia. Un módulo PAM que non pode abrir o segredo de inscrición devolve un fallo que parece idéntico a un código incorrecto, e o contorno do servizo que oculta os directorios persoais é unha causa habitual. Antes de relaxar calquera permiso, decida en cal das tres situacións está.

Cal dos tres fallos é este?

O primeiro é un segredo que o módulo non pode ler en absoluto. O segundo é un segredo que pode ler pero non actualizar. O terceiro é un código que realmente é incorrecto, normalmente por deriva do reloxo ou un valor reutilizado.

Sepáreos lendo o diario do servizo e o rexistro de autenticación do sistema para un intento fallido, e despois confirme que servizo PAM carga o complemento e que liña de módulo usa ese servizo. Unha mensaxe xenérica de fallo de autenticación non os distingue, nin tampouco unha proba manual correcta, porque o seu shell non é o contorno do servizo.

A vista do sistema de ficheiros da unidade é o culpable habitual cando só falla o servizo.

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ón A: sacar o segredo do directorio persoal

Cando o servizo oculta /home e prefire conservar esa protección, garde o segredo nun lugar onde poida velo. O módulo acepta unha ruta secret= e unha conta user= que realiza as operacións de ficheiros, o que permite que un almacén central atenda moitas identidades.

Esta é a opción ordenada, e é a que necesita máis coidado, porque un almacén compartido converte un só directorio na fronteira de seguridade de cada conta.

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

Comprobe tres cousas antes de confiar nela: a conta existe, o traballador do módulo pode cambiar a ela e os ficheiros son seus con modos restritivos. Non use ~ nin unha ruta con variable persoal xunto con user=, e non desactive as comprobacións de propiedade do módulo para facer que unha ruta funcione. Manteña a etapa de contrasinal e o resto da pila intactos.

Opción B: deixar o ficheiro e abrir unha ruta

Se o segredo debe quedar no directorio persoal do usuario, a unidade necesita unha vista que inclúa ese único directorio sen expor todos os directorios persoais do host. Un drop-in pode engadir unha montaxe de enlace moi limitada baixo un directorio persoal illado.

Isto mantén a propiedade por usuario como modelo, a costa dun cambio na unidade que debe revisarse sempre que cambie o contorno illado.

Dous límites son fáciles de pasar por alto. Unha ruta de só lectura engadida baixo un directorio que o contorno illado oculta non o expón, porque o pai simplemente non está. E a montaxe debe ser escribible se o módulo ten que actualizar o estado, o que pon en xogo a seguinte opción. Escriba o drop-in como un ficheiro separado en lugar de editar a unidade empaquetada baixo /usr/lib, para que unha actualización do paquete non o desfaga en silencio.

Opción C: manter o contorno illado e corrixir as escrituras de estado

Ler o segredo é só a metade da autenticación. O módulo pode reescribir información de desviación horaria, protección contra repetición ou un contador, e un ficheiro que pasa a comprobación de lectura aínda pode fallar na escritura.

Ese fallo parece un código incorrecto no seguinte intento e non neste, por iso se confunde cunha deriva do reloxo.

Délle un directorio escribible propio e dirixa alí a ruta do segredo, en lugar de facer escribible todo o directorio persoal. Confirme o propietario do directorio, o espazo libre do sistema de ficheiros e se a unidade restrinxe escrituras noutros lugares. Despois probe dous inicios de sesión consecutivos, porque o segundo demostra a ruta de escritura e o primeiro só a de lectura.

Verifique como o servizo, non como vostede mesmo

Cada comprobación que importa debe executarse dentro do contorno illado da unidade coa identidade da unidade.

Un comando que ten éxito como root dille que o ficheiro existe e nada máis. Un inicio de sesión polo servizo real dille se o módulo pode ler o segredo, usalo e escribir de volta o que necesita.

Por último, manteña o requisito intacto. Engadir unha opción de contrasinal nulo, aceptar fallos de só lectura ou eliminar o contorno illado farían desaparecer o síntoma cambiando a política. Un usuario obrigado a presentar un código debe seguir sendo rexeitado cando o segredo é inalcanzable.