Il servizio OpenVPN si blocca sulla richiesta della password della chiave privata: come risolvere

OpenVPN chiede la passphrase della chiave privata sulla macchina locale, quindi un file di accesso funzionante non risponde mai. In un servizio non c’è un terminale su cui digitare, e l’avvio o si blocca o fallisce con una voce di journal che nomina l’input invece della causa. Sono coinvolti due segreti, e ciascuno ha bisogno della propria fonte leggibile prima di riavviare l’unità. Il percorso sotto li separa, poi verifica l’identità che apre davvero ogni file.

Distinguere le due richieste

La passphrase della chiave decifra la chiave privata locale; le credenziali dell’account autenticano la sessione verso il server. Vengono da posti diversi, falliscono in momenti diversi e producono messaggi diversi. Confonderle manda a cercare un reset della password quando l’account non c’entrava nulla. Leggete il testo della richiesta prima di cambiare qualsiasi opzione, perché la formulazione è l’unico indizio affidabile su quale segreto manca.

In Community OpenVPN 2.x, askpass indica un file che contiene la passphrase della chiave sulla prima riga, e auth-user-pass indica un file con il nome utente su una riga e la password sulla successiva. Nessuno dei due file soddisfa l’altra opzione. Un’app desktop o un profilo NetworkManager possono tenere entrambi nel proprio archivio di segreti, che un client da riga di comando non legge mai, quindi annotate quale client state configurando prima di scrivere un percorso.

Puntate entrambe le opzioni a file leggibili

Un profilo che ha bisogno di entrambi gli input finisce con tre riferimenti a file: la chiave cifrata, la passphrase che la sblocca e la coppia di accesso. Aggiungeteli senza toccare la CA né i controlli di identità, perché quelli decidono chi è il server e non fanno parte di questo problema. Se il deployment non usa affatto credenziali dell’account, aggiungere auth-user-pass crea un input che nessuno può fornire.

key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.auth

Le opzioni senza argomento si comportano diversamente da quelle con percorso, e su un servizio la differenza conta. Un askpass senza argomento legge ancora la console, e un file auth-user-pass con solo un nome utente lascia ancora una richiesta di password in attesa. Una volta che il client diventa demone non può più chiedere input a un terminale, quindi un servizio configurato così non parte.

I percorsi assoluti eliminano la questione della directory di lavoro ma non concedono l’accesso. Proprietà, modo e attraversamento vengono dopo, e tutti e tre sono verificati rispetto all’account con cui gira il processo.

Leggete la configurazione dell’unità prima del profilo

È l’unità, non il file che stavate modificando, a decidere quale configurazione carica l’istanza. Leggete la sua riga di comando e ogni drop-in, poi seguite la directory di lavoro fino al profilo realmente in uso. Un riferimento alla passphrase aggiunto a un altro file .ovpn non cambia nulla per questa istanza.

Tre comandi di sola lettura rispondono alla maggior parte. Il primo stampa l’unità e gli eventuali drop-in, il secondo l’identità e le impostazioni sandbox che vincolano il processo, e il terzo ciò di cui l’ultimo avvio si è realmente lamentato. Usate il nome dell’istanza che esiste sull’host:

systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -b

Fate attenzione a ProtectHome e alle opzioni proprie del profilo user, group e chroot. Un file sotto una directory home può essere leggibile nella vostra shell e invisibile dentro il servizio una volta nascoste le directory home. L’account con cui systemd avvia non è sempre quello che finisce per aprire la chiave.

Dimostrate che l’identità di esecuzione può aprire entrambi i file

Leggere il modo non basta, perché ogni directory del percorso deve essere attraversabile dalla stessa identità. Percorrete il percorso componente per componente, poi provate l’apertura come l’account che usa il processo. Un file con modo 600 di proprietà di root funziona solo finché il processo è ancora root, cosa non vera dopo la riduzione dei privilegi che molti profili eseguono. Due comandi coprono l’attraversamento e l’apertura:

namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readable

Il primo comando stampa il modo di ogni componente e fallisce dove l’account non può attraversare; il secondo risponde all’unica domanda che conta, se l’identità di esecuzione può aprire il file in lettura. Nessuno dei due stampa il contenuto del file, ed è proprio il punto quando il file contiene una passphrase. Ripetete il test per il file di accesso, perché i due sono spesso memorizzati con proprietari diversi.

Se il processo usa un chroot o un namespace limitato, eseguite lo stesso test da dentro quella vista, altrimenti la risposta descrive il filesystem sbagliato. Una passphrase salvata sotto una directory home nascosta è l’esempio abituale di test che passa fuori dall’unità e fallisce dentro.

Controllate il primo avvio, poi una riconnessione

Avviate l’istanza una volta e leggete il primo errore invece dell’ultimo. Un file di input mancante, una decifratura della chiave fallita e un AUTH_FAILED dal server sono tre eventi diversi con tre riparazioni diverse. Correggere un avviso sui permessi non dimostra nulla sul fatto che la chiave sia stata sbloccata.

La riga del journal dice quale dei tre avete. La riparazione deriva da quale input è fallito:

Poi provate il ciclo di vita che vi serve davvero: un avvio al boot e ogni riconnessione supportata, non solo un avvio manuale dalla vostra shell. Con auth-nocache gli input vengono scartati dopo il primo uso, quindi una riconnessione successiva ha comunque bisogno di una fonte leggibile. Un portachiavi sbloccato all’accesso al desktop non è disponibile per un servizio avviato prima che qualcuno accedesse, ed è la ragione abituale per cui un test manuale passa e un riavvio fallisce. Se il primo avvio riesce e una riconnessione successiva fallisce, leggete il journal per l’evento di riconnessione prima di cambiare di nuovo i permessi.

Memorizzare la passphrase accanto alla chiave riduce ciò che la cifratura vi dà, quindi limitate quel file e i suoi backup. Trattate la rimozione della passphrase della chiave come una decisione separata sulle credenziali, non come la riparazione di un input mancante. Un deployment che dipende da approvazione umana o MFA interattiva ha bisogno del suo agente o della sua integrazione di gestione supportata; un codice monouso salvato in permanenza non è un sostituto equivalente.