Risolvere l'errore SSH "Permission denied (publickey)"

Il tentativo di connessione si interrompe dopo un secondo, non arriva nessuna richiesta di password, solo una riga: Permission denied (publickey). Questo messaggio è così fastidioso proprio perché di proposito non rivela nulla. Il server SSH non dice a un potenziale attaccante se l'utente esiste, se la chiave era sbagliata o se il file non è leggibile. La stessa reticenza però colpisce anche te, quando sei tu a bussare alla porta in modo del tutto legittimo.

La buona notizia: le cause sono in numero finito, si possono verificare in un ordine preciso e nella maggior parte dei casi si tratta semplicemente dei permessi sui file. Questo articolo affronta le cause in ordine di frequenza, mostra per ciascuna il testo esatto che compare nel log e spiega come stabilire in trenta secondi, con ssh -vvv, se il problema è sul tuo computer o sul server.

Che cosa significa esattamente il messaggio

La parentesi finale non è un ornamento, è l'informazione più importante di tutta la riga. Contiene i metodi di autenticazione che il server continua a offrire dopo il tentativo fallito:

Permission denied (publickey).
Permission denied (publickey,password).
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Se compare solo publickey, l'accesso con password è disattivato sul server. Se nella lista c'è anche password, un accesso con password sarebbe stato possibile in linea di principio, semplicemente non è stato tentato oppure è fallito a sua volta. La variante con gssapi è tipica di AlmaLinux, Rocky Linux e RHEL, dove il supporto Kerberos è compilato nel binario.

È importante distinguere questo messaggio da altri che gli somigliano ma descrivono un problema completamente diverso:

• Permission denied, please try again. senza parentesi indica una password sbagliata, non un problema di chiavi.
• Host key verification failed. riguarda la chiave del server nel tuo file known_hosts, non la tua chiave personale.
• Received disconnect from 203.0.113.7 port 22:2: Too many authentication failures significa che il tuo agent ha proposto troppe chiavi una dopo l'altra e il server ha chiuso la connessione al raggiungimento di MaxAuthTries.
• Connection refused oppure un timeout sono questioni di rete o di firewall. Se poco prima hai messo mano a un firewall UFW o a Fail2ban, comincia da lì.

Il bivio: leggere ssh -vvv nel modo giusto

Prima di modificare qualsiasi cosa, fatti mostrare come procede la sessione. Le tre v non sono un caso, con una sola v mancano le righe decisive:

ssh -vvv deploy@203.0.113.7

L'output è lungo, ma a te interessano solo quattro punti. Primo, il nome utente con cui la connessione avviene davvero:

debug1: Authenticating to 203.0.113.7:22 as 'deploy'

Secondo, quali chiavi il client prende effettivamente in considerazione e, terzo, quale invia davvero:

debug1: Will attempt key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk... agent
debug1: Offering public key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

E quarto, il messaggio di successo, che in caso di errore appunto non compare:

debug1: Server accepts key: /home/tom/.ssh/id_ed25519 ED25519 SHA256:8Qk...
debug1: Authenticated to 203.0.113.7 ([203.0.113.7]:22) using "publickey".

Da qui nasce il bivio che ti risparmia metà della ricerca dell'errore:

• Non compare nessun Offering public key con la tua chiave. Allora il problema è sul tuo computer, la chiave non è mai stata inviata. Passa alla causa 3.
• Compare Offering public key, ma subito dopo di nuovo Authentications that can continue. Allora il server ha visto la tua chiave e l'ha rifiutata. Sono le cause 1, 2, 4, 5 e 6, tutte lato server.
• Compare send_pubkey_test: no mutual signature algorithm. Allora il tema è il tipo di chiave, passa alla causa 7.

Altre due righe dell'output di debug meritano uno sguardo. debug3: no such identity: /home/tom/.ssh/id_rsa: No such file or directory è innocua, il client sta semplicemente provando tutti i nomi standard. Permissions 0644 for '/home/tom/.ssh/id_ed25519' are too open. invece è un riscontro vero: la tua chiave privata a quel punto viene ignorata.

Il lato server: sshd -T e i log

