Come risolvere "Permission denied (publickey)" via SSH

Provi ad accedere, ti aspetti un semplice prompt del terminale, e invece SSH ti chiude la porta in faccia con Permission denied (publickey).

Versione breve: Permission denied (publickey) significa che il server accetta solo l’accesso con chiave SSH, ma non ha accettato la chiave che il tuo computer ha proposto. Di solito la soluzione è una di queste cinque cose: usare l’utente giusto, usare la chiave privata giusta, assicurarti che la chiave pubblica sia sul server, sistemare i permessi dei file, oppure confermare che l’accesso con chiave SSH sia abilitato per quell’account.

Perché SSH dice "Permission denied (publickey)"?

SSH è lo strumento di accesso remoto sicuro che permette al tuo computer di parlare con il tuo server. Un accesso con chiave pubblica funziona come una coppia serratura-chiave.

Il server conserva la metà pubblica della chiave in un file chiamato authorized_keys. Il tuo computer conserva la metà privata. Quando ti connetti, SSH chiede: “Puoi dimostrare di possedere la chiave privata corrispondente?”

La stringa di errore Permission denied (publickey) significa che quella prova è fallita. Non vuol dire sempre che la tua password sia sbagliata. In molte configurazioni server, le password non vengono accettate affatto. Il server sta dicendo: “Apro solo per una chiave conosciuta, e non ho riconosciuto la tua.”

Può succedere anche quando sei vicinissimo alla soluzione. Un nome utente sbagliato, un file messo nel posto sbagliato o un’impostazione dei permessi troppo aperta possono far sembrare non valida una chiave perfettamente valida.

Cosa dovresti controllare per prima cosa?

Inizia dai dettagli noiosi. I problemi SSH spesso nascono da una piccola discrepanza, come provare ad aprire la porta di casa con la chiave del garage.

Per prima cosa, controlla il nome utente. Non ti stai collegando solo a una macchina: ti stai collegando come un utente specifico su quella macchina. root, ubuntu, debian e il tuo utente applicativo sono identità diverse. Una chiave che funziona per un utente potrebbe non funzionare per un altro.

Secondo, controlla che tu ti stia collegando all’indirizzo del server giusto. Se hai cambiato DNS di recente, hai cambiato provider o hai ricreato il server da zero, il tuo terminale potrebbe raggiungere una macchina diversa da quella che pensi. Se il routing del dominio fa parte della confusione, la nostra guida su come collegare un dominio al tuo server spiega i vari pezzi in modo semplice.

Terzo, controlla quale chiave privata sta offrendo il tuo client SSH. Molte persone accumulano diverse chiavi nel tempo: una per GitHub, una per il portatile di lavoro, una da un vecchio server. SSH potrebbe provare quella sbagliata, a meno che tu non gli dica quale chiave appartiene a questo server.

Un modo utile per pensarci: il nome utente è il nome sulla cassetta della posta, l’indirizzo del server è l’indirizzo della via, e la chiave privata è la chiave fisica che hai in mano. Tutti e tre devono corrispondere.

Quali sono le cause comuni di Permission denied (publickey)?

La causa più comune è una chiave pubblica mancante. La tua chiave privata può essere perfetta, ma il server ha comunque bisogno della chiave pubblica corrispondente nel file ~/.ssh/authorized_keys di quell’utente. Se la chiave pubblica è stata incollata nella home directory dell’utente sbagliato, SSH ti respingerà.

Un’altra causa comune sono i permessi dei file. SSH è rigido apposta. Se la tua cartella .ssh o il file authorized_keys sono scrivibili da troppe persone, SSH potrebbe ignorarli. È come un edificio che si rifiuta di fidarsi di una serratura dopo aver scoperto che chiunque nel corridoio può cambiarla.

Potresti anche stare usando localmente la chiave privata sbagliata. Succede spesso dopo aver reinstallato il portatile, cambiato macchina o copiato un progetto da qualcun altro. La chiave pubblica sul server deve corrispondere alla chiave privata presente sul computer che stai usando adesso.

A volte è la configurazione SSH del server a bloccare l’accesso. Per esempio, l’accesso come root potrebbe essere disabilitato, l’accesso con password potrebbe essere disabilitato, oppure uno specifico utente potrebbe non essere autorizzato. Di solito è una buona scelta di sicurezza, ma sembra un errore quando non sai quale regola ti sta bloccando.

