Come risolvere "Permission denied (publickey)" in SSH

Vedere cosa offre il tuo client

ssh -v user@server

Cerca queste righe verso la fine dell'output:

La parola tra parentesi nell'errore elenca i metodi di login che il server consente ancora. (publickey) da solo significa che le password sono disattivate, quindi una chiave funzionante è l'unico modo per entrare.

Ti capita con git push o git pull? Vedi git@github.com: Permission denied (publickey).

Leggere il log sul server

Al client non viene mai detto perché una chiave è stata rifiutata. Lo sa solo il server. Se hai ancora un modo per entrare, come un'altra sessione o la console del provider, leggi il log:

sudo journalctl -u ssh -n 50     # Debian, Ubuntu
sudo journalctl -u sshd -n 50    # RHEL, Fedora, Arch
sudo tail -n 50 /var/log/auth.log   # older Debian and Ubuntu
sudo tail -n 50 /var/log/secure     # older RHEL

Se il log non dà alcun motivo, esegui un secondo sshd in modalità debug su una porta libera. Gestisce una sola connessione, stampa ogni passaggio ed esce. La porta deve essere aperta nel tuo firewall.

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

ssh -v -p 2222 user@server

Utente sbagliato

Controlla con quale utente fai davvero il login, perché una riga User nella tua configurazione può impostarlo:

ssh -G server | grep '^user '

Le immagini cloud spesso usano un account fisso come ubuntu, debian o ec2-user e rifiutano root. Una chiave installata per un account non funziona per un altro, perché ogni account ha il proprio authorized_keys.

Per fissare utente e chiave di un host una volta per tutte, metti User e IdentityFile nel suo blocco del file di configurazione ssh.

Chiave sbagliata, o chiave assente sul server

Confronta le impronte. Sulla tua macchina:

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

Sul server, questo elenca ogni chiave nel file:

ssh-keygen -lf ~/.ssh/authorized_keys

Se l'impronta manca, installa la chiave. Finché l'accesso con password funziona, basta un comando, che imposta anche i permessi giusti:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

Se il server accetta solo chiavi, aggiungila dalla console del provider o da un'altra sessione, come quell'utente. Al posto dell'esempio metti la riga intera del tuo file .pub:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo 'ssh-ed25519 AAAA... you@laptop' >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Se la chiave c'è ma il tuo client ne offre prima altre, indicala per nome e ignora le altre:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 user@server

Un errore comune nell'installazione a mano è una chiave spezzata su due righe. Ogni chiave deve stare su una sola riga: vedi il file authorized_keys spiegato.

Permessi e proprietà

Con StrictModes yes, il valore predefinito, sshd ignora authorized_keys se altri utenti potrebbero scriverci o scrivere nelle cartelle sopra. Basta il permesso di scrittura per il gruppo sulla home directory per far scattare il controllo. Sul server, come utente:

chmod go-w ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Se hai creato i file con sudo, correggi anche il proprietario:

sudo chown -R user:user /home/user/.ssh

Per vedere tutti i livelli del percorso in una volta:

namei -l /home/user/.ssh/authorized_keys

Sui sistemi con SELinux in modalità enforcing, come RHEL e Fedora, i file spostati al loro posto possono anche avere l'etichetta sbagliata. Ripristinala con restorecon -Rv ~/.ssh.

AuthorizedKeysFile punta altrove

La tua chiave può essere nel file giusto per la configurazione predefinita, ma non per questo server. Chiedi a sshd cosa si applica a questo utente. -C valuta anche gli eventuali blocchi Match:

sudo sshd -T -C user=user,host=example.com,addr=203.0.113.10 | grep -iE '^(authorizedkeysfile|pubkeyauthentication) '

Il valore predefinito è .ssh/authorized_keys .ssh/authorized_keys2, relativo alla home directory. Un valore come /etc/ssh/authorized_keys/%u significa che la chiave deve andare invece lì. Controlla anche che pubkeyauthentication dica yes.

RSA vecchio e PubkeyAcceptedAlgorithms

OpenSSH 8.8 ha disattivato di default la firma ssh-rsa, che usa SHA-1. Ha disattivato la vecchia firma, non le chiavi RSA. Una chiave RSA funziona ancora quando entrambi i lati supportano rsa-sha2-256 o rsa-sha2-512, che OpenSSH supporta dalla versione 7.2.

Se un nuovo client incontra un server troppo vecchio per questo, ssh -v mostra una riga come no mutual signature algorithm, e la chiave non viene mai offerta. La vera soluzione è aggiornare il server. Fino ad allora, consenti la vecchia firma per quel solo host in ~/.ssh/config:

Host oldbox
  PubkeyAcceptedAlgorithms +ssh-rsa
  HostKeyAlgorithms +ssh-rsa

Se un vecchio client si connette a un nuovo server, la stessa riga va nella configurazione di sshd e riguarda ogni utente di quel server:

PubkeyAcceptedAlgorithms +ssh-rsa

Prima di OpenSSH 8.5 l'opzione si chiamava PubkeyAcceptedKeyTypes. Se puoi, passa a una chiave ed25519 e rimuovi queste righe.

Domande

Come aggiungo la mia chiave SSH al server?

Esegui ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server finché l'accesso con password funziona. Se il server accetta solo chiavi, aggiungi la riga del tuo file .pub a ~/.ssh/authorized_keys dalla console del provider, poi esegui chmod 600 sul file.

Perché SSH dice Permission denied (publickey) se la chiave è sul server?

Di solito per i permessi: sshd ignora authorized_keys se la home, .ssh o il file sono scrivibili da altri. Controlla anche che la chiave sia nel file dell'account con cui entri.

Come vedo quale chiave offre SSH?

Esegui ssh -v user@server e cerca le righe Offering public key. Per usare una sola chiave, aggiungi -o IdentitiesOnly=yes e -i con il suo percorso.

Le chiavi RSA funzionano ancora con OpenSSH recente?

Sì. OpenSSH 8.8 ha spento la vecchia firma ssh-rsa con SHA-1, non le chiavi RSA, che funzionano con rsa-sha2-256 o rsa-sha2-512.

Fonti

• ssh(1), manuale OpenBSD
• sshd(8), manuale OpenBSD
• sshd_config(5), manuale OpenBSD
• Note di rilascio di OpenSSH 8.8
• Note di rilascio di OpenSSH 8.5

Guide collegate

• Come generare una chiave SSH ed25519
• Il file authorized_keys spiegato
• "git@github.com: Permission denied (publickey)": come risolvere
• Errore SSH "Too many authentication failures": come risolvere
• WARNING: UNPROTECTED PRIVATE KEY FILE: come correggere i permessi
• Il file di configurazione SSH, con esempi

Altro in Chiavi e accesso

• Come convertire una chiave .ppk in OpenSSH, e viceversa
• Come disabilitare l'accesso con password in SSH
• Come usare una YubiKey o una chiave FIDO2 con SSH (ed25519-sk)
• Come aggiungere una chiave SSH a GitHub
• Come recuperare una chiave pubblica SSH dalla chiave privata
• Chiavi SSH RSA o ed25519: quale conviene usare?

Tutte le guide