ssh -vvv mostra esclusivamente il punto di vista del client. Il motivo del rifiuto è scritto solo nel log del server. Se hai ancora una sessione aperta oppure riesci a entrare dalla console nell'area clienti, guarda prima lì.

Su Debian e Ubuntu il servizio si chiama ssh, su AlmaLinux, Rocky Linux e RHEL si chiama sshd. È una trappola classica quando si copiano comandi:

journalctl -u ssh -n 50 --no-pager      # Debian, Ubuntu
journalctl -u sshd -n 50 --no-pager     # AlmaLinux, Rocky, RHEL

Il classico file di testo non esiste più ovunque. Ubuntu 22.04 e 24.04 mantengono /var/log/auth.log nell'installazione server, perché rsyslog viene fornito insieme al sistema. Debian 12 e Debian 13 non installano più rsyslog in un'installazione minimale, lì il file semplicemente non esiste e tutto finisce nel journal. Nella famiglia Red Hat il file si chiama /var/log/secure. Chi su Debian vuole riavere il file di testo installa rsyslog a posteriori, su Debian e Ubuntu con apt-get install -y rsyslog, nella famiglia Red Hat con dnf install -y rsyslog.

Il secondo comando lato server è ancora più importante, perché stampa la configurazione realmente attiva risolvendo tutti i file inclusi:

sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|strictmodes|permitrootlogin'

Se al posto di una configurazione il comando risponde solo con Missing privilege separation directory: /run/sshd e non stampa una sola riga, manca semplicemente una directory di runtime. Succede su Debian 11, Debian 12, Ubuntu 22.04 e Ubuntu 24.04 subito dopo l'installazione del pacchetto, finché il servizio non è mai stato avviato, e nei container. In esercizio normale è la unit systemd a creare da sé la directory tramite RuntimeDirectory=sshd. Se il messaggio compare, basta anteporre un mkdir -p /run/sshd, dopodiché sshd -T restituisce correttamente permitrootlogin, pubkeyauthentication yes, strictmodes yes e authorizedkeysfile. Debian 13 con OpenSSH 10 e tutta la famiglia Red Hat non conoscono più questa limitazione. Fai attenzione al fatto che il messaggio si perde dentro una pipe: sshd -T | grep ... mostra allora solo un output vuoto e il vero codice di ritorno 255 sparisce nel grep.

E se vuoi davvero vedere che cosa pensa il server senza toccare il servizio in esecuzione: avvia una seconda istanza in modalità debug su una porta libera. Si chiude da sola dopo una connessione e non può lasciarti fuori.

/usr/sbin/sshd -ddd -p 2222

Dal tuo computer poi ssh -p 2222 deploy@203.0.113.7, e nel terminale del server il rifiuto compare in chiaro. Naturalmente la porta deve essere aperta nel firewall.

Causa 1: permessi e proprietario, di gran lunga il caso più frequente

OpenSSH ha l'opzione StrictModes yes attiva per impostazione predefinita. Il server si rifiuta di leggere una chiave da un file su cui, oltre all'utente stesso, potrebbe scrivere qualcun altro. Non è un capriccio, serve a impedire che un altro utente scriva tranquillamente la propria chiave nel tuo authorized_keys.

Lo stato corretto è definito in modo stretto:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chmod 750 ~
chown -R "$(id -un):$(id -gn)" ~/.ssh

La verifica sta in una sola riga:

stat -c "%a %U %G %n" ~ ~/.ssh ~/.ssh/authorized_keys

Ci si aspetta 750 oppure 700 per la home, 700 per .ssh e 600 per authorized_keys, e in tutte e tre le righe il tuo nome utente. Il punto decisivo è questo: la home non deve essere scrivibile da gruppo e altri, quindi 770 o 777 bastano già a far fallire l'accesso.

Un numero però non va scambiato per un errore: su AlmaLinux, Rocky Linux e Oracle Linux /root ha i permessi 550, non 700 come su Debian e Ubuntu. stat -c lo mostra correttamente ed è del tutto normale. Per StrictModes conta solo che gruppo e altri non abbiano permesso di scrittura, ed è esattamente ciò che 550 garantisce. Chi a questo punto lancia un chmod 700 /root non ha riparato l'accesso, ha solo nascosto ancora di più la causa.

