El servicio de OpenVPN se detiene al pedir la contraseña de la clave privada: cómo arreglarlo

OpenVPN pide la contraseña de la clave privada en la máquina local, así que un archivo de inicio de sesión que funciona nunca la responde. En un servicio no hay terminal donde escribir, y el arranque o se cuelga o falla con una entrada del registro que nombra la entrada y no la causa. Hay dos secretos y cada uno necesita su propia fuente legible antes de reiniciar la unidad. El recorrido de abajo los separa y luego comprueba la identidad que realmente abre cada archivo.

Distinga las dos peticiones

La contraseña de la clave descifra la clave privada local; las credenciales de la cuenta autentican la sesión con el servidor. Vienen de lugares distintos, fallan en momentos distintos y dan mensajes distintos. Confundirlas lleva a buscar un restablecimiento de contraseña cuando la cuenta no tenía nada que ver. Lea el texto de la petición antes de cambiar cualquier opción, porque la redacción es la única pista fiable de qué secreto falta.

En Community OpenVPN 2.x, askpass nombra un archivo que guarda la contraseña de la clave en su primera línea, y auth-user-pass nombra un archivo con el nombre de usuario en una línea y la contraseña en la siguiente. Ninguno de los dos archivos satisface la otra opción. Una aplicación de escritorio o un perfil de NetworkManager pueden guardar ambos en su propio almacén de secretos, que un cliente de línea de órdenes nunca lee, así que anote qué cliente está configurando antes de escribir cualquier ruta.

Apunte ambas opciones a archivos legibles

Un perfil que necesita las dos entradas acaba con tres referencias de archivo: la clave cifrada, la contraseña que la desbloquea y el par de inicio de sesión. Añádalas sin tocar la CA ni las comprobaciones de identidad, porque estas deciden quién es el servidor y no forman parte de este problema. Si el despliegue no usa credenciales de cuenta en absoluto, añadir auth-user-pass crea una entrada que nadie puede proporcionar.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Las opciones sin argumento se comportan distinto de las opciones con ruta, y la diferencia importa en un servicio. Una askpass sin argumento sigue leyendo la consola, y un archivo auth-user-pass con solo un nombre de usuario sigue dejando una petición de contraseña esperando. En cuanto el cliente pasa a demonio no puede pedir entrada al terminal, así que un servicio configurado así no arranca.

Las rutas absolutas eliminan la cuestión del directorio de trabajo, pero no conceden acceso. La propiedad, el modo y el recorrido vienen después, y los tres se comprueban contra la cuenta con la que se ejecuta el proceso.

Lea la configuración de la unidad antes que el perfil

La unidad, no el archivo que estaba editando, decide qué configuración carga la instancia. Lea su línea de órdenes y cualquier drop-in, y luego siga el directorio de trabajo hasta el perfil que realmente se usa. Una referencia de contraseña añadida a otro archivo .ovpn no cambia nada para esta instancia.

Tres órdenes de solo lectura responden a la mayor parte. La primera imprime la unidad y cualquier drop-in, la segunda imprime la identidad y los ajustes de sandbox que limitan el proceso, y la tercera imprime de qué se quejó realmente el último arranque. Use el nombre de instancia que exista en el host:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Fíjese en ProtectHome y en las opciones propias del perfil user, group y chroot. Un archivo bajo un directorio personal puede ser legible en su shell e invisible dentro del servicio cuando se ocultan los directorios personales. La cuenta con la que arranca systemd no siempre es la cuenta que acaba abriendo la clave.

Demuestre que la identidad de ejecución puede abrir ambos archivos

Leer el modo no basta, porque cada directorio de la ruta debe ser atravesable por la misma identidad. Recorra la ruta componente a componente y luego pruebe la apertura como la cuenta que usa el proceso. Un archivo con modo 600 propiedad de root solo funciona mientras el proceso sigue siendo root, lo que no es cierto tras la bajada de privilegios que hacen muchos perfiles. Dos órdenes cubren el recorrido y la apertura:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

La primera orden imprime el modo de cada componente y falla donde la cuenta no puede atravesar; la segunda responde a la única pregunta importante: si la identidad de ejecución puede abrir el archivo para lectura. Ninguna imprime el contenido del archivo, que es justo lo que se busca cuando el archivo guarda una contraseña. Repita la prueba para el archivo de inicio de sesión, porque los dos suelen guardarse con propietarios distintos.

Si el proceso usa un chroot o un namespace restringido, ejecute la misma prueba desde dentro de esa vista, o la respuesta describe el sistema de archivos equivocado. Una contraseña guardada bajo un directorio personal oculto es el ejemplo habitual de prueba que pasa fuera de la unidad y falla dentro.

Compruebe el primer arranque y luego una reconexión

Arranque la instancia una vez y lea el primer fallo, no el último. Un archivo de entrada ausente, un descifrado de clave fallido y un AUTH_FAILED del servidor son tres sucesos distintos con tres reparaciones distintas. Arreglar un aviso de permisos no demuestra nada sobre si la clave se desbloqueó.

La línea del registro dice cuál de los tres tiene. La reparación se deduce de qué entrada falló:

Después pruebe el ciclo de vida que realmente necesita: un arranque en el boot y cualquier reconexión admitida, no solo un arranque manual desde su shell. Con auth-nocache las entradas se descartan tras el primer uso, así que una reconexión posterior sigue necesitando una fuente legible. Un llavero desbloqueado al iniciar sesión en el escritorio no está disponible para un servicio que arrancó antes de que nadie iniciara sesión, y esa es la razón habitual por la que una prueba manual pasa y un reinicio falla. Si el primer arranque tiene éxito y una reconexión posterior falla, lea el registro del evento de reconexión antes de volver a cambiar permisos.

Guardar la contraseña junto a la clave reduce lo que aporta el cifrado, así que restrinja ese archivo y sus copias. Trate quitar la contraseña de la clave como una decisión de credenciales aparte, no como la reparación de una entrada ausente. Un despliegue que depende de aprobación humana o MFA interactiva necesita su agente o integración de gestión compatible; un código de un solo uso guardado de forma permanente no es un sustituto equivalente.