Diagnosi e risoluzione dei fallimenti di autenticazione SSH

Secure Shell (SSH) è la base dell'amministrazione remota sicura, consentendo l'accesso crittografato a server e dispositivi di rete. Tuttavia, incontrare fallimenti di autenticazione è un'esperienza comune e spesso frustrante per amministratori di sistema e sviluppatori. Questi problemi possono derivare da una miriade di cause, che vanno da semplici errori di battitura a complessi problemi di permessi o errate configurazioni.

Questo articolo funge da guida completa per diagnosticare e risolvere efficacemente i fallimenti di autenticazione SSH. Approfondiremo metodi di risoluzione dei problemi sistematici, sottolineando il ruolo critico dell'output dettagliato lato client e dell'analisi dei log lato server. Comprendendo come interpretare questi indizi diagnostici, sarai equipaggiato per individuare la causa principale della maggior parte dei problemi di autenticazione e ripristinare il tuo accesso remoto sicuro.

Comprensione dei metodi di autenticazione SSH

Prima di addentrarci nella risoluzione dei problemi, è essenziale comprendere i principali metodi di autenticazione impiegati da SSH:

• Autenticazione con password: L'utente fornisce una password, che il server verifica rispetto al suo database utenti o a un servizio di autenticazione esterno (come PAM).
• Autenticazione a chiave pubblica: Questo metodo più sicuro utilizza una coppia di chiavi crittografiche: una chiave privata archiviata sul client e una chiave pubblica corrispondente archiviata sul server. Durante l'autenticazione, il client utilizza la propria chiave privata per dimostrare la propria identità senza mai inviare la chiave privata sulla rete.

I fallimenti di autenticazione possono verificarsi con entrambi i metodi, ma i passaggi per la risoluzione dei problemi spesso differiscono.

Controlli iniziali e insidie comuni

Prima di addentrarci nei log dettagliati, è prudente eseguire alcuni controlli di base, poiché molti problemi sono spesso semplici sviste:

• Nome utente e hostname corretti: Ricontrolla che stai utilizzando il nome utente corretto e l'hostname o l'indirizzo IP esatto del server di destinazione.
• Connettività di rete: Riesci a raggiungere il server? Usa ping per verificare la raggiungibilità di base della rete.
  bash ping example.com
• Stato del servizio SSH: Il server SSH (sshd) è effettivamente in esecuzione sulla macchina di destinazione? Se hai accesso alla console, controllane lo stato.
  bash sudo systemctl status sshd # Per sistemi basati su systemd (la maggior parte dei Linux moderni) sudo service sshd status # Per vecchi sistemi init
• Porta SSH: Il demone SSH è in ascolto sulla porta predefinita (22) o su una porta personalizzata? Se si tratta di una porta personalizzata, dovrai specificarla con -p.
• Regole del firewall: Ci sono firewall (lato client o lato server) che bloccano la porta 22 (o la tua porta SSH personalizzata)? Controlla i firewall del server come ufw, firewalld o i gruppi di sicurezza AWS.
  bash sudo ufw status sudo firewall-cmd --list-all

Diagnostica lato client: sfruttare la modalità dettagliata

Il client SSH offre modalità dettagliate (-v, -vv, -vvv) che forniscono output di debug dettagliati sul processo di connessione e sui tentativi di autenticazione. Questo output è inestimabile per capire perché il client ritiene che l'autenticazione stia fallendo.

Utilizzo dei flag dettagliati

• -v: Output dettagliato.
• -vv: Output più dettagliato.
• -vvv: Output ancora più dettagliato (spesso il più utile per i problemi di autenticazione).

Esempio di comando:

ssh -vvv username@your_server_ip

Interpretazione dell'output dettagliato

Quando esegui ssh in modalità dettagliata, cerca righe chiave che indicano dove sta fallendo il processo di autenticazione:

• debug1: Authentications that can continue:: Questa riga indica quali metodi di autenticazione il server è disposto ad accettare. Se il metodo desiderato (ad esempio, publickey) non è elencato, la configurazione del server lo impedisce.
  debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
• debug1: Offering public key:: Questo indica che il tuo client sta tentando di utilizzare una chiave pubblica specifica per l'autenticazione. Se ti aspetti l'autenticazione a chiave pubblica ma non vedi questo, il tuo client non sta trovando o offrendo la chiave.
  debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:...
• debug3: send_pubkey_test: ... trying private key: /home/user/.ssh/id_rsa: Questo conferma che il client sta tentando di utilizzare una chiave privata specifica.
• debug1: Server accepts key: ...: Questo indicherebbe un'autenticazione a chiave pubblica riuscita dal punto di vista del client. Se non vedi questo, la chiave è stata probabilmente rifiutata dal server.
• debug1: No more authentication methods to try.: Questo appare spesso subito prima di un errore Permission denied e significa che il client ha esaurito tutti i metodi di autenticazione disponibili senza successo.
• debug1: Permission denied (publickey,password).: Questo è l'errore finale lato client, che riassume il rifiuto del server di tutti i tentativi.

