Risoluzione dei problemi di autorizzazione SSH: errore 'Permission Denied (publickey)'

Permission denied (publickey) significa che il server era raggiungibile, ma non ha accettato alcun tentativo di autenticazione tramite chiave pubblica per l'utente che hai provato. Questo restringe il problema. Non stai più eseguendo il debug di routing, DNS o se la porta SSH è aperta. Stai eseguendo il debug dell'identità: il nome utente, la chiave privata offerta dal tuo client, la chiave pubblica memorizzata sul server e le regole del server che decidono se quel login è consentito.

Il comando più rapido e utile è:

ssh -vvv utente@indirizzo_server

Cerca Authenticating to ... as 'utente', poi cerca Offering public key. Se la chiave prevista non viene offerta, correggi il client. Se la chiave prevista viene offerta e rifiutata, correggi lato server authorized_keys, proprietà, permessi o la politica del demone SSH.

Cause comuni dell'errore 'Permission Denied (publickey)'

L'errore "Permission Denied (publickey)" può derivare da diversi problemi di configurazione. Identificare la causa principale spesso comporta il controllo sistematico dei seguenti componenti:

• Permessi file errati: SSH è molto sensibile ai permessi di file e directory per motivi di sicurezza. Permessi errati sulla tua directory ~/.ssh locale, sul file della chiave privata o sulla directory ~/.ssh lato server e sul file authorized_keys possono impedire l'autenticazione.
• Voce authorized_keys mancante o errata: Il file authorized_keys del server deve contenere la chiave pubblica corretta per l'utente con cui stai tentando di accedere. Se la chiave è mancante, malformata o associata all'utente sbagliato, l'autenticazione fallirà.
• Associazione errata della coppia di chiavi: Il tuo client SSH potrebbe offrire la chiave privata sbagliata, oppure il server potrebbe non avere la corrispondente chiave pubblica elencata nel file authorized_keys.
• Problemi con l'agente SSH: Se stai utilizzando un agente SSH, potrebbe non essere caricato correttamente con la tua chiave privata o potrebbe essere configurato in modo errato.
• Configurazione SSH lato server: Sebbene meno comune per questo errore specifico, la configurazione del demone SSH del server (sshd_config) potrebbe avere restrizioni specifiche sull'autenticazione tramite chiave pubblica.

Guida alla risoluzione dei problemi passo-passo

Approfondiamo i passaggi pratici per diagnosticare e risolvere questi problemi.

1. Verifica la chiave privata locale e i permessi

La tua configurazione SSH locale è il primo posto da controllare. Assicurati che la tua chiave privata sia accessibile e abbia i permessi corretti.

Verifica dell'esistenza della chiave privata

La tua chiave privata si trova spesso in ~/.ssh/id_ed25519 o ~/.ssh/id_rsa, ma molti team usano nomi specifici per progetto. Elenca le tue chiavi:

ls -la ~/.ssh

Non caricare o incollare una chiave privata in authorized_keys. Il server ha bisogno del contenuto del file .pub, non della chiave privata.

Verifica dei permessi dei file locali

La directory ~/.ssh e il tuo file di chiave privata dovrebbero avere permessi restrittivi per prevenire accessi non autorizzati.

• Directory ~/.ssh: Dovrebbe essere 700 (drwx------).
• File della chiave privata (es. id_rsa): Dovrebbe essere 600 (-rw-------).

Usa il comando chmod per impostare i permessi corretti:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa

Suggerimento: Se stai usando un nome di chiave diverso, sostituisci id_rsa con il nome effettivo del tuo file di chiave privata.

Se stai testando una chiave specifica, forzala:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_prod utente@indirizzo_server

Questo impedisce al tuo agente di offrire prima una lunga lista di chiavi non correlate.

2. Verifica la configurazione lato server di authorized_keys

Questa è spesso la causa più comune. Il server deve avere la tua chiave pubblica elencata correttamente per l'utente con cui stai tentando di autenticarti.

Accesso al server (se possibile)

Se puoi ancora accedere al server tramite un altro metodo (es. autenticazione tramite password, un altro account utente o una console), accedi per controllare il file authorized_keys.

Verifica della posizione del file authorized_keys

Il file authorized_keys si trova tipicamente in ~/.ssh/authorized_keys all'interno della home directory dell'utente con cui stai tentando di accedere.

Verifica dei permessi dei file lato server

Analogamente al lato client, i permessi lato server sono critici:

• Directory ~/.ssh sul server: Dovrebbe essere 700 (drwx------).
• File authorized_keys sul server: Dovrebbe essere 600 (-rw-------).

Assicurati che questi permessi siano impostati correttamente sul server:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Verifica anche la proprietà. La directory .ssh e il file authorized_keys dovrebbero normalmente appartenere all'account con cui stai accedendo:

chown -R tuo_utente:tuo_utente ~/.ssh
ls -ld ~ ~/.ssh ~/.ssh/authorized_keys

Se StrictModes è abilitato in sshd_config, OpenSSH potrebbe rifiutare le chiavi quando la home directory o il percorso .ssh sono scrivibili da utenti errati.

Verifica del contenuto di authorized_keys

Apri il file ~/.ssh/authorized_keys usando un editor di testo (es. nano, vim). Ogni chiave pubblica dovrebbe essere su una singola riga. Assicurati che la chiave pubblica che intendi usare sia presente e formattata correttamente. Dovrebbe iniziare con ssh-rsa, ssh-ed25519 o simile, seguita da una lunga stringa di caratteri e opzionalmente un commento.