Nel log del server la cosa è scritta in modo molto chiaro:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh
Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys
error: Could not open authorized keys '/home/deploy/.ssh/authorized_keys': Permission denied

Due dettagli che le altre guide omettono volentieri. Primo, il proprietario: se hai creato il file con sudo nano ~/.ssh/authorized_keys, appartiene a root e non all'utente, e l'accesso fallisce nonostante permessi 600 perfetti. Secondo, sshd controlla tutto il percorso verso l'alto. Se la home non si trova sotto /home ma per esempio sotto /srv/clienti/deploy, anche /srv e /srv/clienti devono appartenere a root o all'utente e non devono essere scrivibili da gruppo e altri.

Causa 2: il nome utente sbagliato

Un utente inesistente produce esattamente lo stesso messaggio di una chiave sbagliata, perché il server non rivela di proposito quale dei due casi si sia verificato. Nel log la differenza si vede subito:

Invalid user deply from 203.0.113.7 port 51234

La causa più frequente è che la chiave si trova in /root/.ssh/authorized_keys mentre tu accedi come utente normale, oppure il contrario. Nelle immagini cloud preconfezionate l'accesso root è spesso bloccato ed esiste invece un utente già predisposto, a seconda della distribuzione debian, ubuntu, almalinux oppure rocky. Con le immagini standard su un server root KernelHost, invece, accedi direttamente come root.

Controlla inoltre se il tuo ~/.ssh/config ti sostituisce un altro utente. Il comando seguente non apre alcuna connessione, mostra soltanto quali impostazioni valgono davvero per questa destinazione:

ssh -G deploy@203.0.113.7

Nell'output interessano user, hostname, port e l'elenco delle voci identityfile.

Causa 3: la chiave non viene proprio proposta

Se in ssh -vvv non compare alcun Offering public key con la tua chiave, il server non ha mai avuto occasione di valutarla. Ci sono quattro motivi tipici.

La chiave ha un nome personalizzato

Automaticamente OpenSSH prova solo i nomi standard id_ed25519, id_ecdsa e id_rsa. Una chiave chiamata id_produzione viene usata solo se la indichi esplicitamente:

ssh -i ~/.ssh/id_produzione -o IdentitiesOnly=yes deploy@203.0.113.7

IdentitiesOnly=yes qui non è un accessorio. Senza questa opzione ssh propone anche tutte le chiavi presenti nell'agent e, se i tentativi sono troppi, il server chiude con Too many authentication failures prima ancora che tocchi alla chiave giusta.

L'agent non ha la chiave

ssh-add -l

Se il comando risponde con The agent has no identities. oppure Could not open a connection to your authentication agent., carica la chiave con ssh-add ~/.ssh/id_ed25519.

Permessi sulla chiave privata

La chiave privata deve avere 600, altrimenti il client si rifiuta di usarla. Su Windows chmod non ha effetto, lì si lavora con le ACL:

icacls %USERPROFILE%\.ssh\id_ed25519 /inheritance:r /grant:r "%USERNAME%":R

Il file authorized_keys è danneggiato

Una chiave pubblica occupa esattamente una riga. Copiandola attraverso editor, sistemi di ticket o finestre di chat ci si ritrova volentieri con un a capo in mezzo al blocco Base64, e a quel punto non torna più niente. Conta le righe:

grep -c '^ssh-' ~/.ssh/authorized_keys
awk '{print NR": "NF" campi, tipo "$1}' ~/.ssh/authorized_keys

Ogni riga deve iniziare con ssh-ed25519, ssh-rsa oppure ecdsa-sha2- ed essere composta da due o tre campi. Il numero di righe deve corrispondere al numero di chiavi. Un secondo classico è aver inserito per sbaglio la chiave privata al posto di quella pubblica, riconoscibile da BEGIN OPENSSH PRIVATE KEY. E una chiave in formato PuTTY (.ppk) così non funziona, va prima esportata in formato OpenSSH.

