OpenVPN legge la password dal terminale, non da stdin

OpenVPN chiede un nome utente e una password sul terminale di controllo, e un file reindirizzato sull'ingresso standard non è quel terminale. Quel singolo dettaglio spiega lo script che resta appeso con la password lì dentro la pipe. Il prompt lo disegna il client e la lettura avviene dal dispositivo terminale, quindi reindirizzare stdin non cambia nulla. Alimenta il client attraverso una delle sue vie d'ingresso documentate e lo stesso script si connette al primo tentativo.

Tre vie coprono quasi ogni caso, e ciascuna fallisce a modo suo. Scegli in base al prompt che il client mostra davvero, non in base all'opzione più facile da mettere in uno script.

Il prompt non viene da stdin

Quando OpenVPN ha bisogno di credenziali apre il terminale di controllo e legge lì. Per questo un test interattivo sembra a posto mentre lo stesso comando sotto cron o in un file unit resta fermo con il prompt scritto in un registro che nessuno guarda. Alcune build ricadono sull'ingresso standard quando non esiste un terminale, e questa incoerenza è peggio di un guasto netto perché nasconde il problema fino al rilascio.

Controlla l'ambiente prima di scrivere qualsiasi codice: esegui il client con lo stesso utente, con lo stesso stdin, che userà lo scheduler o il gestore dei servizi. Se il prompt non compare mai nel registro e il processo non avanza, qualcosa attende un terminale che non esiste.

Prima via: un file di credenziali di due righe

L'opzione di autenticazione prende un percorso, e il file contiene esattamente due righe, prima il nome utente poi la password, senza nient'altro. Passa il percorso in modo esplicito invece di affidarti a un nome file predefinito, perché un file di credenziali vagante nella directory di lavoro è il modo in cui l'account sbagliato finisce in uso. Imposta il modo a 0600 e assegna la proprietà all'account che esegue il client.

Il client legge quel file una volta all'avvio, quindi ruotare la password significa riavviare il processo. Di solito è il comportamento che vuoi, e appartiene al runbook accanto alla procedura di rotazione.

Seconda via: askpass per la passphrase della chiave

Una chiave privata protetta da passphrase solleva un secondo prompt diverso, e ha la sua risposta su file: l'opzione askpass legge la passphrase dalla prima riga di un file. Per i tunnel basati su SSH l'equivalente è un programma askpass che il client esegue, e la cui uscita standard diventa il segreto.

Nessuna delle due forme mette il segreto nella lista degli argomenti, ed entrambe lo lasciano esistere come file o come eseguibile che lo stampa. La protezione sono i permessi del file e la proprietà del processo, non l'oscurità. Un aiutante che riecheggia una stringa scritta nel codice è un segreto con passaggi extra.

Terza via: la CLI propria del client del portale

I client aziendali di solito forniscono un punto d'ingresso a riga di comando che si connette a un portale con nome senza alcuna finestra, e quella è la via supportata. Su Linux il client GlobalProtect espone le operazioni di connessione e di importazione del certificato tramite la sua CLI, e i portali che usano l'autenticazione con certificato hanno bisogno del passo di importazione prima che una connessione automatizzata possa funzionare. Preferiscila alle pressioni di tasti sintetizzate: ottieni uno stato di uscita reale, nessuna dipendenza dal fuoco della finestra, e sopravvive a uno schermo bloccato.

Se la prima connessione richiede ancora una persona per accettare un certificato, l'automazione non è finita. Fai l'importazione durante la configurazione e registrala come prerequisito.

Quando il flusso richiede uno pseudo-terminale

Una sequenza che chiede una password e poi un codice monouso non ha un singolo file da leggere. Un driver di terminale come Expect è lo strumento giusto perché attende ogni schema a turno, e ha bisogno del processo avviato prima di poter far corrispondere qualcosa.

Due guasti dominano. Uno script che attende un prompt senza avviare il client attende per sempre, e Tcl non è una shell, quindi l'aritmetica di shell scritta dentro un blocco expect non viene valutata come si legge. Tieni attivo il flag di debug mentre costruisci gli schemi, poi spegnilo.

Segreti che trapelano, e dove si nascondono

Tutto ciò che passa come argomento è visibile nell'elenco dei processi, quindi le credenziali stanno in un file o dietro un aiutante, mai sulla riga di comando. I codici monouso si consumano per progetto e vanno prodotti per ogni tentativo. I registri dei guasti portano spesso il nome utente e a volte altro, quindi oscurali prima di inviarli ovunque, e tieni il segreto fuori dal profilo stesso, perché un file di configurazione con una password incorporata finisce incollato in ticket e repository. Ruotare l'account allora significa cacciare ogni copia, ed è esattamente il costo che questa disposizione evita.

Verifica le vie che hai scelto, poi collegale nel file unit o nello scheduler che eseguirà davvero il client. Il tunnel vive esattamente quanto quel processo.