Come risolvere SSH Permission denied (publickey)

Che cosa significa realmente Permission denied (publickey)

Permission denied (publickey) significa che il client ha inviato una o più chiavi pubbliche e il server non ne ha accettata nessuna. La rete funziona e sshd è in esecuzione: il rifiuto avviene nell'ultima fase dell'autenticazione. La correzione non richiede tentativi casuali, perché ssh -v indica quale delle cinque cause è presente.

Le parole tra parentesi indicano i metodi che il server era disposto ad accettare. Permission denied (publickey) da solo significa che sul server l'accesso con password è disabilitato, quindi non è disponibile alcuna password alternativa. Permission denied (publickey,password) significa che le password erano accettate e che anche quei tentativi di autenticazione sono falliti.

Un solo messaggio comprende cinque problemi distinti ed è volutamente generico. Un server che rispondesse "utente inesistente" o "chiave non installata" aiuterebbe chiunque cercasse account validi. Non iniziare quindi a sostituire chiavi e modificare file di configurazione. Esegui un comando, leggi tre righe dell'output e riduci le cinque cause possibili a una sola.

Esegui prima ssh -v e leggi tre righe

Ripeti il comando che ha avuto esito negativo, aggiungendo -v:

ssh -v deploy@203.0.113.10

Un'esecuzione ridotta ma realistica è simile a questa:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

Tre righe contengono tutte le informazioni necessarie.

Authenticating to 203.0.113.10:22 as 'deploy' è il nome utente che verrà effettivamente usato. Non quello che intendevi usare, ma quello ricavato da ssh dalla riga di comando, da ~/.ssh/config oppure dal nome dell'utente locale.

Authentications that can continue: publickey è l'elenco dei metodi accettati dal server, inviato prima che venga provata qualsiasi chiave. Se publickey manca dal primo elenco, il server ha disabilitato l'accesso con chiave pubblica, quindi nessuna chiave potrà funzionare.

Offering public key: ... è una riga per ogni chiave inviata realmente dal client, con il nome del file di origine e la relativa impronta digitale SHA256. Una chiave priva della riga Offering non è mai stata inviata al server.

Ora separa il problema in due parti:

• Non esiste alcuna riga Offering public key per la chiave prevista. Il problema è sul computer locale, perché il server non ha mai ricevuto la chiave.
• La chiave viene offerta e compare di nuovo Authentications that can continue: publickey. Il server ha ricevuto la chiave, ma l'ha rifiutata; il problema è quindi sul server.

Le cause riportate di seguito sono ordinate in base alla frequenza con cui risultano essere la spiegazione corretta.

Causa 1: connessione con il nome utente errato

La causa più comune è anche la meno interessante. sshd, il demone server SSH (secure shell), non comunica mai che un account non esiste. Esegue l'intero scambio per un nome utente inventato e rifiuta la connessione alla fine con lo stesso messaggio, perché rivelare nomi di account validi aiuta un attaccante. Un errore di digitazione nel nome utente appare esattamente come una chiave non valida.

Controllare la riga Authenticating to ... as prima di qualsiasi altra cosa. Se indica il nome utente con cui si accede al laptop invece dell'account sul server, il nome utente è stato omesso dal comando.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

L'account predefinito dipende dall'immagine usata dal provider. Ad agosto 2026, le immagini cloud di Ubuntu includono in genere un account ubuntu, quelle di Debian includono debian o admin, Rocky Linux e AlmaLinux includono rocky e almalinux, mentre molti provider VPS installano direttamente la chiave in root. Il pannello di controllo del provider indica quale account è stato creato. Nessun comando eseguito dall'esterno del server può recuperare questa informazione.

Un blocco Host in ~/.ssh/config imposta a sua volta il nome utente e ha la precedenza sul nome utente locale:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Se l'account è stato creato manualmente e non è stato possibile accedervi, probabilmente la chiave è stata installata per l'utente predefinito dell'immagine e non è mai stata copiata nell'account creato. Questo passaggio fa parte di primi dieci minuti su un nuovo VPS ed è facile ometterlo.

