Diagnosi e Risoluzione dei Fallimenti di Autenticazione SSH

Secure Shell (SSH) è il fondamento 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 configurazioni errate.

Questo articolo funge da guida completa per diagnosticare e risolvere efficacemente i fallimenti di autenticazione SSH. Approfondiremo metodi sistematici di risoluzione dei problemi, enfatizzando il ruolo critico dell'output verbose lato client e dell'analisi dei log lato server. Comprendendo come interpretare questi indizi diagnostici, sarai in grado di 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 immergerci nella risoluzione dei problemi, è essenziale comprendere i metodi di autenticazione primari utilizzati da SSH:

• Autenticazione tramite Password: L'utente fornisce una password, che il server verifica rispetto al proprio database utenti o a un servizio di autenticazione esterno (come PAM).
• Autenticazione tramite Chiave Pubblica: Questo metodo più sicuro utilizza una coppia di chiavi crittografiche: una chiave privata memorizzata sul client e una chiave pubblica corrispondente memorizzata sul server. Durante l'autenticazione, il client utilizza la sua 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 verbose, è prudente eseguire alcuni controlli di base, poiché molti problemi sono spesso semplici sviste:

• Nome Utente e Hostname Corretti: Ricontrolla di utilizzare il nome utente corretto e l'hostname esatto o l'indirizzo IP del server di destinazione.
• Connettività di Rete: Riesci a raggiungere il server? Usa nc -vz host 22 o ssh -vvv per testare la raggiungibilità di SSH. ping può aiutare, ma molti server bloccano ICMP anche quando SSH funziona.

  ping example.com
  

• Stato del Servizio SSH: Il server SSH (sshd) è effettivamente in esecuzione sulla macchina di destinazione? Se hai accesso alla console, controlla il suo stato.

  sudo systemctl status sshd # Per sistemi basati su systemd (la maggior parte dei Linux moderni)
  sudo service sshd status    # Per sistemi init più vecchi
  

• Porta SSH: Il demone SSH è in ascolto sulla porta predefinita (22) o su una porta personalizzata? Se è 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.

  sudo ufw status
  sudo firewall-cmd --list-all
  

Diagnostica Lato Client: Sfruttare la Modalità Verbose

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

Utilizzo dei Flag Verbose

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

Comando di Esempio:

ssh -vvv username@indirizzo_server

Interpretazione dell'Output Verbose

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

• debug1: Authentications that can continue:: Questa riga ti dice quali metodi di autenticazione il server è disposto ad accettare. Se il tuo metodo desiderato (ad es., 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:: Indica che il tuo client sta tentando di utilizzare una chiave pubblica specifica per l'autenticazione. Se ti aspetti l'autenticazione tramite chiave pubblica ma non vedi questo, il tuo client non trova o non offre 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: Conferma che il client sta tentando di utilizzare una chiave privata specifica.
• debug1: Server accepts key: ...: Indicherebbe un'autenticazione tramite 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.: 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 publickey viene offerto ma subito seguito da una richiesta di password, spesso significa che il server ha rifiutato la chiave pubblica.

Diagnostica Lato Server: Esame dei Log del Server SSH

Mentre l'output verbose lato client mostra cosa il client sta cercando di fare, i log del server forniscono informazioni definitive sul motivo per cui il server ha rifiutato il tentativo di autenticazione. Questo è spesso il passo più critico nell'analisi delle cause principali.

Individuazione dei Log del Server SSH

La posizione dei log del server SSH varia in base al 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

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

Comandi di Esempio:

# 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 (modo più robusto per visualizzare i log correnti)
sudo journalctl -u sshd -f

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

Voci Comuni dei Log del Server e Loro Significati

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 tramite password è fallito. Potrebbe essere dovuto a una password errata o se all'utente non è consentito l'accesso tramite password.
• Authentication refused: bad ownership or modes for directory /home/user/.ssh: Questo è un errore molto comune nell'autenticazione tramite 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 errore comune della 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à di file eccessivamente permissive. SSH è molto severo 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 è esplicitamente negato l'accesso SSH da DenyUsers.
• input_userauth_request: invalid user username: Il nome utente fornito non esiste sul server.
• Failed publickey for user o chiavi offerte ripetutamente seguite da password: la chiave pubblica presentata dal client non corrispondeva a una chiave accettata per quell'utente, o il server ha rifiutato la chiave a causa di permessi o policy.
• Maximum authentication attempts exceeded for user from IP: Il client ha provato 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]: 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 dell'Autenticazione e Soluzioni

