Chiavi SSH: configurare l'accesso al server senza password

Una chiave SSH è una coppia di file: la chiave privata resta sul tuo computer, la chiave pubblica viene collocata sul server. Quando ti connetti, il server verifica che tu possieda la chiave privata corrispondente a una delle chiavi pubbliche autorizzate e ti fa entrare senza password. È più comodo della password e molto più sicuro: indovinare una chiave con un attacco a forza bruta è praticamente impossibile. Qui sotto trovi la configurazione completa delle chiavi SSH, dalla generazione fino alla disattivazione dell'accesso con password, con un'analisi degli errori più frequenti.

Come funziona l'autenticazione con chiave

Le chiavi sono asimmetriche. La chiave pubblica (id_ed25519.pub) può essere mostrata a chiunque, perché da essa non si ricava la privata. La chiave privata (id_ed25519) non lascia mai la tua macchina e non viene trasmessa in rete.

Quando ti connetti, il client dichiara al server con quale chiave vuole entrare. Il server cerca quella chiave pubblica nel file ~/.ssh/authorized_keys dell'utente e, se la trova, chiede al client di firmare i dati della sessione con la chiave privata. La firma viene verificata con la chiave pubblica e l'accesso è concesso. La password non viene mai inviata.

Passo 1. Genera la chiave: ssh-keygen

Sul tuo computer (Linux, macOS o Windows 10/11 con OpenSSH integrato) esegui:

ssh-keygen -t ed25519 -C "alena@laptop"

-t specifica l'algoritmo e -C un commento, che finisce in fondo alla chiave pubblica e aiuta a capire di chi è. Ed25519 è l'algoritmo consigliato oggi: chiavi corte, veloci e affidabili. Se il server è molto vecchio e non supporta Ed25519, usa RSA di almeno 3072 bit: ssh-keygen -t rsa -b 4096.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alena/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alena/.ssh/id_ed25519
Your public key has been saved in /home/alena/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Xq3v0m6c1y2pVv8m3N0uYv9yQm0e6dFv5gH2rZt1aBc alena@laptop

Serve una passphrase?

La passphrase cifra la chiave privata sul disco. Se il portatile viene rubato o il file trapela, senza passphrase la chiave è inutilizzabile. Per una chiave personale è consigliabile impostarla; per non digitarla a ogni connessione usa ssh-agent, che tiene la chiave sbloccata in memoria per tutta la sessione.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l      # elenco delle chiavi caricate

Le chiavi senza passphrase sono adatte all'automazione, ad esempio per CI o script di backup. Una chiave del genere va limitata sul server (vedi più avanti).

Passo 2. Copia la chiave pubblica sul server: ssh-copy-id

Il modo più semplice è ssh-copy-id. Si collega una volta con la password, aggiunge la tua chiave pubblica a ~/.ssh/authorized_keys sul server e imposta i permessi corretti.

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/alena/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
deploy@203.0.113.10's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'deploy@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.

Se il server ascolta su una porta non standard, aggiungi -p 2222.

Se ssh-copy-id non è disponibile

Su Windows ssh-copy-id non esiste. La chiave si può inviare a mano con un solo comando:

cat ~/.ssh/id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

I provider cloud di solito chiedono la chiave pubblica già alla creazione del server; la chiave finisce in authorized_keys tramite cloud-init.

Passo 3. Verifica l'accesso

ssh deploy@203.0.113.10

Se non ti viene più chiesta la password (o ti viene chiesta solo la passphrase della chiave), è tutto a posto. Al primo collegamento a un server nuovo, SSH mostra l'impronta della chiave dell'host e chiede se fidarsi. Rispondendo yes l'impronta viene salvata in ~/.ssh/known_hosts, e in futuro SSH avviserà se la chiave del server cambia.

Per capire quali chiavi il client prova e perché il server rifiuta, avvia la connessione in modalità dettagliata:

ssh -v deploy@203.0.113.10

~/.ssh/config: nomi brevi per i server

Con più server, digitare ogni volta utente, IP, porta e percorso della chiave diventa scomodo. Tutto questo si descrive in ~/.ssh/config:

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host bastion
    HostName bastion.example.com
    User alena

Host db-internal
    HostName 10.0.0.15
    User admin
    ProxyJump bastion

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

Ora basta ssh prod, e anche scp, rsync e Git riconoscono questi nomi: rsync -av ./site/ prod:/var/www/.

• IdentitiesOnly yes — usa solo la chiave indicata. Senza questa riga il client prova tutte le chiavi dell'agent e il server, dopo un certo numero di tentativi, può chiudere la connessione prima di arrivare a quella giusta.
• ProxyJump — raggiungere un server interno passando da un server intermedio (bastion) con un solo comando.
• ServerAliveInterval — invia un segnale ogni 60 secondi per evitare che la connessione cada quando è inattiva.

Il file deve avere permessi 600, altrimenti SSH può rifiutarsi di leggerlo: chmod 600 ~/.ssh/config.

