Chiavi SSH: crearne una e usarla senza farsi chiudere fuori

Introduzione

SSH è il modo normale per entrare in un server Linux. Molti lo usano ancora con utente e password. Funziona. È anche il primo bersaglio di chi prova login a raffica.

Una chiave SSH è un paio di file. Uno resta sul tuo PC. L'altro va sul server. Chi ha la chiave privata entra. Chi ha solo la password, no, se la disabiliti.

Questa guida ti porta dal nulla a un login che funziona, senza chiuderti fuori. In ordine:

• cosa sono chiave privata e chiave pubblica
• come crearle con ssh-keygen e ed25519
• dove vanno sul server (authorized_keys)
• come copiarle con ssh-copy-id
• quando (e solo quando) togliere il login a password
• agent, passphrase, Windows
• errori che sembrano "il server è rotto" e non lo è

Cos'è una coppia di chiavi

Non è un "codice segreto" da digitare. Sono due file matematicamente legati.

• Chiave privata: resta sul client. Non la copi, non la mandi, non la incolli in una chat. Se la perdi, ne crei un'altra. Se la rubano, chiunque può entrare come te.
• Chiave pubblica: va sul server, in un file che si chiama authorized_keys. Puoi condividerla. Non apre nulla da sola.

Quando ti connetti, il server ti sfida. Il client firma la sfida con la privata. Il server verifica con la pubblica. Se torna, sei tu.

Perché ed25519 e non RSA

ssh-keygen può generare tipi diversi. Per un server nuovo, ed25519 è la scelta di default oggi: chiave corta, veloce, solida.

RSA va ancora. Serve se hai un sistema vecchio che non accetta ed25519. Non è il caso di un Ubuntu o Debian recente.

Creare la chiave sul tuo PC

Apri un terminale. Su Linux e macOS è già lì. Su Windows 10/11 puoi usare PowerShell o il "Prompt dei comandi": OpenSSH client è incluso.

ssh-keygen -t ed25519 -C "tuo-nome@tuo-pc"

-C è un commento. Serve a te, per capire quale chiave è. Non è una password.

Ti chiede un percorso. Il default va bene:

• Linux/macOS: ~/.ssh/id_ed25519
• Windows: C:\Users\TUO_UTENTE\.ssh\id_ed25519

Poi chiede una passphrase. Mettila. Non è la password del server. Protegge il file sul disco. Se qualcuno copia la chiave privata e non ha la passphrase, non entra.

Al termine hai due file:

ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

• id_ed25519 — privata. Permessi stretti.
• id_ed25519.pub — pubblica. Questa la copi.

Se l'hai già incollata da qualche parte, considerala bruciata. Generane un'altra. Togli la pubblica vecchia da authorized_keys.

Cosa finisce sul server: authorized_keys

Sul server, per ogni utente, SSH guarda:

/home/UTENTE/.ssh/authorized_keys

Per root (meglio non usarlo per il login quotidiano):

/root/.ssh/authorized_keys

È un file di testo. Ogni riga è una chiave pubblica. Una riga, una chiave. Puoi averne più di una: portatile, PC fisso, chiave di emergenza.

Il contenuto assomiglia a questo (troncato):

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... tuo-nome@tuo-pc

Permessi: il dettaglio che blocca tutto

SSH è paranoico sui permessi. Se la cartella .ssh o il file sono scrivibili da altri, ignora le chiavi. Sembra un bug. Non lo è.

Sul server, da quell'utente:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

La chiave privata, sul client:

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

Su Windows i permessi si gestiscono in modo diverso. OpenSSH si lamenta se la cartella .ssh è ereditata da "Users". Il messaggio parla di "bad permissions". Si sistema togliendo l'ereditarietà e lasciando solo il tuo utente e SYSTEM.

Copiare la chiave: ssh-copy-id

Il modo pulito, da Linux o macOS (e da Windows se hai OpenSSH recente):

ssh-copy-id -i ~/.ssh/id_ed25519.pub utente@IP_O_HOSTNAME

Ti chiede la password del server, un'ultima volta. Poi scrive la pubblica in authorized_keys e sistema i permessi.

Se ssh-copy-id non c'è (Windows vecchio, qualche ambiente minimale), lo fai a mano. Una riga, senza spezzarla:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh utente@IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Su Linux, equivalente:

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

Verificare prima di toccare sshd_config

Apri una nuova sessione. Non chiudere quella in cui sei già dentro.

ssh -i ~/.ssh/id_ed25519 utente@IP

Se entra senza chiedere la password del server, la chiave funziona. Può chiedere la passphrase della chiave. È un altro conto.

Per vedere cosa sta succedendo:

ssh -v utente@IP

Cerca righe tipo Offering public key e Authentication succeeded. Se offre la chiave sbagliata, specifica -i.

Se non entra, non disabilitare nulla. Vai alla sezione errori.

Disabilitare il login a password (solo dopo)

Il file è /etc/ssh/sshd_config sul server. A volte c'è anche un file in /etc/ssh/sshd_config.d/. Su Ubuntu recente, spesso è lì che si mette la tua regola.

Prima, una copia:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Poi i valori che contano:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password

ChallengeResponseAuthentication sui sistemi vecchi va messo a no. Altrimenti la password rientra dalla finestra.

Controlla la sintassi prima di riavviare:

