O OpenVPN lê a senha do terminal, não do stdin

OpenVPN pede um nome de usuário e uma senha no terminal de controle, e um arquivo redirecionado para a entrada padrão não é esse terminal. Esse único detalhe explica o script que trava com a senha ali mesmo no cano. O cliente desenha o prompt e a leitura é feita do dispositivo de terminal, então redirecionar o stdin não muda nada. Alimente o cliente por uma das suas vias de entrada documentadas e o mesmo script conecta na primeira tentativa.

Três vias cobrem quase todos os casos, e cada uma falha à sua maneira. Escolha pelo prompt que o cliente realmente mostra, não pela opção mais fácil de colocar num script.

O prompt não vem do stdin

Quando o OpenVPN precisa de credenciais, ele abre o terminal de controle e lê ali. Por isso um teste interativo parece certo enquanto o mesmo comando sob cron ou num arquivo de unidade fica parado com o prompt escrito num log que ninguém olha. Algumas compilações voltam à entrada padrão quando não existe terminal, e essa inconsistência é pior que uma falha dura porque esconde o problema até a implantação.

Verifique o ambiente antes de escrever qualquer código: execute o cliente sob o mesmo usuário, com o mesmo stdin, que o agendador ou o gerenciador de serviços usará. Se o prompt nunca aparece no log e o processo não avança, algo espera um terminal que não existe.

Primeira via: um arquivo de credenciais de duas linhas

A opção de autenticação recebe um caminho, e o arquivo contém exatamente duas linhas, primeiro o nome de usuário e depois a senha, sem mais nada. Passe o caminho explicitamente em vez de confiar num nome de arquivo padrão, porque um arquivo de credenciais perdido no diretório de trabalho é como a conta errada acaba em uso. Defina o modo como 0600 e dê a propriedade à conta que executa o cliente.

O cliente lê esse arquivo uma vez na inicialização, então girar a senha significa reiniciar o processo. Normalmente é o comportamento que você quer, e ele pertence ao runbook ao lado do procedimento de rotação.

Segunda via: askpass para a frase da chave

Uma chave privada protegida por frase provoca um segundo prompt, diferente, e ele tem a sua própria resposta em arquivo: a opção askpass lê a frase da primeira linha de um arquivo. Para túneis baseados em SSH o equivalente é um programa askpass que o cliente executa, e cuja saída padrão se torna o segredo.

Nenhuma das formas coloca o segredo na lista de argumentos, e ambas o deixam existindo como arquivo ou como executável que o imprime. A proteção são as permissões de arquivo e a propriedade do processo, não a obscuridade. Um auxiliar que ecoa uma string escrita no código é um segredo com passos extras.

Terceira via: a CLI própria do cliente do portal

Os clientes corporativos costumam trazer um ponto de entrada de linha de comando que conecta a um portal nomeado sem nenhuma janela, e essa é a via suportada. No Linux o cliente GlobalProtect expõe operações de conexão e importação de certificado pela sua CLI, e os portais que usam autenticação por certificado precisam do passo de importação antes que uma conexão automatizada funcione. Prefira-a às pressões de tecla sintéticas: você obtém um status de saída real, nenhuma dependência do foco da janela, e ela sobrevive a uma tela bloqueada.

Se a primeira conexão ainda precisa de uma pessoa para aceitar um certificado, a automação não está pronta. Faça a importação durante a configuração e registre-a como pré-requisito.

Quando o fluxo precisa de um pseudo-terminal

Uma sequência que pede uma senha e depois um código de uso único não tem um único arquivo para ler. Um driver de terminal como o Expect é a ferramenta certa porque espera cada padrão por vez, e precisa do processo iniciado antes de poder casar qualquer coisa.

Dois fracassos dominam. Um script que espera um prompt sem iniciar o cliente espera para sempre, e Tcl não é um shell, então a aritmética de shell escrita dentro de um bloco expect não é avaliada como se lê. Mantenha a flag de depuração ligada enquanto constrói os padrões e depois desligue-a.

Segredos que vazam, e onde se escondem

Tudo o que é passado como argumento fica visível na lista de processos, então as credenciais pertencem a um arquivo ou a um auxiliar, nunca à linha de comando. Os códigos de uso único são consumidos por desenho e precisam ser produzidos para cada tentativa. Os logs de falha costumam carregar o nome de usuário e às vezes mais, então redija-os antes de enviá-los a qualquer lugar, e mantenha o segredo fora do próprio perfil, porque um arquivo de configuração com senha embutida acaba colado em tickets e repositórios. Girar a conta então significa caçar cada cópia, e é exatamente esse custo que este arranjo evita.

Audite as vias que você escolheu e depois ligue-as ao arquivo de unidade ou ao agendador que realmente executará o cliente. O túnel vive exatamente tanto quanto esse processo.