SSH dal lato client: chiavi, file config, scp e rsync

SSH è il modo standard per lavorare su un computer remoto da terminale, e si usa sia per amministrare server sia per inviare codice a un repository. Molti però lo usano nella forma più faticosa: indirizzo IP da ricordare, password digitata ogni volta, file copiati con strumenti grafici. Con le chiavi, un file di configurazione ben scritto e due comandi per i trasferimenti, il lavoro quotidiano diventa più rapido e anche più sicuro. Qui mi occupo del lato client, cioè del computer da cui ti colleghi.

Le chiavi: come funzionano

Una coppia di chiavi è formata da una chiave privata, che resta sul tuo computer e non va mai condivisa, e da una chiave pubblica, che copi sui server a cui vuoi accedere. Quando ti colleghi, il server propone una sfida che solo chi possiede la chiave privata può risolvere. La password non viaggia, e un attacco basato sul tentare password diverse diventa inutile.

Per generare una coppia moderna:

ssh-keygen -t ed25519 -C "portatile-anna"

Il tipo ed25519 produce chiavi corte, veloci e robuste. Il commento serve solo a riconoscere la chiave quando ne avrai diverse. Il programma chiede una passphrase: conviene impostarla, perché protegge la chiave privata se il computer viene rubato o il disco copiato. I file vengono salvati in ~/.ssh/id_ed25519, la privata, e ~/.ssh/id_ed25519.pub, la pubblica.

Copiare la chiave sul server

Il modo più semplice:

ssh-copy-id utente@server.esempio.it

Il comando chiede la password un'ultima volta e aggiunge la chiave pubblica al file ~/.ssh/authorized_keys sul server. Dal collegamento successivo l'accesso avviene con la chiave. Molti pannelli dei fornitori di server permettono anche di incollare la chiave pubblica al momento della creazione della macchina.

ssh-agent: la passphrase una volta sola

Digitare la passphrase a ogni collegamento è scomodo. Lo ssh-agent tiene la chiave sbloccata in memoria per la durata della sessione:

ssh-add ~/.ssh/id_ed25519
ssh-add -l

Sui desktop Linux più diffusi e su macOS l'agente è già attivo e collegato al portachiavi del sistema. Su macOS, con l'opzione UseKeychain yes nel file di configurazione, la passphrase viene memorizzata nel Portachiavi.

Il file ~/.ssh/config

È lo strumento che fa risparmiare più tempo. Ogni blocco definisce un alias con le sue impostazioni:

Host produzione
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519

Host backup
    HostName backup.esempio.it
    User anna
    ProxyJump produzione

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

Con questa configurazione ssh produzione sostituisce ssh -p 2222 -i ~/.ssh/id_ed25519 deploy@203.0.113.10. Il secondo blocco mostra ProxyJump: per raggiungere un server non esposto a Internet si passa attraverso un altro, in modo trasparente. Il blocco Host * vale per tutti i collegamenti: ServerAliveInterval invia un segnale periodico ed evita che una connessione inattiva venga chiusa da un router.

Gli alias funzionano anche con scp, rsync e Git, che usano SSH sotto il cofano. Il file deve essere leggibile solo da te: chmod 600 ~/.ssh/config.

La prima connessione e l'impronta del server

Al primo collegamento SSH mostra l'impronta della chiave del server e chiede conferma. Una volta accettata, la salva in ~/.ssh/known_hosts. Se un giorno compare l'avviso che l'identificazione del server è cambiata, non va ignorato: può essere una reinstallazione legittima, ma anche un'intercettazione. Prima di rimuovere la vecchia voce con ssh-keygen -R nomehost, conviene verificare l'impronta con chi gestisce il server.

Copiare file con scp

Per trasferimenti singoli scp usa la stessa sintassi di cp, con il server indicato come alias:percorso:

scp report.pdf produzione:/home/deploy/
scp produzione:/var/log/nginx/error.log .
scp -r cartella/ produzione:/srv/

Sincronizzare con rsync

Quando i file sono molti, o il trasferimento va ripetuto, rsync è nettamente superiore: confronta origine e destinazione e copia solo ciò che è cambiato.

rsync -avz --progress sito/ produzione:/var/www/sito/

Le opzioni: -a conserva permessi, date e collegamenti; -v mostra i dettagli; -z comprime durante il trasferimento. Due accorgimenti evitano gli errori più comuni:

• la barra finale sull'origine conta: sito/ copia il contenuto della cartella, sito copia la cartella stessa dentro la destinazione;
• --delete elimina dalla destinazione i file non più presenti nell'origine, ed è potente quanto pericoloso. Prima di usarlo, una prova con -n (--dry-run) mostra cosa succederebbe senza toccare nulla.

Nel mio lavoro rsync -avn --delete seguito dalla lettura attenta dell'elenco è un passaggio fisso prima di ogni sincronizzazione su un server in produzione.

Buone abitudini

• Una chiave per dispositivo, così se perdi un portatile revochi solo quella.
• Passphrase sempre impostata sulle chiavi private.
• Permessi corretti: chmod 700 ~/.ssh e chmod 600 sui file privati, altrimenti SSH può rifiutarsi di usarli.
• Rimuovere da authorized_keys le chiavi che non servono più.

In sintesi

• Le chiavi ed25519 con passphrase sostituiscono le password e resistono ai tentativi automatici.
• ssh-copy-id installa la chiave sul server, ssh-agent evita di ridigitare la passphrase.
• ~/.ssh/config trasforma indirizzi, porte e utenti in alias brevi, anche con ProxyJump.
• scp per copie singole, rsync per trasferimenti ripetuti o grandi.
• Prima di rsync --delete, sempre una prova con --dry-run.