Causa 2: la chiave che pensi di inviare non è quella effettivamente inviata

Per impostazione predefinita, ssh propone soltanto le chiavi contenute in ssh-agent e un insieme fisso di nomi di file in ~/.ssh: id_ed25519, id_ecdsa, id_rsa e le varianti hardware e DSA di questi nomi. Una chiave salvata come ~/.ssh/vps-prod non è visibile a ssh finché non la specifichi. Per questo l'output dettagliato non mostra alcuna riga Offering public key relativa a quella chiave.

Specifica il file e impedisci alle chiavi dell'agent di precederlo:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

-i da solo non basta quando l'agent contiene delle chiavi, perché ssh continua a proporre prima le chiavi dell'agent e il file specificato per ultimo. Questo è importante perché il server conta ogni chiave rifiutata ai fini di MaxAuthTries, che per impostazione predefinita è 6. Un agent che contiene sette chiavi può raggiungere il limite prima che venga proposta la chiave corretta. Il messaggio cambia quindi in:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

IdentitiesOnly=yes limita i tentativi al file specificato. Elenca le chiavi contenute nell'agent con ssh-add -l e rimuovile con ssh-add -D se l'agent ha accumulato chiavi obsolete negli anni. Quindi salva le impostazioni, così il login successivo non dipenderà dalla memoria dei flag:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

Esiste un'altra insidia lato client. ssh rifiuta di usare una chiave privata leggibile da altri account sul computer locale. Mostra un avviso e ignora la chiave. Di conseguenza, la chiave non viene mai proposta e il server non la riceve:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod risolve il problema. Il trasferimento di una chiave tramite una chiavetta USB o una condivisione Windows è il modo più comune con cui vengono persi i permessi. La posizione delle chiavi e i relativi nomi sono descritti in Nozioni di base sulla gestione delle chiavi SSH.

Causa 3: la chiave pubblica non è mai arrivata in authorized_keys

Se ssh -v mostra che la chiave viene inviata, ma il server continua a rifiutarla, la domanda successiva è se quella chiave si trovi nel file authorized_keys dell'account. Apri la console del provider per verificarlo, perché non puoi accedere tramite SSH per eseguire il controllo.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

ssh-keygen -lf su un file authorized_keys stampa un'impronta per ogni voce:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

Confronta queste impronte con quella nella riga Offering public key. Se non è presente nell'elenco, la chiave non è installata per quell'account, indipendentemente da ciò che ricordi di avere fatto.

Ecco quattro cause comuni:

• Hai incollato la chiave privata invece del file .pub. Una riga di chiave pubblica inizia con ssh-ed25519 o ssh-rsa. Una chiave privata inizia con -----BEGIN OPENSSH PRIVATE KEY-----.
• Il contenuto incollato è stato distribuito su più righe. Ogni voce deve occupare esattamente una riga. Una chiave suddivisa su più righe viene quindi interpretata come più voci danneggiate e non corrisponde a nulla.
• La chiave è stata inserita in /root/.ssh/authorized_keys, mentre accedi come deploy, oppure il contrario. Il file è specifico per ogni account e non ne esiste uno condiviso.
• La casella del provider per "aggiungere la mia chiave" l'ha scritta soltanto nell'utente predefinito dell'immagine. Di conseguenza, l'account creato successivamente ha una directory .ssh vuota.

Il metodo sicuro per aggiungere una chiave dalla console, come root, è il seguente:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Esegui nuovamente sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys. La nuova impronta dovrebbe ora essere presente nell'elenco. Da una macchina che può ancora accedere con una password, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 esegue la stessa operazione e imposta correttamente anche i permessi.

Causa 4: perché sshd ignora authorized_keys quando i permessi sono troppo aperti

StrictModes yes è il valore predefinito di sshd. Con questa impostazione, sshd rifiuta di leggere authorized_keys se il file, la directory .ssh o la home directory dell'account possono essere modificate da chiunque non ne sia il proprietario. Il motivo è diretto: se il gruppo o tutti gli utenti possono scrivere nella home directory, qualsiasi account con questo accesso può sostituire authorized_keys e prendere il controllo dell'accesso. sshd considera il percorso non attendibile come se non esistesse alcuna chiave.

