Correção: o OpenVPN não conseguiu ler o nome de usuário Auth da entrada padrão

could not read Auth username from stdin parece um problema de autenticação e não é. O OpenVPN tentou pedir o nome de usuário na entrada padrão, não encontrou nada legível e parou antes de sequer contactar o servidor. A conta pode ser perfeitamente válida; o processo simplesmente não tem a quem perguntar.

Por isso, o primeiro passo útil é confirmar o que o cliente está a ler, e não repetir a ligação nem alterar definições do lado do servidor. Percorra as verificações abaixo por ordem e pare na primeira que falhar.

Leia o erro como uma falha local de entrada

Quando auth-user-pass aparece sem um argumento de ficheiro, o cliente espera perguntar. Numa shell interativa esse pedido funciona porque o processo possui um terminal. Sob systemd, uma tarefa cron ou um contentor, a entrada padrão está normalmente vazia e a leitura regressa de imediato com o erro que está a ver.

A mensagem também indica o campo que falhou, nome de usuário ou palavra-passe, o que mostra até onde chegou a leitura. A falta do nome de usuário significa que o processo não conseguiu ler nada. A falta da palavra-passe depois de um nome de usuário bem-sucedido significa que o fluxo de entrada terminou entre as duas leituras, o que é típico de um ficheiro escrito pela metade ou de um pipe fechado.

Confirme a visão do próprio cliente antes de alterar mais alguma coisa. Execute-o em primeiro plano com a mesma configuração e o mesmo utilizador, e observe se o pedido aparece. Se aparecer na sua shell mas não sob o gestor de serviços, a diferença está na fonte de entrada, não nas credenciais. Uma comparação rápida do ficheiro unit e do ambiente da sua shell mostra normalmente qual dos dois fornece um terminal.

Dê ao serviço uma fonte de credenciais suportada

A fonte suportada para funcionamento sem supervisão é um ficheiro de credenciais passado como argumento a auth-user-pass. O ficheiro é lido como texto simples: a primeira linha é o nome de usuário e a segunda é a palavra-passe. Aponte para ele com um caminho absoluto como /etc/openvpn/client/creds , para que o diretório de trabalho da conta de serviço não possa alterar o significado da diretiva.

As permissões importam tanto como o caminho. O ficheiro tem de ser legível pela conta que executa o cliente e não por todos os outros, e deve pertencer à conta de serviço ou à root com um grupo que inclua o serviço. Verifique a legibilidade como essa conta, sem imprimir o conteúdo.

Um caminho relativo é o modo de falha silencioso. O perfil pode estar num diretório enquanto o systemd inicia o processo noutro, pelo que um ficheiro que se resolve na sua shell não se resolve para o serviço. Mova as credenciais para um local fixo e refira-as de forma absoluta. Depois inicie o serviço uma vez e confirme que o mesmo caminho é usado, em vez de confiar na vista do editor de perfis.

Se a implementação exigir um código de uso único ou outro desafio interativo, decida se o fluxo de trabalho do cliente realmente o suporta sem supervisão. Um ficheiro com uma palavra-passe estática não consegue responder a um código rotativo, e repetir um pedido sem resposta não acrescenta informação.

Porque o script-security não vai ajudar

script-security controla se o cliente pode executar scripts e quanto lhes pode passar, incluindo se uma palavra-passe pode ser entregue a um script através de uma variável de ambiente. Não diz nada sobre de onde vêm o nome de usuário e a palavra-passe.

Subi-lo para um nível superior é um reflexo comum porque a mensagem menciona Auth, mas altera as permissões dos scripts e não a fonte de entrada, e alarga o que o cliente pode executar. Se um script auxiliar faz parte do desenho, corrija primeiro a fonte de entrada e mantenha o nível de segurança no valor mais baixo de que a implementação precisa.

A interface de gestão é uma alternativa legítima. Um frontend pode ligar-se a ela, receber o pedido de credenciais e responder com o nome de usuário e a palavra-passe, que é como funcionam alguns GUI. Se a usar, ligue-a a um endereço local, proteja-a com um ficheiro de palavra-passe de gestão e restrinja quem se pode ligar, porque é um canal de controlo do cliente.

Verifique a etapa seguinte depois de o cliente ler o ficheiro

Assim que o cliente conseguir ler as credenciais, a falha seguinte é uma troca real com o servidor, e a sua mensagem tem outro significado. Uma falha de autenticação nessa etapa significa que o servidor rejeitou a conta; uma resposta de desafio significa que o servidor quer outro fator. Trate-as como problemas novos e não como o mesmo repetido.

Teste todo o caminho como o serviço o vai executar: mesma conta, mesmo diretório de trabalho, mesmo ambiente unit. Uma ligação que só funciona quando é iniciada a partir da sua shell é sinal de que uma variável de ambiente ou um terminal ainda faz parte do fluxo.

Depois guarde os segredos onde pertencem. As palavras-passe em argumentos de linha de comando aparecem na tabela de processos, e as palavras-passe na saída de depuração acabam nos tickets. Use um ficheiro protegido ou a interface de gestão, mantenha os registos num nível que não repita credenciais e troque o ficheiro quando alguém com acesso sair.

Lista de verificação: caminho absoluto das credenciais, legível como conta de serviço, sem necessidade de terminal, script-security deixado no mínimo, interface de gestão apenas se estiver ligada e autenticada, e a resposta do servidor resultante tratada como um evento separado.