OpenVPN PAM: el argumento de inicio de sesión es un servicio, no un usuario

Se añadió un usuario en el servidor, la contraseña se escribió correctamente y la conexión sigue terminando con AUTH_FAILED. La línea del complemento suele explicar por qué: la palabra que sigue a la ruta del complemento es un nombre de servicio PAM, y decide qué pila de módulos responde a la pregunta. No es un nombre de usuario ni un puntero a un archivo de contraseñas que OpenVPN lee por sí mismo.

Qué selecciona la segunda palabra

La línea de configuración toma una ruta de complemento y un argumento:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

Ese argumento se pasa a la biblioteca PAM como nombre de servicio, lo que hace que se ejecute la pila de /etc/pam.d/openvpn. Si escribe login allí, obtiene en cambio la política de inicio de sesión interactiva, con los módulos que esa política incluya en su distribución.

Utilice la ruta del complemento que proporciona el paquete instalado, no una ruta copiada de otro host. El nombre del archivo y el directorio difieren entre distribuciones, y una ruta incorrecta falla al arrancar con un error de carga del complemento, no al autenticar.

Dónde lee realmente las cuentas la pila

PAM es un despachador. El archivo de servicio enumera los módulos en orden, y el primero que puede responder decide el resultado. Una pila que llama a pam_unix lee cuentas locales; una pila que llama a un módulo LDAP o RADIUS envía las credenciales a otro lugar por completo.

Lea el archivo al que resuelve el nombre de servicio, incluido todo lo que incluye:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

Si la pila delega en un directorio, añadir una cuenta local no cambia nada. Si lee cuentas locales, crear el usuario en el directorio tampoco cambia nada. La cuenta tiene que existir donde mira la pila, y ese es todo el diagnóstico en la mayoría de estos informes.

Un intento, dos registros

Correlacione una única conexión fallida en ambos lados. El registro de OpenVPN muestra el resultado del complemento y el rechazo del cliente; el registro de autenticación del sistema muestra qué módulo se ejecutó y qué decidió. Leerlos en la misma ventana temporal es lo que separa un archivo de servicio ausente de un tiempo de espera del backend. Un hueco en el registro de autenticación significa que la pila nunca se alcanzó.

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

Pruebe el servicio directamente con una utilidad que hable PAM, para no depurar la VPN y la pila al mismo tiempo. Una prueba directa correcta con el mismo nombre de servicio y cuenta reduce el problema a cómo el demonio pasa las credenciales, no a la cuenta.

pamtester openvpn alice authenticate

Si la prueba directa falla con las mismas credenciales que funcionan en una consola, la pila no lee el origen de cuentas que suponía. Si tiene éxito, mire la conversación que ejecuta el complemento y lo que el cliente envió realmente. Ejecútela también una vez con una contraseña deliberadamente incorrecta, para ver la diferencia entre un rechazo y un error de módulo. Esos dos resultados se ven idénticos en el registro de la VPN y completamente distintos aquí.

Un servicio dedicado supera a editar el inicio de sesión

Dé a la VPN su propio archivo de servicio cuando sus requisitos difieren del inicio de sesión interactivo, como suelen hacerlo. Editar login o common-auth cambia la política de todos los programas que los incluyen, y la próxima persona que depure un problema de inicio de sesión no relacionado heredará su cambio.

Copie los módulos que necesite en un archivo de servicio pequeño, mantenga el orden explícito y anote quién es su propietario. Ese archivo es lo que hay que revisar cuando un restablecimiento de contraseña parece no tener efecto.

Qué envía el cliente y qué no

El cliente proporciona un nombre de usuario y una contraseña mediante su solicitud o archivo compatible. El complemento del servidor pasa esos valores a la conversación PAM; no los lee de la configuración del servidor. Una línea del lado del servidor que parezca definir una contraseña no lo hace, y ninguna edición de perfil creará una cuenta.

El nombre de usuario y la contraseña pueden convivir con los certificados de cliente, y habilitar PAM no es motivo para dejar de verificar certificados. Mantenga las capas que el despliegue pretendía y corrija solo el origen de las cuentas.

La aceptación es bidireccional: la cuenta prevista tiene éxito, y una cuenta que debería rechazarse sigue fallando. El README del complemento auth-pam documenta el argumento de servicio y los backends que puede atender, y es el lugar para confirmar la disposición que intenta construir.