Il client visualizza il semplice messaggio Permission denied. Il log del server registra il motivo reale:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

oppure, quando il problema riguarda direttamente il file:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

Cosa accetta sshd:

• La home directory: non deve essere scrivibile dal gruppo né da tutti gli utenti. 755, 750 e 700 superano il controllo. 775 e 777 lo falliscono.
• ~/.ssh: modalità 700.
• ~/.ssh/authorized_keys: modalità 600.
• Proprietà: tutti e tre devono appartenere all'account con cui si effettua il login, non a root.

La proprietà è importante quanto la modalità. Un file dentro /home/deploy/.ssh di proprietà di root fallisce lo stesso controllo. Questo accade quando lo si crea con sudo nano e si dimentica di restituirne la proprietà all'account corretto. Correggi entrambi gli aspetti con un solo comando:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

L'ultimo comando mostra il risultato. La home directory deve avere drwxr-xr-x o permessi più restrittivi, mentre drwx------ deve essere impostato su .ssh. Se queste stringhe non sono ancora chiare, leggi come leggere una stringa di permessi come drwxr-xr-x prima di modificare le modalità su un server in produzione.

Su Rocky Linux e AlmaLinux, aggiungi SELinux (Security-Enhanced Linux) all'elenco delle possibili cause. Una directory .ssh creata tramite una procedura non standard può avere un'etichetta di file errata. Di conseguenza, a sshd viene negato l'accesso in lettura anche se le modalità sono corrette. sudo restorecon -Rv /home/deploy/.ssh ripristina le etichette e sudo ausearch -m avc -ts recent mostra se il componente che ha negato l'accesso era SELinux.

Causa 5: sshd è configurato per rifiutare l'accesso

