Un messaggio di errore "Autenticazione PAM non riuscita" non indica una soluzione universale. Innanzitutto, identifica il servizio e gli utenti che presentano l'errore, quindi controlla il registro eventi all'ora corrispondente. Su SUSE Linux Enterprise Server (SLES), ripara un problema PAM globale confermato tramite pam-confige modifica un singolo file di servizio solo se il suo stack è errato. Mantieni aperta una sessione root o amministrativa funzionante durante i test; uno stack PAM danneggiato può bloccare nuovi accessi SSH e alla console.
La Guida alla sicurezza e all'indurimento di SLES 15 SP7 descrive PAM come una pila di moduli di autenticazione, account, password e sessione. Questa distinzione è importante: una password corretta può superare questa authfase e venire comunque rifiutata in seguito da una policy di account o da una regola specifica del servizio. Un messaggio di errore generico da solo non è sufficiente a identificare quale fase ha causato l'errore.
PAM funge da intermediario tra un'applicazione, come sshdad esempio l'accesso tramite console, e i metodi di autenticazione configurati. Ogni servizio compatibile con PAM ha un file nella directory /etc/pam.d/. Il file di servizio può includere file comuni di SLES come common-authe common-account, pertanto un errore isolato a SSH può avere una causa diversa rispetto agli errori che si verificano con tutti i metodi di accesso.
Verificato: lo stack SSH documentato di SUSE include pam_nologin.soi file PAM comuni. Se /etc/nologinpresente, il modulo documentato nega l'accesso agli utenti diversi da root. Dipendente dal contesto: le regole modificate localmente, i servizi di directory e i moduli MFA di terze parti possono aggiungere ulteriori controlli. Non stabilito dal solo messaggio: che la password sia errata, che i file PAM siano danneggiati o che l'account sia bloccato. Iniziare dal servizio interessato e dal relativo log anziché sostituire lo stack.
Riproduci l'errore una volta e annota l'ora, il nome utente e il metodo: SSH, console di testo locale, accesso grafico, sudoo su. Se puoi accedere come amministratore, controlla i messaggi di sistema recenti:
sudo journalctl -eLa guida alla risoluzione dei problemi di SLES di SUSE raccomanda specificamente di controllare il registro per errori di accesso e PAM. Cercate intorno all'ora esatta del tentativo il nome del modulo o la causa, ad esempio un account negato, un servizio di directory non disponibile, un modulo mancante o un errore di file/permessi. Non condividete i log pubblicamente senza aver prima rimosso nomi utente, nomi host, indirizzi e altri dettagli sensibili.
Se il problema riguarda solo SSH, controlla il registro del demone SSH:
sudo journalctl -u sshd
Successivamente, confronta i percorsi di accesso. Se un utente riesce ad autenticarsi sulla console locale ma non tramite SSH, concentrati sulla /etc/pam.d/sshdpolicy di accesso SSH o su un modulo specifico per SSH. Se più servizi rifiutano gli stessi utenti locali, esamina i loro common-*file condivisi. Se solo un utente non riesce ad autenticarsi, verifica lo stato dell'account e la password prima di modificare l'autenticazione a livello di sistema.
Per un utente locale, verificare prima il nome utente, il layout della tastiera e il tasto Bloc Maiusc. Se è necessario reimpostare le credenziali, utilizzare lo strumento per la gestione delle password approvato dall'amministratore, come YaST User and Group Management, anziché modificarle /etc/shadowmanualmente. Se a tutti gli utenti non root viene negato l'accesso tramite SSH, verificare la presenza di un file di manutenzione pianificata /etc/nologinprima di modificare PAM; rimuoverlo solo se il blocco di manutenzione risulta obsoleto e si dispone dell'autorizzazione necessaria.
Per gli utenti LDAP, Active Directory o di altri sistemi di directory, una password funzionante su un altro server non garantisce che questo host SLES possa raggiungere il provider di identità. SUSE elenca tra le possibili cause problemi di rete e DNS, deriva dell'orologio Kerberos, regole PAM configurate in modo errato, criteri di accesso host e directory home non disponibili. Verificare se un altro utente di dominio riesce ad accedere e se l'utente interessato riesce ad accedere a un host diverso. Quindi, controllare il servizio di identità configurato e la connettività del server.
Quando l'host utilizza SSSD, verificare il relativo servizio e se PAM è configurato per utilizzarlo:
systemctl status sssd
sudo pam-config --query --sss
SSSD può memorizzare nella cache le informazioni utente e consentire l'autenticazione anche se la directory è temporaneamente irraggiungibile, ma questo comportamento dipende dalla sua configurazione e dalle credenziali memorizzate nella cache. Una cache obsoleta o mancante è quindi una possibilità, non una conclusione. Prima di cancellare qualsiasi cache o modificare i moduli, verificare il DNS, la sincronizzazione dell'ora per Kerberos, la raggiungibilità della directory e i log di SSSD. Se il provider di identità segnala "Account bloccato" o "Account disabilitato", chiedere all'amministratore della directory di verificare i criteri relativi a tale account; PAM segnala la decisione, non la crea necessariamente.
Esamina il file specifico del servizio e le regole condivise in esso contenute:
sudo grep -nE '^(auth|account|password|session)' /etc/pam.d/sshd
sudo pam-config --query --sss
Su SLES, pam-configi file globali vengono mantenuti in /etc/pam.d/common-*; i singoli file di servizio come /etc/pam.d/sshdvengono mantenuti separatamente. Non modificare manualmente i file comuni generati a meno che non siano stati deliberatamente disabilitati pam-config. Se si conferma che questo host dovrebbe utilizzare SSSD e le relative regole PAM di SSSD sono mancanti, consultare la documentazione SUSE sudo pam-config --add --sssper aggiungerle. Utilizzarla solo dopo aver verificato che SSSD stesso sia configurato e in esecuzione, quindi testare un nuovo accesso mentre la sessione amministrativa di lavoro rimane aperta.
Un equivoco comune ma rischioso è che pam-config --createsi tratti di un comando di riparazione innocuo. SUSE afferma che crea una configurazione di autenticazione Unix di base e sovrascrive i file preesistenti che non gestisce, mantenendo delle copie di backup. Questo può rimuovere l'autenticazione a più fattori personalizzata o il comportamento di autenticazione della directory. Non eseguirlo come passaggio di ripristino generico. In caso di errore di battitura in un file di servizio, ripristina la configurazione corretta e appropriata alla versione del servizio da un backup attendibile oppure modifica la riga specifica errata seguendo la procedura di modifica della tua organizzazione.
Lascia aperta la sessione root o di amministratore originale. Avvia una seconda sessione tramite lo stesso servizio che ha causato l'errore, ad esempio una nuova connessione SSH, e testa l'account interessato. Verifica che il registro non registri più lo stesso errore di autenticazione PAM e che un altro metodo di autenticazione configurato funzioni correttamente. Se l'errore persiste, annota l'ora esatta, il servizio, il nome del modulo PAM e le righe di registro pertinenti (opportunamente anonimizzate); questi dettagli sono più utili del messaggio generico "errore di autenticazione".
pam-config.Individuare la causa di un errore PAM, ovvero il servizio, i criteri dell'account o il provider di identità, quindi ripristinare la corretta configurazione SLES preservando una sessione amministrativa funzionante.
Esegui il backup simultaneo dei file di Nextcloud e di MariaDB, pianifica snapshot crittografati di Restic tramite cron e verifica il ripristino senza mettere a rischio il server di produzione.
Configura HAProxy HTTPS, l'inoltro delle intestazioni, i timeout WebSocket e i controlli di integrità per ONLYOFFICE Docs, quindi verifica le modifiche e i salvataggi.
Installa i font personalizzati in ONLYOFFICE Document Server, confronta i mount Docker persistenti con le copie dirette, ricostruisci l'elenco dei font e verifica il risultato.
Diagnosticare i kill di MySQL OOM su Debian 12, verificare i limiti di memoria del VPS, configurare lo swap e ottimizzare la memoria e la concorrenza del database, senza promettere una soluzione universale.
Esporta una singola casella di posta Zimbra Community Edition, convalida il relativo backup TGZ e ripristina gli elementi mancanti senza sovrascrivere la posta esistente.
Consenti solo agli account approvati di avviare stanze Jitsi Meet utilizzando l'autenticazione tramite Keycloak e token, mantenendo al contempo la possibilità per gli ospiti di partecipare quando necessario.
Configura un server VPN WireGuard su Debian 12 per un client remoto. Configura le chiavi, l'inoltro IPv4, il NAT con nftables, l'accesso tramite firewall e i controlli di connessione.
Collega ONLYOFFICE DocSpace ad Active Directory o OpenLDAP, importa utenti e gruppi in modo sicuro, mappa i campi dell'account e pianifica una sincronizzazione affidabile.
Carica un modulo kernel SLES 15 personalizzato senza disabilitare Secure Boot. Fai corrispondere il kernel in esecuzione, firma il file .ko, registra una chiave MOK e verifica il caricamento.