Classifichiamo i fallimenti comuni e le loro soluzioni specifiche.

1. Fallimenti dell'Autenticazione tramite Password

• Password Errata: Il problema più semplice. Ricontrolla la tua password. Fai attenzione ai layout della tastiera, al Blocco Maiuscole o al Blocco Numerico.
• Utente Non Consentito: Il file sshd_config (/etc/ssh/sshd_config) potrebbe limitare l'accesso per determinati utenti.
  • PermitRootLogin no: Impedisce l'accesso come 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 in sshd_config e riavvia sshd.
• Problemi PAM: Se il server utilizza Pluggable Authentication Modules (PAM), i problemi con la configurazione PAM possono impedire l'autenticazione tramite password. Controlla /var/log/auth.log per errori specifici di PAM. Questo è meno comune per le configurazioni SSH di base.

2. Fallimenti dell'Autenticazione tramite Chiave Pubblica

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

• Permessi Errati di File/Directory (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 dovrebbe essere scrivibile da tutti (chmod 755 ~ è generalmente sicuro).
  • ~/.ssh: Deve essere 700 (rwx solo per il proprietario).

    chmod 700 ~/.ssh
    

  • ~/.ssh/authorized_keys: Deve essere 600 (rw solo per il proprietario).

    chmod 600 ~/.ssh/authorized_keys
    

  • Il proprietario di questi file e directory deve essere l'utente che tenta di accedere.

    sudo chown -R username:username ~/.ssh
    

• Contenuto Errato di authorized_keys: La chiave pubblica in ~/.ssh/authorized_keys potrebbe essere corrotta, avere caratteri extra o essere in un formato errato. Ogni chiave dovrebbe essere su una singola riga. Un modo rapido per garantire il formato corretto è usare ssh-copy-id dal client.

  ssh-copy-id -i ~/.ssh/id_rsa.pub username@indirizzo_server
  

  Per verificare l'impronta della tua chiave pubblica lato client, usa: ssh-keygen -l -f ~/.ssh/id_rsa.pub
• Client che Non Offre la Chiave: La chiave privata potrebbe non trovarsi nella posizione predefinita (~/.ssh/id_rsa), non essere caricata in ssh-agent o non essere stata 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:

    ssh -i /percorso/della/tua/chiave_privata username@indirizzo_server
    

  • Se usi ssh-agent, assicurati che la tua chiave sia aggiunta:

    eval "$(ssh-agent -s)"
    ssh-add ~/.ssh/tua_chiave_privata
    

• sshd_config che Disabilita l'Autenticazione tramite Chiave Pubblica: Il demone SSH del server potrebbe essere configurato per disabilitare l'autenticazione tramite 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 è generalmente corretto.
  • Soluzione: Imposta PubkeyAuthentication yes e riavvia sshd.
• Interferenza SELinux/AppArmor: Su sistemi con SELinux o AppArmor, questi moduli di sicurezza possono talvolta bloccare SSH dall'accesso 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", spesso precedono i tentativi di autenticazione e ne impediscono l'avvio.

• Firewall che Blocca: Controlla i firewall sia sul client (ad es., firewall del sistema operativo locale) che sul server (ad es., 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 Errati: Tentativo di connettersi alla porta o all'indirizzo IP sbagliato.

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).
• Prova 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 una macchina client diversa. 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 verbosi e consumare spazio su disco.

Conclusione

Usa ssh -vvv per vedere cosa offre il tuo client, poi controlla i log del server per scoprire perché sshd lo ha rifiutato. La maggior parte dei fallimenti delle chiavi pubbliche si riduce a una chiave sbagliata, una voce authorized_keys mancante, permessi dei file rigorosi o una regola sshd_config che blocca l'utente o il metodo.