Leggere /etc/ssh/sshd_config non è sufficiente sui sistemi Ubuntu o Debian recenti. Il file inizia con Include /etc/ssh/sshd_config.d/*.conf e OpenSSH mantiene il primo valore trovato per ogni impostazione. Di conseguenza, un file drop-in come 50-cloud-init.conf viene letto prima e prevale su qualsiasi modifica effettuata più avanti nel file principale. Per questo una modifica può sembrare corretta senza produrre alcun effetto.

Chiedi a sshd quale configurazione sta realmente utilizzando:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

Una risposta corretta è simile a questa:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

Nell'output del tuo sistema verifica quanto segue:

• pubkeyauthentication no. Nessuna chiave verrà mai accettata. Questa impostazione compare anche in ssh -v come primo elenco Authentications that can continue: senza alcun publickey.
• authorizedkeysfile punta a un percorso diverso, ad esempio /etc/ssh/authorized_keys/%u. Il file nella directory home viene quindi ignorato completamente e le regole sui permessi descritte nella causa 4 si applicano al nuovo percorso.
• Sono presenti allowusers o allowgroups. Qualsiasi account non incluso viene rifiutato con esattamente questo errore e senza ulteriori spiegazioni. denyusers e denygroups producono lo stesso effetto al contrario.
• permitrootlogin no mentre tenti di accedere come root. prohibit-password è l'impostazione intermedia consigliata: root può usare una chiave, ma non una password.

I blocchi Match non compaiono in un semplice sshd -T, perché il risultato dipende dall'utente che si connette. Verifica una connessione specifica:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

Un'altra impostazione riguarda le chiavi meno recenti. OpenSSH 8.8 ha smesso di accettare per impostazione predefinita le firme SHA-1 (ssh-rsa). Di conseguenza, una chiave RSA che ha funzionato per anni può smettere di funzionare subito dopo un aggiornamento del server. Il client lo indica chiaramente:

debug1: send_pubkey_test: no mutual signature algorithm

La correzione corretta consiste nel generare una nuova chiave: ssh-keygen -t ed25519 -C "deploy@vps-prod", quindi installa il file .pub come mostrato sopra. Impostare PubkeyAcceptedAlgorithms +ssh-rsa sul server riattiva le vecchie firme e consente di accedere nell'immediato. Considerala però una soluzione temporanea per raggiungere il server, non la conclusione dell'intervento. Le altre impostazioni lato server da esaminare sono disponibili nella guida alla messa in sicurezza del server SSH su un VPS.

Come dimostrare che una chiave privata corrisponde alla chiave pubblica installata

Gran parte delle verifiche necessarie per questo errore dipende dal fatto che non si sa se due file costituiscono una coppia. Un comando permette di verificarlo:

ssh-keygen -y -f ~/.ssh/vps-prod

Il comando stampa la chiave pubblica derivata dalla chiave privata. Non legge mai il file .pub che si trova accanto a essa, quindi mostra quale chiave privata si sta effettivamente usando, invece di basarsi su ciò che dichiara un file .pub obsoleto. Se la chiave è protetta da una passphrase, il comando la richiede. Questo conferma anche che la passphrase è ancora disponibile.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

Il primo comando stampa l'impronta digitale di un file di chiave pubblica. Il secondo stampa le impronte delle chiavi presenti nell'agent. Confrontare quindi quattro rappresentazioni della stessa stringa: l'impronta nella riga Offering public key di ssh -v, l'impronta del file .pub, le impronte in ssh-keygen -lf sul file authorized_keys del server e l'impronta nel log del server. Il punto in cui i valori non coincidono più identifica la propria configurazione errata.

Leggi il log del server mentre il login non riesce

Al client non viene restituita intenzionalmente alcuna informazione utile. Il server registra il motivo effettivo. Avvia il monitoraggio del log nella sessione della console, quindi esegui dal laptop il comando ssh che non riesce.

sudo journalctl -u ssh -f

Ubuntu 24.04 non installa rsyslog per impostazione predefinita, quindi /var/log/auth.log potrebbe non essere presente. Su Rocky Linux e AlmaLinux l’unità si chiama sshd e gli stessi record vengono scritti anche in /var/log/secure.

Imposta LogLevel VERBOSE nella configurazione di sshd e ricarica il servizio. Da quel momento, ogni tentativo registra l’impronta digitale della chiave effettivamente ricevuta dal server:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

Quella riga indica su quale lato si trova il problema. Un’impronta digitale che riconosci significa che la tua chiave è arrivata al server, ma è stata rifiutata. Controlla quindi le cause 3, 4 e 5. Un’impronta digitale che non riconosci significa che il client ha inviato una chiave diversa da quella prevista. Torna quindi alla causa 2.

Se il log non è ancora chiaro, avvia un secondo sshd su un’altra porta in modalità debug. Il processo resta in primo piano, gestisce una connessione, stampa le motivazioni del rifiuto e poi termina:

sudo /usr/sbin/sshd -ddd -p 2222

Dalla sessione della console sullo stesso server, connettiti usando l’indirizzo di loopback:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

L’uso di 127.0.0.1 esclude il firewall dal test. L’output di debug indica il file aperto, l’impronta digitale confrontata e il rifiuto esatto, incluse righe come Authentication refused: bad ownership or modes for directory /home/deploy. Premi Ctrl+C quando hai individuato la causa. Il processo sshd reale sulla porta 22 non viene modificato.

Come evitare di rimanere esclusi

Ogni modifica alla configurazione del server deve prevedere un metodo di accesso alternativo che non dipenda da SSH. Configuralo mentre SSH funziona ancora, non dopo che ha smesso di funzionare.

1. Apri la console del provider tramite seriale o VNC (virtual network computing) e verifica di poter effettuare l'accesso.
2. Assicurati di conoscere una password locale funzionante per un account con sudo. Se non ne hai una, reimposta prima la password di root dalla console del provider.
3. Mantieni aperta la sessione SSH corrente. Una sessione aperta sopravvive a systemctl restart ssh, quindi resta un metodo di accesso alternativo se la nuova configurazione è errata.
4. Verifica la sintassi prima del riavvio: sudo sshd -t non restituisce alcun output quando il file è valido e mostra il file e il numero di riga quando non lo è.
5. Apri un secondo terminale ed effettua un nuovo accesso prima di chiudere il primo. Una configurazione non valida impedisce i nuovi accessi, ma non interrompe quelli esistenti. Per questo la sessione già aperta non può indicarti se la modifica ha avuto effetto.

Riavvia con sudo systemctl restart ssh su Debian e Ubuntu oppure con sudo systemctl restart sshd su Rocky Linux e AlmaLinux. Su Ubuntu 24.04 sshd viene avviato da un socket unit, quindi una modifica a Port o ListenAddress richiede anche sudo systemctl restart ssh.socket prima di diventare effettiva.

FAQ

Perché ricevo Permission denied (publickey) quando la stessa chiave funziona su un altro server?

La chiave è valida, ma c'è un problema nella configurazione circostante. Esegui ssh -v e individua la riga Offering public key. Se la chiave non è elencata, ssh non l'ha inviata: il file non si trova in ~/.ssh con un nome predefinito e la chiave non è stata caricata nell'agent, quindi aggiungi -i /path/to/key -o IdentitiesOnly=yes. Se la chiave è elencata ma il server continua a rifiutarla, la chiave non è presente nel file authorized_keys dell'account, il percorso che la contiene è scrivibile dal gruppo oppure sshd blocca l'utente. Il log del server consente di distinguere questi casi.

Come posso vedere quale chiave SSH sta effettivamente inviando?

ssh -v host stampa una riga debug1: Offering public key: per ogni chiave e indica, per ciascuna, il file sorgente e l'impronta SHA256. ssh-add -l elenca le impronte delle chiavi contenute nell'agent. ssh-keygen -lf ~/.ssh/id_ed25519.pub stampa l'impronta di un singolo file di chiave, mentre ssh-keygen -y -f ~/.ssh/id_ed25519 stampa la chiave pubblica realmente derivata da una chiave privata. Perché l'accesso abbia esito positivo, l'impronta nella riga Offering deve comparire anche nell'output di ssh-keygen -lf eseguito sul file authorized_keys del server.

Perché sshd ignora il mio file authorized_keys?

Perché StrictModes è attivo per impostazione predefinita e il file, la directory .ssh o la directory home è scrivibile dal gruppo o da chiunque, oppure appartiene all'account sbagliato. sshd non considera attendibile un percorso che altri utenti possono modificare, quindi si comporta come se non esistesse alcuna chiave. Imposta la directory home su 755 o su permessi più restrittivi, .ssh su 700, authorized_keys su 600 e assegna tutte e tre all'account di accesso. Con LogLevel VERBOSE il server registra Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

La mia chiave ha smesso di funzionare subito dopo un aggiornamento del server. Che cosa è cambiato?

Se si tratta di una chiave RSA, la causa più probabile è la modifica relativa a SHA-1. OpenSSH 8.8 ha disabilitato per impostazione predefinita le firme SHA-1 ssh-rsa, quindi una chiave che può firmare soltanto in questo modo viene ora rifiutata. L'output dettagliato del client mostra debug1: send_pubkey_test: no mutual signature algorithm. Genera una chiave moderna con ssh-keygen -t ed25519 e installa il relativo file .pub. Se devi ripristinare subito l'accesso, PubkeyAcceptedAlgorithms +ssh-rsa sul server riabilita le vecchie firme; rimuovi questa riga non appena la nuova chiave funziona.

Ho modificato sshd_config e ora non riesco più ad accedere. Come posso ripristinare l'accesso?

Usa la console del provider, che non passa da SSH. Accedi con una password locale, esegui sudo sshd -t per visualizzare l'errore di sintassi e il relativo numero di riga, annulla la modifica e riavvia il servizio. Controlla quindi sudo sshd -T per confermare i valori effettivamente in uso, perché un file in /etc/ssh/sshd_config.d/ potrebbe sovrascrivere la configurazione principale. Se non hai una password locale, reimposta prima la password di root dalla console, quindi correggi il file.