Corrección: OpenVPN non puido ler o nome de usuario de Auth desde a entrada estándar

could not read Auth username from stdin parece un problema de autenticación e non o é. OpenVPN intentou pedir o nome de usuario pola entrada estándar, non atopou nada lexible e detívose antes de chegar a contactar co servidor. A conta pode ser perfectamente válida; simplemente o proceso non ten a quen preguntar.

Por iso o primeiro paso útil é confirmar que está a ler o cliente, non reintentar a conexión nin cambiar axustes do lado do servidor. Percorra as comprobacións seguintes en orde e detéñase na primeira que falle.

Lea o erro como un fallo local de entrada

Cando auth-user-pass aparece sen un argumento de ficheiro, o cliente espera preguntar. Nunha shell interactiva esa pregunta funciona porque o proceso posúe un terminal. Baixo systemd, unha tarefa cron ou un contedor, a entrada estándar adoita estar baleira e a lectura regresa de inmediato co erro que está a ver.

A mensaxe tamén nomea o campo que fallou, nome de usuario ou contrasinal, o que indica ata onde chegou a lectura. Que falte o nome de usuario significa que o proceso non puido ler nada de todo. Que falte o contrasinal tras un nome de usuario correcto significa que o fluxo de entrada rematou entre as dúas lecturas, algo típico dun ficheiro escrito á metade ou dunha tubaxe que se pechou.

Confirme a visión do propio cliente antes de cambiar calquera outra cousa. Execúteo en primeiro plano coa mesma configuración e o mesmo usuario, e observe se aparece a petición. Se aparece na súa shell pero non baixo o xestor de servizos, a diferenza está na fonte de entrada, non nas credenciais. Unha comparación rápida do ficheiro de unidade e do ambiente da súa shell adoita mostrar cal dos dous fornece un terminal.

Dea ao servizo unha fonte de credenciais compatible

A fonte compatible para o funcionamento sen supervisión é un ficheiro de credenciais pasado como argumento a auth-user-pass. O ficheiro lese como texto simple: a primeira liña é o nome de usuario e a segunda é o contrasinal. Apunte a el cunha ruta absoluta como /etc/openvpn/client/creds , para que o directorio de traballo da conta de servizo non poida cambiar o significado da directiva.

Os permisos importan tanto como a ruta. O ficheiro debe ser lexible pola conta que executa o cliente e non por todos os demais, e debería pertencer á conta de servizo ou a root cun grupo que inclúa o servizo. Comprobe a lexibilidade como esa conta, sen imprimir o contido.

Unha ruta relativa é o modo de fallo silencioso. O perfil pode estar nun directorio mentres systemd inicia o proceso noutro, así que un ficheiro que se resolve na súa shell non se resolve para o servizo. Mova as credenciais a unha localización fixa e faga referencia absoluta a elas. Despois inicie o servizo unha vez e confirme que se usa a mesma ruta, en lugar de confiar na vista do editor de perfís.

Se o despregamento esixe un código dun só uso ou outro desafío interactivo, decida se o fluxo de traballo do cliente realmente o admite sen supervisión. Un ficheiro cun contrasinal estático non pode responder a un código rotatorio, e reintentar unha petición que non se pode responder non achega información.

Por que script-security non axudará

script-security controla se o cliente pode executar scripts e canto pode pasarlle, incluído se se pode entregar un contrasinal a un script mediante unha variable de ambiente. Non di nada sobre de onde veñen o nome de usuario e o contrasinal.

Subilo a un nivel superior é un reflexo habitual porque a mensaxe menciona Auth, pero cambia os permisos dos scripts en lugar da fonte de entrada, e amplía o que o cliente pode executar. Se un script auxiliar forma parte do deseño, corrixa primeiro a fonte de entrada e manteña o nivel de seguridade no valor máis baixo que necesite o despregamento.

A interface de xestión é unha alternativa lexítima. Un frontend pode conectarse a ela, recibir a petición de credenciais e responder co nome de usuario e o contrasinal, que é como funcionan algúns GUI. Se a usa, vincúlea a un enderezo local, protéxaa cun ficheiro de contrasinal de xestión e restrinxa quen pode conectarse, porque é unha canle de control do cliente.

Verifique a seguinte etapa despois de que o cliente lea o ficheiro

Unha vez que o cliente pode ler as credenciais, o seguinte fallo é un intercambio real co servidor, e a súa mensaxe ten outro significado. Un fallo de autenticación nesa etapa significa que o servidor rexeitou a conta; unha resposta de desafío significa que o servidor quere outro factor. Tráteos como problemas novos en lugar de como o mesmo repetido.

Probe toda a ruta tal como a executará o servizo: mesma conta, mesmo directorio de traballo, mesmo ambiente de unidade. Unha conexión que só funciona cando se inicia desde a súa shell é sinal de que unha variable de ambiente ou un terminal segue formando parte do fluxo.

Despois garde os segredos onde corresponden. Os contrasinais nos argumentos de liña de ordes aparecen na táboa de procesos, e os contrasinais na saída de depuración acaban nos tíckets. Use un ficheiro protexido ou a interface de xestión, manteña os rexistros nun nivel que non repita credenciais e rote o ficheiro cando se vaia calquera con acceso.

Lista de comprobación: ruta absoluta de credenciais, lexible como conta de servizo, sen necesidade de terminal, script-security no seu mínimo, interface de xestión só se está vinculada e autenticada, e a resposta do servidor resultante tratada como un evento aparte.