I firewall sono un problema diverso. Un problema di firewall di solito causa un timeout o un “connection refused”, non Permission denied (publickey). Se sospetti che il server non sia raggiungibile affatto, guarda la nostra guida al firewall in parole semplici: Come configurare un firewall sul tuo server.

Come lo risolvi senza peggiorare le cose?

Se hai ancora una sessione di accesso funzionante aperta, tienila aperta. Non chiudere la tua unica porta aperta mentre cambi la serratura.

Poi conferma l’utente che intendi usare. Sul server, la cartella home di quell’utente dovrebbe contenere una directory .ssh, e al suo interno un file authorized_keys. La chiave pubblica che vuoi usare dovrebbe essere su una riga tutta sua in quel file.

Poi confronta la coppia di chiavi. La chiave pubblica sul server dovrebbe essere la metà pubblica della chiave privata sul tuo computer. Non incollare la tua chiave privata sul server. La chiave privata è la metà segreta: trattala come la chiave di casa, non come un cartellino con il nome.

Dopo, controlla i permessi. La cartella home dell’utente, la cartella .ssh e il file authorized_keys non dovrebbero essere aperti alla modifica da parte di altri utenti. Se SSH pensa che altre persone possano manomettere l’elenco delle chiavi, potrebbe ignorare completamente il file.

Infine, fai una prova in una finestra di terminale separata prima di cambiare qualcos’altro. Se il nuovo accesso funziona, puoi chiudere in sicurezza la vecchia sessione. Se fallisce, la vecchia sessione è ancora la tua corda di sicurezza.

Se stai configurando un server nuovo e questo è uno dei primi ostacoli, può aiutarti fare un passo indietro e seguire un percorso più completo per i primi passi. Ne parliamo in Ho preso un server — e adesso?.

FAQ

**Permission denied (publickey) significa che il mio server è giù?** No. Di solito significa che il server ha risposto, ma ha rifiutato la tua chiave SSH per quell’utente.

Posso risolvere con la password di root? Solo se l’accesso con password e l’accesso come root sono abilitati. Molti server disabilitano uno o entrambi per sicurezza.

Dovrei creare una nuova chiave SSH? Solo se non hai più la chiave privata corretta, oppure se vuoi sostituire una vecchia chiave. Altrimenti, prima sistema la mancata corrispondenza.

**È sicuro incollare la mia chiave pubblica in authorized_keys?** Sì. La chiave pubblica è fatta per essere condivisa. Non incollare mai lì la tua chiave privata.

Perché un portatile funziona e un altro no? Perché il portatile che funziona ha la chiave privata corrispondente. All’altro portatile va aggiunta al server la sua chiave pubblica.

La scorciatoia

Server Manager ti aiuta a evitare fin dall’inizio le parti confuse che di solito creano Permission denied (publickey): l’utente sbagliato, una chiave pubblica mancante, regole di accesso poco chiare e una configurazione che tre mesi dopo non ricordi più.

Il vero vantaggio è che l’accesso resta leggibile. Puoi vedere cosa appartiene a quale server e a quale progetto, quindi non devi tirare a indovinare se SSH ti rifiuta per colpa di una vecchia chiave, di un vecchio nome utente o di una configurazione lasciata a metà.

Riduce anche il rischio di restare fuori mentre fai lavori di routine. Invece di trasformare un piccolo problema di accesso in un recupero notturno, mantieni il server abbastanza comprensibile da sistemarlo con calma.

Che aspetto ha una soluzione pulita?

Una soluzione pulita non è solo “sono entrato una volta”. È sapere perché sei entrato.

Conosci il nome utente corretto. Sai quale chiave privata appartiene a questo server. La chiave pubblica corrispondente è nel file authorized_keys dell’utente giusto. I permessi sono abbastanza stretti perché SSH si fidi. E la configurazione è documentata abbastanza bene da evitare che il te del futuro debba risolvere di nuovo lo stesso rompicapo.

Questa è la vittoria: SSH diventa una porta chiusa a chiave che capisci, non una porta chiusa a chiave che temi.