Suggerimento: Presta molta attenzione all'ordine dei metodi di autenticazione offerti e accettati. Se viene offerta la publickey ma è immediatamente seguita da una richiesta di password, spesso significa che il server ha rifiutato la chiave pubblica.

Diagnostica lato server: esaminare i log del server SSH

Mentre l'output dettagliato lato client mostra ciò che il client sta tentando di fare, i log del server forniscono informazioni definitive sul perché il server ha rifiutato il tentativo di autenticazione. Questo è spesso il passaggio più critico nell'analisi della causa principale.

Individuazione dei log del server SSH

La posizione dei log del server SSH varia a seconda del sistema operativo:

• Debian/Ubuntu e derivati: /var/log/auth.log
• RHEL/CentOS/Fedora e derivati: /var/log/secure
• Sistemi basati su Systemd (la maggior parte dei Linux moderni): puoi anche usare journalctl.

Visualizzazione e filtraggio dei log del server

Utilizza strumenti come tail o journalctl per monitorare i log in tempo reale o filtrare le voci specifiche di SSH.

Esempi di comandi:

# Per Debian/Ubuntu
sudo tail -f /var/log/auth.log | grep sshd

# Per RHEL/CentOS
sudo tail -f /var/log/secure | grep sshd

# Per sistemi basati su systemd (il modo più robusto per visualizzare i log correnti)
sudo journalctl -u sshd -f

# Per visualizzare tutti i log di sshd dall'inizio (utile se il fallimento è avvenuto prima)
sudo journalctl -u sshd

Voci comuni nei log del server e il loro significato

Cerca messaggi relativi a sshd quando tenti di connetterti. Ecco alcune voci comuni che indicano fallimenti di autenticazione:

• Failed password for user from IP port ssh2: Indica che un tentativo di autenticazione con password è fallito. Questo potrebbe essere dovuto a una password errata, o se all'utente non è permesso di accedere tramite password.
• Authentication refused: bad ownership or modes for directory /home/user/.ssh: Questo è un errore molto comune nell'autenticazione a chiave pubblica. La directory .ssh sul server ha permessi errati.
  • Soluzione: chmod 700 /home/user/.ssh
• Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys: Un altro comune errore di chiave pubblica, che indica che il file authorized_keys ha permessi errati.
  • Soluzione: chmod 600 /home/user/.ssh/authorized_keys
• sshd[PID]: error: Permissions 0777 for '/home/user/.ssh/authorized_keys' are too open.: Dichiara esplicitamente il problema con modalità file eccessivamente permissive. SSH è molto rigoroso riguardo ai permessi per motivi di sicurezza.
• User username from IP not allowed because not listed in AllowUsers: All'utente non è consentito l'accesso tramite SSH secondo la direttiva AllowUsers in /etc/ssh/sshd_config.
• User username from IP not allowed because listed in DenyUsers: All'utente viene negato esplicitamente l'accesso SSH da DenyUsers.
• input_userauth_request: invalid user username: Il nome utente fornito non esiste sul server.
• Publickey authentication refused: authenticate using identity file.: Questo di solito significa che la chiave pubblica presentata dal client non corrisponde a nessuna chiave nel file authorized_keys del server per quell'utente, o che il formato della chiave è errato.
• Maximum authentication attempts exceeded for user from IP: Il client ha tentato troppi metodi di autenticazione o ha inviato troppe credenziali errate. Controllato da MaxAuthTries in sshd_config.
• Connection closed by authenticating user IP port 22 [preauth]: Questo può verificarsi se non è stato trovato alcun metodo di autenticazione accettabile, o se il client chiude bruscamente la connessione dopo un fallimento.

Scenari comuni di fallimento di autenticazione e soluzioni

Categorizziamo i fallimenti comuni e i relativi rimedi specifici.

1. Fallimenti dell'autenticazione con password

• Password errata: Il problema più diretto. Ricontrolla la tua password. Presta attenzione ai layout della tastiera, a Bloc Maiusc o Bloc Num.
• Utente non autorizzato: Il file sshd_config (/etc/ssh/sshd_config) potrebbe limitare l'accesso per determinati utenti.
  • PermitRootLogin no: Impedisce l'accesso root (altamente raccomandato per la sicurezza).
  • AllowUsers username1 username2: Solo gli utenti specificati possono accedere.
  • DenyUsers username: Gli utenti specificati non possono accedere.
  • AllowGroups groupname: Solo gli utenti nei gruppi specificati possono accedere.
  • Soluzione: Modifica le direttive sshd_config e riavvia sshd.
• Problemi PAM: Se il server utilizza moduli di autenticazione collegabili (PAM), problemi con la configurazione PAM possono impedire l'autenticazione con password. Controlla /var/log/auth.log per errori specifici di PAM. Questo è meno comune per le configurazioni SSH di base.

2. Fallimenti dell'autenticazione a chiave pubblica

L'autenticazione a chiave pubblica è spesso più sicura ma soggetta a più errori di configurazione.