Agent forwarding: quando serve e perché è rischioso

A volte dal server bisogna collegarsi ancora altrove, ad esempio per fare git pull da un repository privato. Copiare la chiave privata sul server non è corretto. Si usa invece ssh -A oppure ForwardAgent yes: il server ottiene accesso al tuo agent per la durata della sessione. Ma chiunque abbia i privilegi di root su quel server può usare l'agent mentre sei connesso. Attiva l'inoltro solo su host di cui ti fidi, e per passare da un server intermedio preferisci ProxyJump, che non apre l'agent.

Passo 4. Disattiva l'accesso con password

Finché l'accesso con password è attivo, il server è un bersaglio per gli attacchi a forza bruta. Quando hai verificato che l'accesso con chiave funziona, disattiva le password. Importante: non chiudere la sessione attuale prima di aver verificato l'accesso in una nuova finestra, altrimenti potresti perdere l'accesso al server.

Apri /etc/ssh/sshd_config (oppure, se il file principale include /etc/ssh/sshd_config.d/ con la direttiva Include, crea un file lì) e imposta:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

PermitRootLogin no vieta l'accesso diretto come root: gli amministratori entrano con il proprio utente e ottengono privilegi con sudo. Se senza root non puoi lavorare, usa PermitRootLogin prohibit-password: root potrà entrare solo con la chiave.

Controlla la sintassi e ricarica il servizio:

sudo sshd -t
sudo systemctl reload ssh      # in Debian/Ubuntu; nelle distribuzioni tipo RHEL — sshd

sshd -t non produce output se la configurazione è corretta. Ora, in un nuovo terminale, verifica che l'accesso con chiave funzioni e che con la password il server rifiuti:

$ ssh -o PubkeyAuthentication=no deploy@203.0.113.10
deploy@203.0.113.10: Permission denied (publickey).

Protezione aggiuntiva

Disattivare le password è la misura principale. In seguito di solito si limita la porta 22 con il firewall (ufw allow from 198.51.100.0/24 to any port 22) e si installa fail2ban, che blocca gli IP dopo una serie di tentativi falliti. Lo stato della protezione SSH si vede con sudo fail2ban-client status sshd.

Una chiave per l'automazione si può restringere direttamente in authorized_keys, con opzioni prima della chiave: ad esempio from="198.51.100.7",no-port-forwarding,no-pty ssh-ed25519 AAAA... backup consente l'accesso solo da un indirizzo e senza shell interattiva.

Errori frequenti e come risolverli

Permission denied (publickey)

È l'errore più comune. Le cause, dalla più frequente alla più rara:

1. Permessi errati sul server. sshd ignora authorized_keys se la directory o il file sono scrivibili da altri. Soluzione: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, e la home non deve essere scrivibile dal gruppo o dagli altri.
2. Proprietario sbagliato. Se hai creato i file con sudo, appartengono a root. Soluzione: sudo chown -R deploy:deploy /home/deploy/.ssh.
3. Chiave copiata per l'utente sbagliato. Hai copiato la chiave per root ma entri come deploy, o viceversa.
4. Il client propone la chiave sbagliata. Con ssh -v vedi le righe Offering public key che indicano le chiavi provate. Specifica quella giusta con -i o con IdentityFile.
5. Chiave rovinata durante la copia. La chiave pubblica deve stare su una sola riga. Un a capo introdotto dagli appunti la corrompe.

La causa lato server è nel log: sudo journalctl -u ssh -n 30 (su RHEL -u sshd). Vi compaiono righe come: Authentication refused: bad ownership or modes for directory /home/deploy/.ssh.

UNPROTECTED PRIVATE KEY FILE

Il client rifiuta di usare una chiave privata leggibile da altri utenti. Soluzione: chmod 600 ~/.ssh/id_ed25519.

REMOTE HOST IDENTIFICATION HAS CHANGED

La chiave dell'host non corrisponde a quella salvata in known_hosts. Succede dopo la reinstallazione del server o il cambio di IP, ma lo stesso messaggio compare in un attacco «man in the middle». Accertati che il server sia stato davvero ricreato, poi elimina la vecchia voce: ssh-keygen -R 203.0.113.10.

Too many authentication failures

L'agent ha proposto al server troppe chiavi e il server ha chiuso la connessione per il limite MaxAuthTries. Soluzione: in ~/.ssh/config usa IdentitiesOnly yes e un IdentityFile esplicito.

Conclusioni

La configurazione delle chiavi SSH richiede cinque minuti: ssh-keygen -t ed25519, ssh-copy-id, verifica dell'accesso, poi PasswordAuthentication no e il ricaricamento di sshd tenendo aperta una seconda sessione. Il file ~/.ssh/config evita i comandi lunghi, e i permessi 700/600 risolvono la maggior parte degli errori «Permission denied». SSH, rsync e la protezione del server con firewall e fail2ban sono trattati nel corso con esercizi pratici.