OpenVPN le o contrasinal do terminal, non de stdin

OpenVPN pide un nome de usuario e un contrasinal no terminal de control, e un ficheiro redirixido á entrada estándar non é ese terminal. Ese único detalle explica o script que se colga co contrasinal xusto aí na tubaxe. O cliente debuxa o aviso e a lectura tómase do dispositivo de terminal, así que redirixir stdin non cambia nada. Alimente o cliente por unha das súas vías de entrada documentadas e o mesmo script conéctase ao primeiro intento.

Tres vías cobren case todos os casos, e cada unha falla á súa maneira. Escolla polo aviso que o cliente amosa realmente, non pola opción que sexa máis fácil de escribir nun script.

O aviso non vén de stdin

Cando OpenVPN necesita credenciais abre o terminal de control e le alí. Por iso unha proba interactiva parece correcta e o mesmo comando baixo cron ou un ficheiro de unidade queda inactivo co aviso escrito nun rexistro que ninguén mira. Algunhas compilacións volven á entrada estándar cando non existe un terminal, e esa inconsistencia é peor ca un fallo duro porque agocha o problema ata o despregamento.

Comprobe a contorna antes de escribir calquera código: execute o cliente baixo o mesmo usuario, co mesmo stdin, que usará o planificador ou o xestor de servizos. Se o aviso nunca aparece no rexistro e o proceso non avanza, algo agarda un terminal que non existe.

Primeira vía: un ficheiro de credenciais de dúas liñas

A opción de autenticación toma unha ruta, e o ficheiro contén exactamente dúas liñas, primeiro o nome de usuario e despois o contrasinal, sen nada máis. Pase a ruta explicitamente en lugar de confiar nun nome de ficheiro predeterminado, porque un ficheiro de credenciais perdido no directorio de traballo é como a conta equivocada acaba en uso. Fixe o modo en 0600 e dea a propiedade á conta que executa o cliente.

O cliente le ese ficheiro unha vez ao arrincar, así que rotar o contrasinal significa reiniciar o proceso. Normalmente ese é o comportamento que quere, e pertence ao runbook xunto ao procedemento de rotación.

Segunda vía: askpass para a frase da clave

Unha clave privada protexida con frase expón un segundo aviso distinto, e ten a súa propia resposta en ficheiro: a opción askpass le a frase da primeira liña dun ficheiro. Para os túneles baseados en SSH o equivalente é un programa askpass que o cliente executa, e cuxa saída estándar se converte no segredo.

Ningunha das dúas formas pon o segredo na lista de argumentos, e ambas o deixan existindo como ficheiro ou como executábel que o imprime. A protección son os permisos de ficheiro e a propiedade do proceso, non a escuridade. Un axudante que fai eco dunha cadea escrita no código é un segredo con pasos extra.

Terceira vía: a CLI propia do cliente do portal

Os clientes empresariais adoitan incluír un punto de entrada de liña de ordes que se conecta a un portal con nome sen ningunha xanela, e esa é a vía admitida. En Linux o cliente GlobalProtect expón operacións de conexión e importación de certificado a través da súa CLI, e os portais que usan autenticación por certificado necesitan o paso de importación antes de que unha conexión automatizada poida funcionar. Prefírao ás pulsacións sintetizadas: obtén un estado de saída real, ningunha dependencia do foco da xanela e sobrevive a unha pantalla bloqueada.

Se a primeira conexión aínda necesita unha persoa para aceptar un certificado, a automatización non está rematada. Faga a importación durante a configuración e rexístrea como requisito previo.

Cando o fluxo necesita un pseudo-terminal

Unha secuencia que pide un contrasinal e despois un código dun só uso non ten un único ficheiro que ler. Un controlador de terminal como Expect é a ferramenta correcta porque agarda cada patrón por quenda, e necesita o proceso iniciado antes de poder coincidir con nada.

Dous fallos dominan. Un script que agarda un aviso sen lanzar o cliente agarda para sempre, e Tcl non é un shell, así que a aritmética de shell escrita dentro dun bloque expect non se avalía como se le. Manteña a bandeira de depuración activa mentres constrúe os patróns e despois apáguea.

Segredos que se filtran, e onde se agochan

Todo o que se pasa como argumento é visible na lista de procesos, así que as credenciais van nun ficheiro ou detrás dun axudante, nunca na liña de ordes. Os códigos dun só uso consómense por deseño e hai que producilos para cada intento. Os rexistros de fallos a miúdo levan o nome de usuario e ás veces máis, así que redánteos antes de envialos a calquera parte, e manteña o segredo fóra do propio perfil, porque un ficheiro de configuración cun contrasinal incrustado acaba pegado en tickets e repositorios. Rotar a conta entón significa cazar cada copia, que é exactamente o custo que evita esta disposición.

Audite as vías que escolleu e despois conécteas ao ficheiro de unidade ou ao planificador que realmente executará o cliente. O túnel vive exactamente tanto como ese proceso.