Per capire se chiave privata e chiave pubblica appartengono alla stessa coppia basta confrontare le impronte:

ssh-keygen -lf ~/.ssh/id_ed25519.pub
ssh-keygen -lf ~/.ssh/authorized_keys

Lo stesso valore SHA256 deve comparire in entrambi gli output. Come si presenta il tutto quando è configurato bene lo trovi nel nostro articolo su come mettere in sicurezza SSH e configurare l'accesso con chiave.

Causa 4: PubkeyAuthentication è disattivato

Più raro, ma in quel caso inequivocabile. Non controllare il file di configurazione, controlla il risultato:

sshd -T | grep -i pubkeyauthentication

Qui si nasconde una trappola che costa parecchie ore. Debian dalla versione 12 e Ubuntu dalla 22.04 hanno in cima a /etc/ssh/sshd_config la riga Include /etc/ssh/sshd_config.d/*.conf. Per sshd vale la regola: per ogni parola chiave conta il valore trovato per primo. Poiché l'inclusione sta all'inizio, qualsiasi dettaglio in sshd_config.d vince sul file principale, indipendentemente da ciò che è scritto più sotto. Se la tua modifica resta senza effetto, guarda lì:

grep -rniE 'pubkeyauthentication|authorizedkeysfile|allowusers|allowgroups' /etc/ssh/

Il secondo punto di questa categoria è AuthorizedKeysFile. I valori predefiniti sono .ssh/authorized_keys e .ssh/authorized_keys2. Alcuni script di hardening impostano il percorso su qualcosa come /etc/ssh/authorized_keys/%u. Da quel momento il tuo file nella home viene ignorato del tutto, senza alcun messaggio di errore. Anche questo lo mostra sshd -T.

Causa 5: AllowUsers, AllowGroups e Match entrano in gioco

Queste direttive tagliano fuori interi gruppi di utenti, e lo fanno prima ancora che la chiave venga verificata. Il testo nel log:

User root from 203.0.113.7 not allowed because not listed in AllowUsers
User deploy from 203.0.113.7 not allowed because none of user's groups are listed in AllowGroups
User root from 203.0.113.7 not allowed because "PermitRootLogin no"

Ricorda l'ordine di precedenza: DenyUsers batte AllowUsers, e non appena AllowUsers è impostato, tutti gli utenti non elencati restano fuori. Con AllowGroups deve essere corretta l'appartenenza al gruppo, cosa che verifichi con id deploy.

Con PermitRootLogin la distinzione è importante: prohibit-password consente l'accesso root con chiave. Solo no esclude root completamente. Nell'output di sshd -T però non aspettarti la parola prohibit-password: lì compare il nome più vecchio ma equivalente without-password. E il valore predefinito non è affatto uguale ovunque, cosa che genera regolarmente confusione quando si confrontano due server:

Su AlmaLinux quindi root può entrare anche con password, sugli altri sistemi citati no. Chi sposta un servizio da AlmaLinux a Debian e finora accedeva come root con password, si ritrova poi esattamente davanti a Permission denied (publickey).

Se la regola si trova dentro un blocco Match, aiuta l'opzione che valuta la configurazione per un caso concreto:

sshd -T -C user=deploy,host=client.example.com,addr=203.0.113.7 | grep -Ei 'pubkeyauth|allowusers|permitrootlogin'

È il modo più affidabile per vedere che cosa vale esattamente per quell'utente e per quell'indirizzo IP.

Causa 6: SELinux su AlmaLinux, Rocky e RHEL

Nella famiglia Red Hat SELinux gira per impostazione predefinita in modalità Enforcing, su Debian e Ubuntu non ha alcun ruolo. Il processo sshd può leggere authorized_keys solo se il file porta il contesto ssh_home_t. È così quando il file è stato creato normalmente nella home. Non è così se lo hai preso da /tmp con mv oppure se hai creato la home a mano, perché mv si porta dietro il vecchio contesto.

getenforce
ls -Z ~/.ssh

Corretta è una voce che termina con ssh_home_t. Se lì compare user_tmp_t oppure user_home_t, la causa è trovata. La riparazione:

restorecon -R -v ~/.ssh

Questo passaggio vale esclusivamente per la famiglia Red Hat. Su Debian e Ubuntu non esiste una configurazione SELinux predefinita, lì la shell risponde restorecon: command not found, e non è un errore, semplicemente non è applicabile. Ma anche su AlmaLinux e Rocky Linux il comando manca in un'installazione essenziale, perché il pacchetto relativo non è previsto. In quel caso installalo prima:

dnf install -y policycoreutils

Le prove le trovi nel log di audit, dove il rifiuto è scritto in chiaro:

ausearch -m avc -ts recent

Se le home si trovano in una posizione insolita, restorecon da solo non basta, perché SELinux non riconosce affatto quel percorso come home. Allora registri l'equivalenza una volta sola e poi ripristini:

semanage fcontext -a -e /home /srv/clienti
restorecon -R -v /srv/clienti

semanage si trova nel pacchetto policycoreutils-python-utils. Non disattivare SELinux per far funzionare l'accesso: risolveresti un problema da due comandi con una perdita di sicurezza su tutta la macchina.

Causa 7: server vecchio, tipo di chiave sbagliato

Da OpenSSH 8.8 il client rifiuta le firme RSA con SHA-1. È già interessato Ubuntu 22.04, e Debian 13 include ormai OpenSSH 10. Se da un sistema così recente vuoi raggiungere un server molto vecchio che conosce solo il vecchio ssh-rsa, nell'output di debug vedi:

debug1: send_pubkey_test: no mutual signature algorithm

Non è un problema di permessi, la tua chiave è perfettamente a posto. Per un accesso una tantum aiuta:

ssh -o PubkeyAcceptedAlgorithms=+ssh-rsa -o HostKeyAlgorithms=+ssh-rsa deploy@203.0.113.7

In modo permanente questo va in ~/.ssh/config sotto una voce Host, così riguarda solo quel singolo server. Sui client molto vecchi l'opzione si chiama ancora PubkeyAcceptedKeyTypes. La soluzione vera è aggiornare il vecchio server, perché già da OpenSSH 7.2 conosce anche le varianti SHA-2 e la tua chiave RSA esistente continua a funzionare senza modifiche. Cambia solo il metodo di firma.

Esiste anche il caso opposto. Una chiave ed25519 richiede almeno OpenSSH 6.5 su entrambi i lati, i token hardware di tipo ed25519-sk almeno la 8.2. E DSA è storia: da OpenSSH 10.0 ssh-dss è stato rimosso del tutto, quelle vecchie chiavi verso Debian 13 non funzionano più affatto. Quali tipi conosce il tuo client lo mostra:

ssh -Q key

Se su un AlmaLinux, Rocky Linux o RHEL appena installato manca completamente ssh, la colpa è di una trappola nei nomi dei pacchetti: dnf install openssh-server porta con sé solo il servizio, nessuno strumento client. Senza di essi mancano ssh, ssh-add e quindi anche ssh -Q e ssh -G. L'installazione avviene con la s finale, a differenza del pacchetto Debian openssh-client:

dnf install -y openssh-clients

Su AlmaLinux, Rocky e RHEL 9 si aggiunge un secondo livello. Lì le policy crittografiche di sistema concorrono a stabilire che cosa è permesso, indipendentemente dalla configurazione di sshd:

update-crypto-policies --show

Anche questo strumento è tipicamente Red Hat, su Debian e Ubuntu non esiste. E persino su Oracle Linux 9 manca nell'installazione minimale, lì lo aggiunge dnf install -y crypto-policies-scripts, dopodiché il risultato è DEFAULT come previsto. Se lì compare DEFAULT, le firme SHA-1 sono già bloccate a livello di sistema. update-crypto-policies --set LEGACY risolve la cosa, ma indebolisce l'intera macchina e dovrebbe essere al massimo una soluzione transitoria per una migrazione.

Se ti sei chiuso fuori

Il momento pericoloso non è l'errore in sé, ma la riparazione di sshd_config. Tre regole che rendono praticamente impossibile restare fuori:

1. Lascia aperta una seconda sessione. Un riavvio di sshd non interrompe le connessioni esistenti. Finché un terminale resta aperto, puoi annullare qualsiasi modifica.
2. Prima di ogni riavvio controlla la sintassi. sshd -t in caso di errore stampa il numero di riga e tace se è tutto a posto. Altrimenti un refuso nella configurazione impedisce l'avvio del servizio, e a quel punto non entra più nessuno. Se invece compare Missing privilege separation directory: /run/sshd, la tua configurazione è in ordine e manca solo la directory di runtime, vedi sopra.
3. Fai la prova dalla seconda sessione, prima di chiudere la prima.

Al riavvio i sistemi si comportano in modo diverso. Su Debian e Ubuntu la unit si chiama ssh, nella famiglia Red Hat sshd. Da Ubuntu 22.10 e in Debian 13 SSH viene avviato anche tramite attivazione socket: la configurazione di sshd_config resta valida, ma un valore Port modificato ha effetto solo dopo il riavvio anche di ssh.socket.

sshd -t
systemctl restart ssh          # Debian, Ubuntu
systemctl restart ssh.socket   # in aggiunta, se la porta è stata modificata
systemctl restart sshd         # AlmaLinux, Rocky, RHEL

Se è successo davvero, ti serve una via che aggiri SSH. Con un server root KernelHost apri la console VNC nell'area clienti e accedi con la password di root, senza alcun servizio di rete. Se non basta, per esempio perché sshd non parte più, aiuta il sistema di rescue: avvii un ambiente di emergenza, monti il filesystem di sistema e correggi authorized_keys e i permessi direttamente sul disco. Ricordati di controllare i proprietari dopo il montaggio, perché nel sistema di rescue sei root e altrimenti crei file con il proprietario sbagliato.

Come capisci che funziona davvero

Il fatto che un accesso vada a buon fine non significa ancora che sia passato dalla chiave. Finché l'accesso con password è attivo, il server può farti ricadere silenziosamente su quello. Il test onesto esclude ogni altro metodo:

ssh -o BatchMode=yes -o PreferredAuthentications=publickey deploy@203.0.113.7 'id -un; hostname'

BatchMode=yes sopprime qualsiasi richiesta interattiva. Se tornano il tuo nome utente e l'hostname e subito dopo echo $? restituisce 0, ha lavorato esclusivamente la chiave.

La seconda prova sta nel log del server e indica perfino l'impronta della chiave usata:

Accepted publickey for deploy from 203.0.113.7 port 51234 ssh2: ED25519 SHA256:8Qk...

Confronta questo valore SHA256 con l'output di ssh-keygen -lf ~/.ssh/id_ed25519.pub. Se coincidono, sai non solo che l'accesso funziona, ma anche quale chiave è stata usata. È rilevante quando ci sono più chiavi in gioco e ne vuoi revocare una.

L'ordine in cui procedere

Se non hai tempo per la teoria, segui questo elenco dall'alto verso il basso. È ordinato per frequenza, non per eleganza.

1. Avviare ssh -vvv e verificare se compare Offering public key. Questo divide il problema tra client e server.
2. Controllare i permessi: 700 su ~/.ssh, 600 su authorized_keys, home non scrivibile dal gruppo, tutto di proprietà dell'utente.
3. Controllare il nome utente, nel dubbio interrogare ssh -G e cercare Invalid user nel log.
4. Confrontare le impronte della chiave privata e di authorized_keys, controllare il numero di righe del file.
5. Analizzare sshd -T: pubkeyauthentication, authorizedkeysfile, strictmodes, permitrootlogin.
6. Verificare AllowUsers, AllowGroups, DenyUsers e i blocchi Match, insieme alla directory sshd_config.d.
7. Nella famiglia Red Hat ls -Z ~/.ssh e, se serve, restorecon -R -v ~/.ssh.
8. Solo con controparti molto vecchie: estendere l'algoritmo di firma con PubkeyAcceptedAlgorithms=+ssh-rsa.

Al più tardi qui la causa è trovata. Se poi vuoi riconfigurare l'accesso da zero in modo pulito, i punti di partenza giusti sono l'introduzione alla connessione SSH e la checklist per un nuovo server root.