SSH certificates
Chi lavora da anni con SSH sa bene quanto sia potente, ma anche quanto possa diventare ingestibile. Usare le chiavi pubbliche va benissimo… finché non devi gestire più di due server, magari con più utenti, ambienti di staging, produzione e qualche freelance che entra ed esce. È lì che inizia il caos: proliferazione di chiavi, accessi dimenticati, revoche fatte a mano (forse), qualcuno più lungimirante che lo fa con Ansible ma per i più nessuna visibilità reale su chi può accedere a cosa.
È arrivato il momento di cambiare marcia: i certificati SSH risolvono questi problemi alla radice. Ecco perché dovresti iniziare a usarli oggi.
Il problema delle chiavi statiche
La classica authorized_keys funziona, ma non scala. Basta che un utente cambi macchina o che un contratto finisca e il sistema si sporca: chiavi lasciate in giro, account con accessi non più giustificati, revoche che diventano un’operazione manuale (e quindi soggetta a errore).
Dal punto di vista della sicurezza:
- Le chiavi vengono spesso copiate su più dispositivi.
- Pochissimi fanno davvero rotazione periodica.
- Non c’è scadenza automatica.
- Nessuna tracciabilità diretta di chi ha usato cosa, quando.
E peggio ancora: se una chiave privata viene compromessa, l’accesso resta valido per sempre, finché non viene manualmente rimossa da ogni singolo server. Un incubo.
Un nuovo approccio: i certificati SSH
I certificati SSH cambiano radicalmente il modello: niente più chiavi statiche da distribuire. Ogni accesso avviene tramite un certificato temporaneo, firmato da una CA (Certificate Authority) centralizzata.
Come funziona in pratica:
- quando un utente vuole accedere, si autentica presso un servizio centrale;
- se autorizzato, ottiene un certificato valido ad esempio per 8 ore;
- il certificato viene caricato nell’agente SSH, e usato per stabilire la connessione;
- il server verifica che il certificato sia stato firmato dalla CA di fiducia, e controlla se l’utente ha diritto a loggarsi con quel ruolo/utente locale.
Questo sistema consente:
- accessi a tempo (Just-in-time): nessun rischio di dimenticare revoche.
- controllo centralizzato: aggiunta e rimozione degli utenti da un unico punto.
- audit: sai chi ha avuto accesso, quando e con quali privilegi.
- miglior igiene operativa: niente più chiavi lasciate in giro, niente riuso.
Sicurezza al centro
Implementare i certificati SSH significa abbracciare davvero il principio del least privilege. Nessuno ha accesso permanente. Tutto è a tempo e tracciabile. È un modello molto più vicino al mondo Zero Trust, in cui la fiducia si guadagna per sessione, non perenne.
Puoi integrare la richiesta del certificato con:
- un SSO aziendale (LDAP, OAuth2, SAML),
- una verifica MFA,
- un sistema RBAC che assegna permessi solo se e quando servono.
E per ogni certificato rilasciato, puoi loggare:
- l’identità del richiedente,
- l’intervallo di validità,
- i ruoli richiesti.
Il tutto senza toccare le authorized_keys su ogni singolo nodo.
È complicato da implementare?
Sì e no. Serve una CA, configurare i server a fidarsi di essa, gestire i principals (gli utenti/ruoli che possono accedere). Ma una volta messo in piedi, diventa una macchina ben oliata. E per chi vuole accelerare, esistono strumenti e piattaforme che automatizzano tutta la parte più noiosa.
Nel mio caso, ho optato per una CA minimale fatta in casa con ssh-keygen, due chiavi (una per firmare gli utenti, una per firmare i server), un po’ di configurazione su sshd_config e qualche script per emettere certificati a scadenza.
Conclusione
Il futuro dell’accesso SSH non è nelle chiavi statiche ma nei certificati dinamici. Se vuoi scalare, automatizzare e soprattutto dormire tranquillo la notte, ti consiglio di fare il salto.
Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.
Risorse: