Configurare SSH con chiave pubblica

Configurare l'accesso SSH con chiave pubblica e il primo, indispensabile passo per mettere in sicurezza qualsiasi server Linux. Le chiavi crittografiche, se gestite correttamente, sono molto più sicure delle password, immuni ai brute force e permettono automazioni avanzate.

Generare la coppia di chiavi

Sul client esegui ssh-keygen -t ed25519 -C "tuo.nome@dominio". L'algoritmo ed25519 e raccomandato dal 2026 per velocità e sicurezza; rsa-4096 resta valido per compatibilità con sistemi più vecchi. Imposta una passphrase robusta: senza, chi compromette la macchina ottiene accesso a tutti i server. La chiave privata risiede in ~/.ssh/id_ed25519, la pubblica in ~/.ssh/id_ed25519.pub.

Copiare la chiave sul server

Il modo più semplice e ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server: copia il contenuto in ~/.ssh/authorized_keys sul server con permessi corretti. In alternativa, manualmente: crea la directory .ssh con permessi 700, il file authorized_keys con 600, e incollaci il contenuto della chiave pubblica.

Hardening di sshd_config

Modifica /etc/ssh/sshd_config: PermitRootLogin no, PasswordAuthentication no, PubkeyAuthentication yes, ChallengeResponseAuthentication no, UsePAM yes, AllowUsers admin. Per maggiore controllo aggiungi MaxAuthTries 3, ClientAliveInterval 300, ClientAliveCountMax 2. Riavvia con systemctl restart sshd mantenendo una sessione aperta come safety net.

Procedura passo-passo

1. Genera una coppia di chiavi ed25519 con passphrase robusta.
2. Copia la chiave pubblica sul server con ssh-copy-id.
3. Verifica il login con chiave: ssh -i ~/.ssh/id_ed25519 user@server.
4. Modifica sshd_config disabilitando password authentication.
5. Riavvia sshd mantenendo una shell aperta.
6. Da un'altro terminale prova il login: se fallisce, rimedia sulla sessione aperta.
7. Aggiungi la chiave all ssh-agent per evitare di reinserire la passphrase.
8. Configura ~/.ssh/config con alias per i server più usati.
9. Pianifica rotazione delle chiavi ogni 12-24 mesi.

Uso di ssh-agent

L'agent SSH conserva la chiave decrittata in memoria. Avvialo con eval "$(ssh-agent -s)" e aggiungi la chiave con ssh-add ~/.ssh/id_ed25519. Su macOS e Linux desktop e gestito dal session manager. Per inoltrare l'agent su un'host bastion usa ForwardAgent yes in ~/.ssh/config, ma solo verso host fidati.

Errori comuni e come risolverli

• "Permission denied (publickey)": controlla permessi (700 directory, 600 file), proprietario corretto, contenuto chiave senza spazi spuri.
• Chiave senza passphrase: rischio elevato se il client viene compromesso; usa sempre una passphrase.
• Forward agent verso host non fidati: chi controlla l'host puo usare la tua chiave.
• Backup della chiave privata in cloud: cifra con GPG o usa un password manager dedicato.

Domande frequenti

D: Quante chiavi dovrei usare?
R: Una chiave per contesto (lavoro, personale, automazioni); evita di riutilizzare la stessa ovunque.

D: Posso usare hardware token come Yubikey?
R: Si, sono altamente raccomandati per accessi privilegiati.

D: Ed25519 e supportato ovunque?
R: Si dal 2014, su qualsiasi OpenSSH moderno (>= 6.5).

Approfondimento tecnico: ssh-agent forwarding e CA SSH

L ssh-agent forwarding (-A o ForwardAgent yes) permette di usare la chiave SSH del client locale anche dopo aver "rimbalzato" su un bastion host. Comodo, ma rischioso: chi ha root sul bastion puo usare temporaneamente la tua chiave per altri server. Per ambienti enterprise si preferiscono jump host via -J (ProxyJump) o SSH bastion senza forwarding.

L SSH Certificate Authority e una soluzione enterprise: invece di distribuire chiavi pubbliche per ogni utente su ogni server, il server fida una CA e accetta automaticamente certificati firmati da essa con tempo di validita breve. Soluzioni come Hashicorp Vault, Smallstep, Teleport, BastionZero implementano questo pattern.

Scenari d'uso reali

Un team DevOps di 10 persone gestisce 50 server: senza CA, ogni nuovo utente richiede aggiornare authorized_keys su tutti. Con SSH CA, basta firmare il certificato.

Un sysadmin freelance usa chiavi ed25519 distinte per ogni cliente, ~/.ssh/config con alias e ProxyJump per bastion: workflow pulito e isolato.

Un operatore in viaggio usa Yubikey FIDO2 + ssh-add per accessi privilegiati: la chiave privata non lascia mai il token.

Checklist operativa SSH

• Algoritmo ed25519 per nuove chiavi.
• Passphrase robusta su ogni chiave privata.
• PasswordAuthentication disabilitata sul server.
• Root login disabilitato (PermitRootLogin no).
• MaxAuthTries 3, ClientAliveInterval 300.
• Rotazione delle chiavi ogni 12-24 mesi.
• Audit delle chiavi autorizzate trimestrale.

Risorse e riferimenti

OpenSSH manuali (ssh, sshd_config, ssh_config). Mozilla SSH guidelines: infosec.mozilla.org/guidelines/openssh. Per gestione chiavi enterprise: Hashicorp Vault SSH secrets, Teleport, Smallstep step-ca. Hardware key: Yubikey con OpenSSH 8.2+.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su configurare ssh con chiave pubblica richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.