Centro di Conoscenza DevOps
Centro di Conoscenza DevOps

Risoluzione dei problemi comuni di SSH: errori di 'Permesso negato' e problemi di connessione

Padroneggia la connettività SSH imparando a risolvere gli errori di 'Permesso negato'. Questa guida spiega come utilizzare la modalità dettagliata (`-vvv`) per diagnosticare i fallimenti di autenticazione, correggere le autorizzazioni dei file sul server critiche (`700`/`600`) per le directory `.ssh` e verificare le impostazioni di configurazione del server necessarie in `sshd_config` per un accesso remoto affidabile.

38 visualizzazioni

Risoluzione dei problemi comuni degli errori SSH 'Permission Denied' e dei problemi di connessione

Secure Shell (SSH) è la pietra angolare della gestione remota dei server, fornendo una comunicazione crittografata per l'accesso e il controllo dei sistemi remoti. Sebbene sia affidabile, la configurazione di SSH, specialmente con l'autenticazione basata su chiavi, può talvolta portare a frustranti errori di connessione. Il colpevole più comune è il temuto errore Permission denied.

Questa guida completa ti accompagnerà attraverso la diagnosi e la risoluzione degli errori SSH più frequenti. Ci concentreremo in particolare sulla comprensione delle cause principali dietro Permission denied (publickey) e affronteremo le insidie comuni relative alle autorizzazioni dei file, alla configurazione errata e alle discrepanze nella configurazione client/server. Padroneggiare questi passaggi di risoluzione dei problemi garantirà un accesso sicuro e affidabile alla tua infrastruttura remota.

Comprendere il Flusso di Autenticazione SSH

Prima di risolvere i problemi, è fondamentale capire come SSH autentica gli utenti. Quando tenti di connetterti, il server controlla tipicamente le credenziali nel seguente ordine (a seconda della configurazione):

  1. Autenticazione tramite chiave pubblica: Il client presenta una chiave pubblica e il server verifica se la chiave privata corrispondente è valida e corrisponde a una chiave autorizzata (file authorized_keys).
  2. Autenticazione tramite password: Se l'autenticazione tramite chiave fallisce o è disabilitata, il server richiede una password.

Quando ricevi Permission denied, significa quasi sempre che il server ha rifiutato le tue credenziali durante il passaggio 1 o 2.

Diagnosi dei problemi di connessione: la potenza della modalità Verbose

Lo strumento più efficace per diagnosticare i problemi SSH è eseguire il client in modalità verbose. Aggiungendo i flag -v, -vv o -vvv, il client visualizza informazioni di debug dettagliate sul processo di negoziazione.

Utilizzo dei flag Verbose

Usa la seguente struttura di comando:

ssh -vvv utente@host_remoto

Cosa cercare nell'output:

  • Scambio di chiavi (Key Exchange): Cerca le righe che indicano quali metodi di autenticazione il client ha tentato (ad esempio, Offering RSA key: /path/to/id_rsa).
  • Risposta del server: Presta molta attenzione ai messaggi di rifiuto del server. Se l'output mostra che il server sta controllando le chiavi ma non riesce a trovare corrispondenze, il problema è probabilmente legato alla configurazione delle chiavi o alle autorizzazioni sul lato server.
  • Richiesta di password: Se l'output salta i controlli delle chiavi e chiede immediatamente una password, l'autenticazione tramite chiave potrebbe essere disabilitata sul server.

Risoluzione di Permission denied (publickey)

Questo errore dichiara esplicitamente che il server ha rifiutato la credenziale della chiave pubblica fornita. La soluzione di solito risiede nelle autorizzazioni o nell'accoppiamento delle chiavi.

1. Controllare le autorizzazioni del file chiave (lato client)

Per motivi di sicurezza, i client SSH sono molto severi riguardo alle autorizzazioni sul tuo file chiave privata (ad esempio, ~/.ssh/id_rsa). Se questi file sono troppo aperti, il client rifiuterà di utilizzarli.

Correzione attuabile (Client): Assicurati che la tua chiave privata sia leggibile solo da te.

chmod 600 ~/.ssh/id_rsa

2. Verificare l'esistenza della chiave e l'uso corretto della chiave

Assicurati di connetterti con il file di identità corretto, specialmente se utilizzi chiavi non standard o coppie di chiavi multiple.

Correzione attuabile (Client): Specifica la chiave privata corretta utilizzando il flag -i.

ssh -i /path/to/your/specific_private_key utente@host_remoto

3. Autorizzazioni e proprietà lato server

Questa è la fonte di errore più comune. SSH impone autorizzazioni rigorose per directory e file sul server per l'utente con cui stai tentando di accedere.

