Correzione: OpenVPN non è riuscito a leggere il nome utente Auth dall’input standard

could not read Auth username from stdin sembra un problema di autenticazione e non lo è. OpenVPN ha provato a chiedere il nome utente sull’input standard, non ha trovato nulla di leggibile e si è fermato prima ancora di contattare il server. L’account può essere del tutto valido; il processo semplicemente non ha nessuno a cui chiedere.

Per questo il primo passo utile è confermare che cosa sta leggendo il client, non riprovare la connessione né cambiare impostazioni lato server. Seguite i controlli qui sotto in ordine e fermatevi al primo che fallisce.

Leggete l’errore come un guasto locale dell’input

Quando auth-user-pass compare senza un argomento file, il client si aspetta di chiedere. In una shell interattiva quel prompt funziona perché il processo possiede un terminale. Sotto systemd, un job cron o un container, l’input standard è di solito vuoto e la lettura ritorna subito con l’errore che state vedendo.

Il messaggio nomina anche il campo che ha fallito, nome utente o password, il che indica fin dove è arrivata la lettura. Un nome utente mancante significa che il processo non è riuscito a leggere proprio nulla. Una password mancante dopo un nome utente riuscito significa che il flusso di input è terminato tra le due letture, cosa tipica di un file scritto a metà o di una pipe chiusa.

Confermate la visione del client stesso prima di cambiare qualsiasi altra cosa. Eseguitelo in primo piano con la stessa configurazione e lo stesso utente, e osservate se il prompt compare. Se compare nella vostra shell ma non sotto il gestore dei servizi, la differenza è nella fonte di input, non nelle credenziali. Un rapido confronto tra il file unit e l’ambiente della vostra shell mostra di solito quale dei due fornisce un terminale.

Date al servizio una fonte di credenziali supportata

La fonte supportata per l’esecuzione senza supervisione è un file di credenziali passato come argomento a auth-user-pass. Il file viene letto come testo semplice: la prima riga è il nome utente, la seconda la password. Indicatelo con un percorso assoluto come /etc/openvpn/client/creds , così che la directory di lavoro dell’account di servizio non possa cambiare il significato della direttiva.

I permessi contano quanto il percorso. Il file deve essere leggibile dall’account che esegue il client e non da tutti gli altri, e dovrebbe appartenere all’account di servizio o a root con un gruppo che includa il servizio. Verificate la leggibilità come quell’account, senza stampare il contenuto.

Un percorso relativo è la modalità di guasto silenziosa. Il profilo può trovarsi in una directory mentre systemd avvia il processo altrove, quindi un file che si risolve nella vostra shell non si risolve per il servizio. Spostate le credenziali in una posizione fissa e fatevi riferimento in modo assoluto. Poi avviate il servizio una volta e confermate che viene usato lo stesso percorso, invece di fidarvi della vista dell’editor di profili.

Se il deployment richiede un codice monouso o un’altra sfida interattiva, decidete se il flusso di lavoro del client la supporta davvero senza supervisione. Un file con una password statica non può rispondere a un codice che ruota, e riprovare un prompt senza risposta non aggiunge informazione.

Perché script-security non aiuterà

script-security controlla se il client può eseguire script e quanto può passare loro, compreso se una password può essere consegnata a uno script tramite una variabile d’ambiente. Non dice nulla su da dove vengono il nome utente e la password.

Alzarlo a un livello superiore è un riflesso comune perché il messaggio menziona Auth, ma cambia i permessi degli script anziché la fonte di input, e amplia ciò che il client può eseguire. Se uno script ausiliario fa parte del progetto, correggete prima la fonte di input e mantenete il livello di sicurezza al valore più basso di cui il deployment ha bisogno.

L’interfaccia di gestione è un’alternativa legittima. Un frontend può connettersi, ricevere la richiesta di credenziali e rispondere con nome utente e password, ed è così che funzionano alcune GUI. Se la usate, vincolatela a un indirizzo locale, proteggetela con un file di password di gestione e limitate chi può connettersi, perché è un canale di controllo del client.

Verificate la fase successiva dopo che il client ha letto il file

Una volta che il client può leggere le credenziali, il guasto successivo è uno scambio reale con il server, e il suo messaggio ha un significato diverso. Un guasto di autenticazione in quella fase significa che il server ha rifiutato l’account; una risposta di sfida significa che il server vuole un altro fattore. Trattateli come problemi nuovi e non come lo stesso ripetuto.

Provate l’intero percorso come lo eseguirà il servizio: stesso account, stessa directory di lavoro, stesso ambiente unit. Una connessione che funziona solo se avviata dalla vostra shell è il segno che una variabile d’ambiente o un terminale fa ancora parte del flusso.

Poi tenete i segreti dove devono stare. Le password negli argomenti della riga di comando compaiono nella tabella dei processi, e quelle nell’output di debug finiscono nei ticket. Usate un file protetto o l’interfaccia di gestione, tenete i log a un livello che non ripeta le credenziali e cambiate il file quando qualcuno con accesso se ne va.

Elenco di controllo: percorso assoluto delle credenziali, leggibile come account di servizio, nessun terminale richiesto, script-security lasciato al minimo, interfaccia di gestione solo se è vincolata e autenticata, e la risposta del server risultante trattata come evento separato.