OpenVPN PAM: l’argomento di accesso è un servizio, non un utente

È stato aggiunto un utente sul server, la password è stata digitata correttamente e la connessione termina comunque con AUTH_FAILED. La riga del plugin di solito spiega il perché: la parola dopo il percorso del plugin è un nome di servizio PAM, e decide quale stack di moduli risponde alla domanda. Non è un nome utente e non è un puntatore a un file di password che OpenVPN legge da solo.

Che cosa seleziona la seconda parola

La riga di configurazione prende un percorso di plugin e un argomento:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

Quell’argomento viene passato alla libreria PAM come nome del servizio, il che fa eseguire lo stack in /etc/pam.d/openvpn. Se ci scrivi login ottieni invece la politica di accesso interattiva, con i moduli che quella politica include sulla tua distribuzione.

Usa il percorso del plugin fornito dal pacchetto installato, non un percorso copiato da un altro host. Il nome del file e la directory differiscono tra distribuzioni, e un percorso sbagliato fallisce all’avvio con un errore di caricamento del plugin, non all’autenticazione.

Dove lo stack legge davvero gli account

PAM è uno smistatore. Il file di servizio elenca i moduli in ordine, e il primo che può rispondere decide l’esito. Uno stack che chiama pam_unix legge gli account locali; uno stack che chiama un modulo LDAP o RADIUS manda le credenziali altrove.

Leggi il file a cui il nome del servizio si risolve, compreso tutto ciò che include:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

Se lo stack delega a una directory, aggiungere un account locale non cambia nulla. Se legge gli account locali, creare l’utente nella directory non cambia nulla lo stesso. L’account deve esistere dove guarda lo stack, e questa è tutta la diagnosi nella maggior parte di questi rapporti.

Un tentativo, due log

Correla una singola connessione fallita su entrambi i lati. Il log di OpenVPN mostra il risultato del plugin e il rifiuto del client; il log di autenticazione del sistema mostra quale modulo è stato eseguito e che cosa ha deciso. Leggerli nella stessa finestra temporale è ciò che distingue un file di servizio mancante da un timeout del backend. Un vuoto nel log di autenticazione significa che lo stack non è mai stato raggiunto.

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

Prova il servizio direttamente con un’utilità che parla PAM, così non stai eseguendo il debug della VPN e dello stack insieme. Un test diretto riuscito con lo stesso nome di servizio e account restringe il problema a come il demone passa le credenziali, non all’account.

pamtester openvpn alice authenticate

Se il test diretto fallisce con le stesse credenziali che funzionano in console, lo stack non legge l’origine degli account che supponevi. Se riesce, guarda la conversazione eseguita dal plugin e ciò che il client ha realmente inviato. Eseguilo anche una volta con una password volutamente sbagliata, per vedere la differenza tra un rifiuto e un errore di modulo. Quei due esiti sembrano identici nel log della VPN e completamente diversi qui.

Un servizio dedicato batte la modifica dell’accesso

Dai alla VPN un proprio file di servizio quando i suoi requisiti differiscono dall’accesso interattivo, come di solito accade. Modificare login o common-auth cambia la politica per ogni programma che li include, e la prossima persona che eseguirà il debug di un problema di accesso non correlato erediterà la tua modifica.

Copia i moduli che ti servono in un piccolo file di servizio, mantieni l’ordine esplicito e annota chi lo possiede. Quel file è ciò che va controllato quando un ripristino della password sembra non avere effetto.

Che cosa invia il client e che cosa no

Il client fornisce un nome utente e una password tramite la richiesta o il file supportato. Il plugin del server passa quei valori nella conversazione PAM; non li legge dalla configurazione del server. Una riga lato server che sembra definire una password non lo fa, e nessuna modifica del profilo creerà un account.

Nome utente e password possono coesistere con i certificati client, e abilitare PAM non è un motivo per smettere di verificare i certificati. Mantieni i livelli che il deployment intendeva e correggi solo l’origine degli account.

L’accettazione è bidirezionale: l’account previsto riesce, e un account che dovrebbe essere rifiutato continua a fallire. Il README del plugin auth-pam documenta l’argomento di servizio e i backend che può fronteggiare, ed è il punto in cui confermare la disposizione che stai cercando di costruire.