Esempio di voce authorized_keys:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQD... tua_stringa_chiave_pubblica utente@hostname

Non aggiungere la tua chiave privata a authorized_keys. Solo la chiave pubblica dovrebbe essere qui.

3. Assicurati che sia stata aggiunta la chiave pubblica corretta

È possibile che sia stata copiata la chiave pubblica sbagliata o che la chiave pubblica sul server non corrisponda alla tua chiave privata locale.

Recupero della tua chiave pubblica locale

La tua chiave pubblica è la controparte della tua chiave privata. Puoi visualizzarla usando il comando ssh-keygen:

cat ~/.ssh/id_rsa.pub

Questo comando restituirà la tua chiave pubblica. Confronta attentamente questo output con la voce nel file ~/.ssh/authorized_keys del server. Anche un singolo errore di battitura o un carattere mancante causerà il fallimento dell'autenticazione.

Per un confronto più pulito, stampa la chiave pubblica derivata dalla chiave privata che stai cercando di usare:

ssh-keygen -y -f ~/.ssh/id_ed25519_prod

Quell'output dovrebbe corrispondere a una riga nel file authorized_keys dell'utente remoto.

Suggerimento: Un modo rapido per aggiungere la tua chiave pubblica se hai accesso tramite password al server è usare ssh-copy-id.

ssh-copy-id utente@indirizzo_server

Questo comando aggiunge automaticamente la tua chiave pubblica predefinita (~/.ssh/id_rsa.pub) al file ~/.ssh/authorized_keys sul server remoto e imposta i permessi corretti.

4. Specifica la chiave privata corretta (se non è quella predefinita)

Se stai usando una chiave privata non predefinita (es. ~/.ssh/mia_altra_chiave), devi dire al tuo client SSH quale chiave usare.

Usando il flag -i

Puoi specificare il file di identità (chiave privata) con l'opzione -i:

ssh -i ~/.ssh/mia_altra_chiave utente@indirizzo_server

Configurando ~/.ssh/config

Per comodità, puoi configurare il tuo client SSH per usare sempre una chiave specifica per un dato host:

Crea o modifica il file ~/.ssh/config sulla tua macchina locale e aggiungi una voce come questa:

Host alias_server
  HostName indirizzo_server_o_dominio
  User tuo_nome_utente
  IdentityFile ~/.ssh/mia_altra_chiave
  IdentitiesOnly yes

Poi puoi connetterti semplicemente usando:

ssh alias_server

5. Controlla lo stato dell'agente SSH

Se ti affidi a un agente SSH per gestire le tue chiavi, assicurati che sia in esecuzione e che abbia caricato la tua chiave.

Verifica se l'agente è in esecuzione

echo "$SSH_AUTH_SOCK"

Se questo restituisce un percorso, l'agente è probabilmente in esecuzione. Se è vuoto, potresti doverne avviare uno.

Aggiunta della chiave all'agente

Se la tua chiave non è caricata, aggiungila:

ssh-add ~/.ssh/id_rsa

Se ti viene richiesta una passphrase, inseriscila. Puoi verificare quali chiavi sono state aggiunte con ssh-add -l.

Se ssh-add -l mostra molte chiavi non correlate e il server si disconnette dopo diversi tentativi, rimuovi le vecchie chiavi dall'agente o usa IdentitiesOnly yes per quell'host.

6. Debug con modalità verbosa

SSH ha una modalità verbosa (-v, -vv o -vvv per livelli crescenti di dettaglio) che può fornire indizi preziosi su dove il processo di autenticazione sta fallendo.

ssh -vvv utente@indirizzo_server

Esamina l'output per messaggi relativi all'autenticazione tramite chiave, all'offerta di chiavi e alle risposte del server. Questo spesso indica direttamente il problema.

Esempio di snippet di output verboso che indica un fallimento publickey:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: read PEM private key file /home/user/.ssh/id_rsa
debug1: failed to use sshkey: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

Questo output significa che il client ha provato id_rsa, il server non l'ha accettata e il client è passato al metodo successivo consentito.

7. Revisione di sshd_config lato server (Avanzato)

Controlla /etc/ssh/sshd_config e qualsiasi file in /etc/ssh/sshd_config.d/. Conferma che l'autenticazione tramite chiave pubblica sia abilitata:

PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
```n
Poi cerca blocchi `Match` vicino alla fine del file. Un blocco successivo `Match User`, `Match Group` o `Match Address` può sovrascrivere le impostazioni precedenti per l'esatto account che stai testando.

Dopo qualsiasi modifica, convalida la sintassi prima di ricaricare:

```bash
sudo sshd -t
sudo systemctl reload sshd

Alcuni sistemi usano ssh come nome del servizio invece di sshd.

Un ordine di risoluzione dei problemi affidabile

Usa l'output verboso per evitare di indovinare. Prima conferma il nome utente. Poi conferma che il client offra la chiave privata che ti aspetti. Poi conferma che la chiave pubblica corrispondente sia nel file authorized_keys dell'utente di destinazione. Poi controlla proprietà e permessi. Solo dopo che questi sono puliti dovresti dedicare tempo a sshd_config, blocchi Match, contesti SELinux o restrizioni dell'account.

Questo ordine risolve la maggior parte dei casi di Permission denied (publickey) senza modifiche casuali e ti impedisce di indebolire la sicurezza SSH solo per ottenere un login urgente.