sudo sshd -t

Se non stampa errori:

sudo systemctl reload sshd

Su alcune distro il servizio si chiama ssh, non sshd:

sudo systemctl reload ssh

Se il server è su un cloud con console seriale o "VNC di emergenza", tieni a mente dove si accende. Se non ce l'hai, non sperimentare su un VPS lontano senza un piano B.

Agent e passphrase: non digitare ogni volta

La passphrase protegge il file. L'agent tiene la chiave sbloccata in memoria, per quella sessione.

Su Linux, di solito ssh-agent parte con la sessione grafica. Aggiungi la chiave:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

Su macOS, Keychain può ricordarla. Su Windows, il servizio "OpenSSH Authentication Agent" va avviato e impostato su automatico, poi:

ssh-add $env:USERPROFILE\.ssh\id_ed25519

ssh-add -l elenca le chiavi caricate. Se è vuoto, l'agent non sta servendo nulla.

Una chiave per ambiente, non una per tutto

Puoi avere più chiavi. Un file per il lavoro, uno per i server personali. In ~/.ssh/config:

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

Host lab
  HostName 192.168.1.50
  User relic
  IdentityFile ~/.ssh/id_ed25519

Poi: ssh vps-produzione.

IdentitiesOnly yes evita che il client provi dieci chiavi e il server ti chiuda per troppi tentativi.

Se usi container e ti chiedi come entra SSH in quel mondo, la guida Docker per principianti è il passo dopo. La chiave resta sul host. Non la copi dentro l'immagine.

Windows: OpenSSH e PuTTY

Due mondi. Non mescolarli a caso.

Se hai una chiave OpenSSH e un collega ti chiede un .ppk, in PuTTYgen: Conversions → Import key, poi salva la privata PuTTY. Non è una nuova coppia. È lo stesso materiale in un altro involucro.

Se crei la chiave in PuTTYgen, esporta la pubblica in una riga ssh-ed25519 .... Il riquadro grande di PuTTY non è il formato di authorized_keys. Copiarlo così com'è è un errore classico.

Errori comuni (e cosa controllare)

Permission denied (publickey)

Il server non ha accettato nessuna chiave. Non significa "chiave rotta". Significa: utente sbagliato, file sbagliato, permessi, o la pubblica non è sul server.

Checklist, in questo ordine:

1. Stai usando l'utente giusto? ubuntu, debian, root, deploy non sono intercambiabili.
2. La pubblica è in quel ~/.ssh/authorized_keys, non in quello di un altro utente.
3. Permessi: 700 sulla cartella, 600 sul file, proprietario = quell'utente.
4. Stai offrendo la chiave giusta? ssh -i o IdentityFile.
5. sshd è stato ricaricato dopo le modifiche?

ssh -i ~/.ssh/id_ed25519 -l utente IP

Funziona in IPv4, fallisce "a caso"

Molti hostname hanno sia A che AAAA. Il client prova IPv6. La regola del firewall o del security group è solo su IPv4. Il sintomo è timeout, non "password sbagliata".

Forza IPv4 per capire:

ssh -4 utente@hostname

Se così entra, il problema non è la chiave. È la rete. Sistema AAAA, firewall, o tieni -4 nel Host di ~/.ssh/config.

Too many authentication failures

Il client ha provato troppe chiavi. Il server taglia. Sintomo tipico se hai 8 file in .ssh e nessun IdentitiesOnly.

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519 utente@IP

Host key verification failed

Non è la tua chiave utente. È l'impronta del server che è cambiata. Può essere un reinstall. Può essere qualcuno in mezzo.

Non cancellare la riga in known_hosts di slancio. Verifica fuori banda (pannello cloud, collega, console) che l'host sia quello. Poi, se è legittimo:

ssh-keygen -R IP_O_HOSTNAME

La chiave va, ma sudo chiede ancora la password

Normale. SSH ti fa entrare. sudo è un altro meccanismo. Non si "sistema" disabilitando la password SSH. Non mescolare le due cose.

Cosa non fare mai

Un fail2ban o un security group che ammette solo il tuo IP aiuta. Non sostituisce la chiave. La chiave non sostituisce gli aggiornamenti. Se stai costruendo un ambiente di lavoro su Linux, tieni accanto Iniziare a usare Linux: utente, permessi e sudo sono la stessa famiglia di problemi.

Conclusione

Una chiave SSH non è un rito. È un file privato sul client, una riga pubblica sul server, permessi giusti, e un test prima di togliere la password.

Ordine che non si inverte:

1. Genera ed25519 con passphrase
2. Copia la pubblica (ssh-copy-id o append controllato)
3. Entra da una sessione nuova
4. Solo allora PasswordAuthentication no
5. Tieni agent e ~/.ssh/config in ordine, così non lotti ogni mattina

Se qualcosa non torna, è quasi sempre utente, permessi, chiave sbagliata o IPv6. Non il "mistero di SSH".

Risorse utili (autorevoli):

• OpenSSH manuale ssh-keygen — opzioni e formati, dal progetto OpenSSH
• OpenSSH sshd_config — direttive del server, comprese password e chiavi
• Ubuntu Server: OpenSSH — installazione e hardening sul ramo Ubuntu
• Debian Wiki: SSH — note pratiche su chiavi, agent e permessi