Su RHEL l’errore passwd: modulo sconosciuto non indica quasi mai un problema di password in sé: di solito significa che passwd sta tentando di caricare un modulo PAM inesistente, mal referenziato o non installato. In pratica il flusso di autenticazione si rompe prima ancora di arrivare alla verifica della password. Se il problema compare su una macchina già in produzione, tratta l’evento come un incidente a impatto utenti fino a prova contraria: prima osserva, poi correggi.
Il punto giusto da cui partire è capire quale layer si è rotto: passwd invoca PAM, PAM può dipendere da moduli locali o da politiche centralizzate, e in mezzo ci sono anche NSS, SSSD o eventuali integrazioni con LDAP/AD. Un errore di questo tipo spesso nasce da una modifica recente a /etc/pam.d/passwd, da un pacchetto rimosso, da una configurazione derivata da hardening non completa o da un file PAM con un nome modulo scritto male.
Diagnosi probabile
Classificazione: troubleshooting. Stato atteso: il comando passwd dovrebbe aprire la sessione PAM, validare l’utente e permettere il cambio credenziali. Stato osservato: il comando si interrompe con un messaggio che cita un modulo sconosciuto, senza arrivare al prompt di cambio password.
Le ipotesi più probabili, in ordine:
/etc/pam.d/, spesso /etc/pam.d/passwd o un file incluso da lì. Si falsifica in pochi minuti controllando il file e cercando la riga che cita il modulo./usr/lib64/security/ e l’integrità del pacchetto con RPM.Blast radius: limitato al login o al cambio password dell’utente e, nei casi peggiori, a più servizi che condividono la stessa logica PAM. Rollback: ripristino del file PAM corretto o reinstallazione del pacchetto che fornisce il modulo, con backup del file prima di ogni modifica.
Verifiche immediate
Prima di toccare la configurazione, raccogli evidenze. Su RHEL il valore diagnostico più alto, in genere, arriva da tre cose: contenuto dei file PAM, presenza del modulo sul filesystem e log recenti del sistema.
Controlla il messaggio esatto e riproduci l’errore con un utente di test, se possibile:
passwd nomeutenteAtteso: l’errore compare subito o dopo il primo controllo PAM. Se il messaggio cambia a seconda dell’utente, potresti avere un problema legato a un backend esterno o a un account specifico.
Ispeziona il file PAM coinvolto:
sudo sed -n '1,200p' /etc/pam.d/passwdAtteso: righe leggibili, senza riferimenti a moduli inesistenti. Cerca nomi come pam_pwquality.so, pam_unix.so, pam_faillock.so o altri moduli non standard. Se c’è una riga con un nome che non corrisponde a un file presente, hai già la causa più probabile.
Verifica che il modulo esista nel percorso corretto:
ls -l /usr/lib64/security/ | grep -E 'pam_.*\.so'Atteso: il modulo citato nel file PAM deve esistere. Se manca, il problema è un pacchetto non installato, rimosso o corrotto.
Controlla i log del sistema per dettagli più espliciti:
sudo journalctl -xe | tail -n 80oppure, se presente, verifica /var/log/secure:
sudo tail -n 80 /var/log/secureAtteso: una riga con il nome del modulo mancante, un errore di apertura del file condiviso o un fallimento PAM più verboso del semplice messaggio a schermo.
Se sospetti un pacchetto mancante, controlla quale pacchetto fornisce il file:
rpm -qf /usr/lib64/security/pam_unix.soAtteso: nome del pacchetto installato. Se il file non esiste, il comando fallisce e conferma che manca il componente.
Se la macchina usa SSSD, LDAP o AD, verifica anche che l’errore non sia una conseguenza laterale di un backend non raggiungibile. In quel caso però il messaggio tipico è diverso: qui la presenza di “modulo sconosciuto” punta più spesso a un riferimento sbagliato nel file PAM che non a un problema di rete o directory service.
Soluzione consigliata passo-passo
L’obiettivo è fare il cambio minimo reversibile: ripristinare il file corretto o reinstallare il pacchetto necessario, senza riscrivere a mano l’intero stack PAM se non serve.
Fai un backup del file coinvolto prima di modificarlo:
sudo cp -a /etc/pam.d/passwd /etc/pam.d/passwd.bak.$(date +%F-%H%M)Rollback immediato: ripristino del backup con cp -a.
Confronta il file con un sistema sano o con un backup di configurazione noto:
sudo diff -u /etc/pam.d/passwd.bak.$(date +%F-%H%M) /etc/pam.d/passwdSe non hai un riferimento locale, controlla almeno la presenza di include standard come password-auth o system-auth, che su RHEL sono spesso usati come base comune.
Se il modulo manca, reinstalla il pacchetto che lo fornisce. Per esempio, per i moduli base PAM:
sudo dnf reinstall pamSu sistemi più vecchi può essere yum reinstall pam. Atteso: il file condiviso torna in /usr/lib64/security/ e il comando passwd riprende a funzionare.
Se il problema è una riga errata nel file PAM, correggila con il minimo intervento. Esempio: se trovi un nome modulo sbagliato o un path non valido, sostituiscilo con il valore corretto presente nei file standard di RHEL. Evita di inventare moduli o di copiare configurazioni da distribuzioni diverse senza verificare la sintassi.
Se il file sembra molto alterato, confrontalo con i template di sistema e con gli altri file PAM correlati, in particolare /etc/pam.d/system-auth e /etc/pam.d/password-auth:
sudo sed -n '1,200p' /etc/pam.d/system-authsudo sed -n '1,200p' /etc/pam.d/password-authAtteso: una struttura coerente, senza riferimenti a moduli non presenti. Se passwd include questi file, il problema potrebbe essere lì dentro e non nel file specifico del comando.
Se c’è un’alterazione recente e sospetti una gestione automatica della policy, controlla se il file è stato rigenerato da uno strumento di hardening o da un playbook. In quel caso, correggi la sorgente della configurazione, non solo il file locale, altrimenti il problema si ripresenterà al prossimo run.
Quando tocchi la configurazione PAM, il rischio principale non è solo rompere passwd: puoi bloccare login, sudo o altre funzioni che dipendono dallo stesso stack. Per questo motivo il rollback deve essere pronto prima della modifica. Se lavori da remoto, tieni aperta una seconda sessione amministrativa e verifica di non perdere l’accesso.
Se vuoi una correzione rapida e il problema è chiaramente un pacchetto mancante, la via più sicura è reinstallare il pacchetto invece di editare a mano i file. Se invece il pacchetto è presente e manca solo il riferimento nel file, il fix corretto è riallineare la configurazione ai template standard di RHEL.
Controlli finali / rollback
Dopo la correzione, devi validare tre cose: che il modulo sia presente, che il file PAM sia coerente e che il comando funzioni davvero per un utente reale.
Riesegui il comando:
passwd nomeutenteCondizione OK: nessun errore “modulo sconosciuto”, comparsa del prompt per la nuova password o del flusso previsto dalla policy locale.
Controlla di nuovo i log subito dopo il test:
sudo journalctl -xe | tail -n 40Condizione OK: assenza di nuovi errori PAM associati a passwd.
Verifica che il modulo e il pacchetto siano coerenti:
rpm -qf /usr/lib64/security/pam_unix.soCondizione OK: il file è posseduto da un pacchetto installato e non risulta mancante.
Se qualcosa non torna, rollback immediato del file modificato:
sudo cp -a /etc/pam.d/passwd.bak.YYYY-MM-DD-HHMM /etc/pam.d/passwdpoi ritesta con passwd nomeutente. Se hai reinstallato un pacchetto e il problema è peggiorato, valuta il ripristino dal repository o dal mirror aziendale, ma solo dopo aver confermato che il file di configurazione non sia la vera causa.
Assunzione operativa: il sistema è RHEL o compatibile RHEL recente, con PAM standard e accesso amministrativo locale o via sudo. Se la macchina usa una catena di autenticazione non standard, la verifica va estesa ai file inclusi e ai moduli del backend esterno, ma il principio resta lo stesso: prima individua il modulo citato, poi verifica la sua presenza, infine correggi il riferimento o reinstalla il pacchetto che lo fornisce.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.