• Permessi file/directory errati (lato server): Questa è di gran lunga la causa più comune. SSH richiede permessi rigorosi per ~/.ssh e ~/.ssh/authorized_keys per motivi di sicurezza.
  • ~: La directory home dell'utente non deve essere scrivibile da tutti (chmod 755 ~ è solitamente sicuro).
  • ~/.ssh: Deve essere 700 (rwx solo per il proprietario).
    bash chmod 700 ~/.ssh
  • ~/.ssh/authorized_keys: Deve essere 600 (rw solo per il proprietario).
    bash chmod 600 ~/.ssh/authorized_keys
  • Il proprietario di questi file e directory deve essere l'utente che tenta di accedere.
    bash sudo chown -R username:username ~/.ssh
• Contenuto authorized_keys errato: La chiave pubblica in ~/.ssh/authorized_keys potrebbe essere corrotta, avere caratteri extra o essere in formato errato. Ogni chiave dovrebbe trovarsi su una singola riga. Un modo rapido per garantire il formato corretto è utilizzare ssh-copy-id dal client.
  bash ssh-copy-id -i ~/.ssh/id_rsa.pub username@your_server_ip
  Per verificare l'impronta digitale della tua chiave pubblica sul lato client, usa: ssh-keygen -l -f ~/.ssh/id_rsa.pub
• Il client non offre la chiave: La chiave privata potrebbe non trovarsi nella posizione predefinita (~/.ssh/id_rsa), non essere caricata in ssh-agent, o non averla specificata con -i.
  • Soluzione: Assicurati che la tua chiave privata sia id_rsa (o id_ed25519, ecc.) in ~/.ssh e abbia permessi 600. In caso contrario, specificala:
    bash ssh -i /path/to/your/private_key username@your_server_ip
  • Se usi ssh-agent, assicurati che la tua chiave sia aggiunta:
    bash eval "$(ssh-agent -s)" ssh-add ~/.ssh/your_private_key
• sshd_config che non consente l'autenticazione a chiave pubblica: Il demone SSH del server potrebbe essere configurato per non consentire l'autenticazione a chiave pubblica.
  • Controlla PubkeyAuthentication yes in /etc/ssh/sshd_config.
  • Controlla AuthorizedKeysFile .ssh/authorized_keys per assicurarti che punti al file corretto. Il valore predefinito è solitamente corretto.
  • Soluzione: Imposta PubkeyAuthentication yes e riavvia sshd.
• Interferenza SELinux/AppArmor: Sui sistemi con SELinux o AppArmor, questi moduli di sicurezza possono talvolta impedire a SSH di accedere alle directory home degli utenti o ai file .ssh, anche se i permessi dei file sono corretti. Controlla i log di audit (/var/log/audit/audit.log o sudo ausearch -m AVC -ts recent) per indizi. Questo è uno scenario avanzato.

3. Connessione rifiutata o timeout

Sebbene non siano strettamente fallimenti di "autenticazione", questi spesso precedono i tentativi di autenticazione e impediscono loro persino di iniziare.

• Firewall bloccante: Controlla i firewall sia sul client (ad esempio, firewall locale del sistema operativo) che sul server (ad esempio, ufw, firewalld, gruppi di sicurezza cloud, ACL di rete). Assicurati che la porta 22 (o la porta personalizzata) sia aperta.
• Server SSH non in esecuzione: Il servizio sshd potrebbe non essere attivo o essere crashato.
• Porta/IP errato: Tentativo di connettersi alla porta o all'indirizzo IP errato.

Suggerimenti generali per il debug

• Controlla sshd_config: Rivedi sempre /etc/ssh/sshd_config sul server per eventuali impostazioni non predefinite che potrebbero interferire. Dopo aver apportato modifiche, riavvia sempre il demone SSH: sudo systemctl restart sshd (o sudo service sshd restart).
• Testa con un nuovo utente/chiave: Se possibile, crea un nuovo utente e una nuova coppia di chiavi pubblica/privata. Prova ad autenticarti con questa nuova configurazione. Se funziona, il problema è specifico della configurazione dell'utente originale.
• Isola il problema: Prova a connetterti da un computer client diverso. Se funziona, il problema è specifico del client. Se fallisce da più client, il problema è specifico del server.
• Aumenta LogLevel (lato server): Per un debug approfondito, puoi impostare temporaneamente LogLevel DEBUG in /etc/ssh/sshd_config e riavviare sshd. Ricorda di ripristinare questa impostazione dopo la risoluzione dei problemi, poiché i log di debug possono essere molto dettagliati e consumare spazio su disco.

Conclusione

La diagnosi dei fallimenti di autenticazione SSH richiede un approccio sistematico, che combina l'output dettagliato lato client con l'analisi dei log lato server. Esaminando meticolosamente gli indizi forniti da ssh -vvv e i log del demone SSH (auth.log o secure), puoi individuare efficacemente il punto esatto di fallimento, che si tratti di una password errata, di una chiave pubblica mal configurata, di permessi di file restrittivi o di un'impostazione lato server.

Ricorda di iniziare con i controlli semplici, quindi passa all'output dettagliato lato client e infine sfrutta le intuizioni definitive dai log del server. Con queste tecniche, sarai ben equipaggiato per risolvere anche i problemi di autenticazione SSH più complessi e mantenere un accesso sicuro ai tuoi sistemi remoti.