Chiavi SSH: come funzionano e come configurarle

Le chiavi SSH sono una di quelle cose che sembrano complicate finché non le configuri una volta, e dopo ti chiedi perché hai usato le password per anni. Sono più sicure e più comode insieme — una combinazione rara. In questo articolo trovi come funzionano, come si configurano e come si gestiscono quando diventano più di una.

Come funzionano

Una chiave SSH è una coppia di file matematicamente collegati: una chiave privata che resta sul tuo computer e non esce mai da lì, e una chiave pubblica che installi sui server.

Il meccanismo, semplificando:

1. Ti colleghi al server
2. Il server ti manda una sfida, cifrata con la tua chiave pubblica
3. Il tuo computer la risolve usando la chiave privata
4. Il server verifica la risposta e ti fa entrare

Il punto che rende tutto questo sicuro: la chiave privata non viene mai trasmessa. Non viaggia in rete, non arriva al server, non può essere intercettata.

È la differenza sostanziale con le password, che devono essere inviate ogni volta e possono essere indovinate con tentativi ripetuti. Una chiave non si indovina.

Generarne una

ssh-keygen -t ed25519 -C "la-tua-email"

Sul tipo di chiave: ed25519 è la scelta attuale — moderna, corta, veloce. Il vecchio rsa funziona ancora e serve solo per sistemi datati che non supportano il nuovo standard; in quel caso usa almeno 4096 bit.

Ti verranno chieste due cose:

Dove salvarla — l'impostazione predefinita va bene, a meno che tu non ne stia creando una seconda.

Una passphrase — e qui la risposta giusta è sì, mettila.

Perché la passphrase conta: se qualcuno accede al tuo computer e copia la chiave privata, senza passphrase può entrare in tutti i tuoi server. Con la passphrase, la chiave da sola non basta.

E non è scomoda, perché l'agent la ricorda — ci arrivo tra poco.

Ottieni due file:

~/.ssh/id_ed25519        # PRIVATA — non condividere mai
~/.ssh/id_ed25519.pub    # pubblica — questa si distribuisce

Installarla su un server

Il modo semplice:

ssh-copy-id utente@server

Chiede la password quella volta sola, poi installa la chiave pubblica al posto giusto.

Se il comando non è disponibile, si fa a mano aggiungendo il contenuto del file .pub al file ~/.ssh/authorized_keys sul server, che deve avere permessi 600 e stare in una cartella .ssh a 700.

Su un server appena creato, la maggior parte dei provider permette di indicare la chiave pubblica in fase di creazione: è la strada migliore, perché la macchina nasce già senza accesso con password.

L'agent: la parte comoda

L'agent è il programma che tiene in memoria le chiavi sbloccate, così digiti la passphrase una volta per sessione invece che a ogni connessione.

ssh-add ~/.ssh/id_ed25519     # aggiungi la chiave all'agent
ssh-add -l                     # vedi quali sono caricate

Su macOS e sulla maggior parte delle distribuzioni desktop l'agent parte da solo e si integra con il portachiavi di sistema.

È questo che rende le chiavi più comode delle password: sicurezza superiore e zero digitazioni.

Gestire più chiavi

Quando hai un server di lavoro, uno personale, GitHub e un cliente, serve un po' di ordine.

Il file di configurazione fa tutto il lavoro — ~/.ssh/config:

Host github.com
    User git
    IdentityFile ~/.ssh/id_github

Host lavoro
    HostName 10.0.0.5
    User edoardo
    IdentityFile ~/.ssh/id_lavoro

Host cliente
    HostName server.cliente.it
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_cliente

Da lì in poi: ssh lavoro, ssh cliente. La chiave giusta viene scelta automaticamente.

Vale la pena avere chiavi separate per contesti separati: se una viene compromessa, revochi quella senza toccare le altre. Una chiave sola per tutto è comoda finché non è un problema.

Cosa NON fare

Non condividere mai la chiave privata. Se qualcuno ti chiede la chiave per darti accesso, sta chiedendo quella pubblica — quella con estensione .pub. Se chiede l'altra, qualcosa non va.

Non metterla in un repository. È l'errore grave: una chiave privata finita in un repository va considerata compromessa e da sostituire, non solo da rimuovere — perché resta nella storia, come spiego in file .gitignore.

Non usare la stessa chiave ovunque, per il motivo detto sopra.

Non lasciarla senza passphrase, salvo casi specifici come le chiavi di automazione (che però vanno protette diversamente, con permessi ristretti e accesso limitato).

Non ignorare i permessi. SSH si rifiuta di usare una chiave privata leggibile da altri: deve essere a 600. Non è pignoleria, è una protezione — vedi permessi dei file Linux.

Se perdi una chiave

Due scenari diversi.

Hai perso il computer o sospetti una compromissione:

1. Rimuovi la chiave pubblica dal file authorized_keys di tutti i server
2. Revocala sui servizi dove l'hai registrata (GitHub, provider cloud)
3. Generane una nuova e reinstallala

Il tempo conta: finché quella chiave pubblica resta installata da qualche parte, quella porta è aperta.

Hai semplicemente cancellato la chiave privata per errore:

Non è recuperabile — matematicamente non si ricostruisce dalla pubblica. Serve generarne una nuova e reinstallarla ovunque. È il motivo per cui vale la pena avere un accesso alternativo (la console web del provider, per esempio) prima di disattivare l'accesso con password.

Le chiavi per l'automazione

Un caso a parte che si incontra spesso: un sistema di deploy automatico che deve collegarsi a un server.

Non può avere una passphrase (nessuno la digiterebbe), quindi servono altre protezioni:

• Una chiave dedicata, usata solo per quello
• Permessi minimi sull'utente a cui è associata
• Restrizioni nel file authorized_keys: si può limitare una chiave a eseguire un solo comando specifico
• Conservata come segreto nel sistema di automazione, mai nel repository

Il principio è quello del privilegio minimo: quella chiave deve poter fare esattamente una cosa.

In sintesi

Una chiave SSH è una coppia: privata sul tuo computer, pubblica sui server. La privata non viene mai trasmessa, ed è per questo che il meccanismo è molto più sicuro di una password.

Si genera con ssh-keygen -t ed25519, con passphrase — che non è scomoda, perché l'agent la ricorda per tutta la sessione.

Con più server, il file di configurazione è ciò che rende tutto gestibile: nomi brevi al posto di indirizzi, chiave giusta scelta in automatico. E chiavi separate per contesti separati, così una compromissione non le tocca tutte.

Le regole che evitano i danni: mai condividere la privata, mai metterla in un repository, mai ignorare i permessi — SSH si rifiuta di usare una chiave leggibile da altri, e fa bene.

Se non hai ancora familiarità con la connessione a un server, il punto di partenza è cos'è SSH.