Percorso sul Server Autorizzazioni richieste Proprietario
Directory ~/.ssh 700 (rwx------) Utente
File ~/.ssh/authorized_keys 600 (rw-------) Utente

Correzione attuabile (Server): Accedi tramite console o autenticazione tramite password (se abilitata) ed esegui questi comandi:

# Imposta le autorizzazioni della directory
chmod 700 ~/.ssh

# Imposta le autorizzazioni di authorized_keys
chmod 600 ~/.ssh/authorized_keys

# Verifica la proprietà (sostituisci 'myuser' con il nome utente effettivo)
chown -R myuser:myuser ~/.ssh

Avviso: Se le autorizzazioni sulla directory home dell'utente (~/) sono troppo ampie (ad esempio, scrivibili dal gruppo o da altri), anche SSH potrebbe fallire per motivi di sicurezza. Mira a 755 o più restrittive su ~/ se i problemi persistono.

4. Confermare che la chiave sia effettivamente aggiunta

Assicurati che la stringa della chiave pubblica sul client corrisponda esattamente a ciò che è incollato nel file ~/.ssh/authorized_keys del server. Un carattere mancante o uno spazio finale causerà un errore di autenticazione.

Suggerimento: Quando aggiungi una chiave, usa ssh-copy-id se disponibile, poiché gestisce automaticamente autorizzazioni e formattazione:

ssh-copy-id utente@host_remoto

Risoluzione dei problemi relativi ai file di configurazione (sshd_config)

Se chiavi e autorizzazioni sono corrette, il problema risiede spesso nel file di configurazione del demone SSH, solitamente situato in /etc/ssh/sshd_config sul server.

1. Controllare i metodi di autenticazione

Assicurati che l'autenticazione tramite chiave pubblica sia esplicitamente consentita.

Controllo della configurazione: Cerca le seguenti righe e assicurati che non siano commentate (#) e impostate correttamente:

PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

2. Stato dell'autenticazione tramite password

Se ti affidi temporaneamente all'accesso tramite password, verifica che sia abilitato. Se è impostato su no, devi usare le chiavi.

PasswordAuthentication yes

3. PermitRootLogin

Se stai tentando di accedere come root, assicurati che sia consentito. La migliore pratica è generalmente accedere come utente standard e utilizzare sudo, ma per la risoluzione dei problemi, puoi controllare questa impostazione:

PermitRootLogin yes

Passaggio cruciale: Dopo qualsiasi modifica a /etc/ssh/sshd_config, devi riavviare il servizio SSH affinché le modifiche abbiano effetto:
bash sudo systemctl restart sshd # Oppure service ssh restart

Altri errori di connessione comuni

Sebbene i problemi relativi alle chiavi siano primari, altri errori possono bloccare l'accesso:

A. Connessione scaduta (Connection Timed Out)

Ciò di solito significa che il client non è riuscito a raggiungere affatto il server, indicando un problema di rete, non un problema di autenticazione.

Possibili cause:
* Il server è spento o irraggiungibile.
* Un firewall (locale o di rete) sta bloccando la connessione sulla porta 22 (o sulla porta SSH personalizzata).
* Indirizzo IP o nome host errato.

Risoluzione dei problemi: Usa ping per controllare la connettività di base e telnet o nc (netcat) per verificare se la porta è aperta:

# Controlla se la porta 22 è raggiungibile
telnet host_remoto 22

B. Nessun percorso verso l'host (No Route to Host)

Simile al timeout, questo è un problema di infrastruttura di rete. Il client non riesce a trovare un percorso verso l'indirizzo IP del server. Controlla le tabelle di routing, lo stato della VPN o assicurati che il server remoto abbia un'interfaccia di rete valida attiva.

C. Il server ha rifiutato la nostra chiave (Server Refused Our Key)

Se l'output verbose mostra che il server sta attivamente rifiutando le chiavi ma hai verificato il file authorized_keys, controlla i contesti di sicurezza SELinux o AppArmor sul server. Questi moduli di sicurezza possono sovrascrivere le autorizzazioni dei file e bloccare l'accesso SSH se i contesti non sono corretti.

Riepilogo delle migliori pratiche

  1. Utilizzare sempre la modalità Verbose (-vvv) per la diagnosi.
  2. Sicurezza delle chiavi client: Assicurati che le chiavi private siano impostate su 600 (chmod 600).
  3. Integrità dei file server: Verifica che ~/.ssh sia 700 e authorized_keys sia 600.
  4. Riavviare il demone: Riavvia sempre sshd dopo aver modificato /etc/ssh/sshd_config.
  5. Utilizzare ssh-copy-id ogni volta che è possibile per automatizzare il deployment delle chiavi.