Solución: OpenVPN no pudo leer el nombre de usuario de Auth desde la entrada estándar

could not read Auth username from stdin parece un problema de autenticación y no lo es. OpenVPN intentó pedir el nombre de usuario por la entrada estándar, no encontró nada legible y se detuvo antes de llegar a contactar con el servidor. La cuenta puede ser perfectamente válida; simplemente el proceso no tiene a quién preguntar.

Por eso el primer paso útil es confirmar qué está leyendo el cliente, no reintentar la conexión ni cambiar ajustes del lado del servidor. Recorra las comprobaciones siguientes en orden y deténgase en la primera que falle.

Lea el error como un fallo local de entrada

Cuando auth-user-pass aparece sin un argumento de archivo, el cliente espera preguntar. En un shell interactivo esa pregunta funciona porque el proceso posee un terminal. Bajo systemd, una tarea cron o un contenedor, la entrada estándar suele estar vacía y la lectura regresa de inmediato con el error que está viendo.

El mensaje también nombra el campo que falló, nombre de usuario o contraseña, lo que indica hasta dónde llegó la lectura. Que falte el nombre de usuario significa que el proceso no pudo leer nada en absoluto. Que falte la contraseña tras un nombre de usuario correcto significa que el flujo de entrada terminó entre las dos lecturas, algo típico de un archivo escrito a medias o de una tubería que se cerró.

Confirme la visión del propio cliente antes de cambiar cualquier otra cosa. Ejecútelo en primer plano con la misma configuración y el mismo usuario, y observe si aparece la petición. Si aparece en su shell pero no bajo el gestor de servicios, la diferencia está en la fuente de entrada, no en las credenciales. Una comparación rápida del archivo de unidad y de su entorno de shell suele mostrar cuál de los dos aporta un terminal.

Dé al servicio una fuente de credenciales compatible

La fuente compatible para el funcionamiento sin supervisión es un archivo de credenciales pasado como argumento a auth-user-pass. El archivo se lee como texto plano: la primera línea es el nombre de usuario y la segunda es la contraseña. Apunte a él con una ruta absoluta como /etc/openvpn/client/creds , para que el directorio de trabajo de la cuenta de servicio no pueda cambiar el significado de la directiva.

Los permisos importan tanto como la ruta. El archivo debe ser legible por la cuenta que ejecuta el cliente y no por todos los demás, y debería pertenecer a la cuenta de servicio o a root con un grupo que incluya el servicio. Compruebe la legibilidad como esa cuenta, sin imprimir el contenido.

Una ruta relativa es el modo de fallo silencioso. El perfil puede estar en un directorio mientras systemd inicia el proceso en otro, así que un archivo que se resuelve en su shell no se resuelve para el servicio. Mueva las credenciales a una ubicación fija y haga referencia absoluta a ellas. Después inicie el servicio una vez y confirme que se usa la misma ruta, en lugar de fiarse de la vista del editor de perfiles.

Si el despliegue exige un código de un solo uso u otro desafío interactivo, decida si el flujo de trabajo del cliente realmente lo admite sin supervisión. Un archivo con una contraseña estática no puede responder a un código rotatorio, y reintentar una petición que no se puede responder no aporta información.

Por qué script-security no ayudará

script-security controla si el cliente puede ejecutar scripts y cuánto puede pasarles, incluido si se puede entregar una contraseña a un script mediante una variable de entorno. No dice nada sobre de dónde vienen el nombre de usuario y la contraseña.

Subirlo a un nivel superior es un reflejo habitual porque el mensaje menciona Auth, pero cambia los permisos de los scripts en lugar de la fuente de entrada, y amplía lo que el cliente puede ejecutar. Si un script auxiliar forma parte del diseño, corrija primero la fuente de entrada y mantenga el nivel de seguridad en el valor más bajo que necesite el despliegue.

La interfaz de gestión es una alternativa legítima. Un frontend puede conectarse a ella, recibir la petición de credenciales y responder con el nombre de usuario y la contraseña, que es como funcionan algunos GUI. Si la usa, vínculela a una dirección local, protéjala con un archivo de contraseña de gestión y restrinja quién puede conectarse, porque es un canal de control del cliente.

Verifique la siguiente etapa después de que el cliente lea el archivo

Una vez que el cliente puede leer las credenciales, el siguiente fallo es un intercambio real con el servidor, y su mensaje tiene otro significado. Un fallo de autenticación en esa etapa significa que el servidor rechazó la cuenta; una respuesta de desafío significa que el servidor quiere otro factor. Trátelos como problemas nuevos en lugar de como el mismo repetido.

Pruebe toda la ruta tal como la ejecutará el servicio: misma cuenta, mismo directorio de trabajo, mismo entorno de unidad. Una conexión que solo funciona cuando se inicia desde su shell es señal de que una variable de entorno o un terminal sigue formando parte del flujo.

Luego guarde los secretos donde corresponde. Las contraseñas en argumentos de línea de comandos aparecen en la tabla de procesos, y las contraseñas en la salida de depuración acaban en los tickets. Use un archivo protegido o la interfaz de gestión, mantenga los registros en un nivel que no repita credenciales y rote el archivo cuando se marche cualquiera con acceso.

Lista de comprobación: ruta absoluta de credenciales, legible como cuenta de servicio, sin necesidad de terminal, script-security en su mínimo, interfaz de gestión solo si está vinculada y autenticada, y la respuesta del servidor resultante tratada como un evento aparte.