SSH Certificate Authority con step-ca: accessi brevi e revocabili nell’homelab

Distribuire una chiave pubblica in ogni authorized_keys funziona con due server. Quando utenti, VM e container aumentano, però, la gestione diventa fragile: non è semplice sapere dove sia presente una chiave, la rimozione è manuale e una credenziale dimenticata può restare valida per anni. Una SSH Certificate Authority risolve il problema facendo firmare le chiavi degli utenti da un’autorità fidata. I server non devono conoscere ogni singola chiave: devono fidarsi soltanto della chiave pubblica della CA.

In un homelab o in una piccola infrastruttura, step-ca di Smallstep offre un’implementazione gestibile in proprio. Il vantaggio operativo più importante non è eliminare le chiavi SSH, ma trasformarle in credenziali brevi: una chiave privata resta sul client, mentre il certificato firmato può scadere dopo poche ore.

Come cambia il modello di accesso

Nel modello tradizionale il server confronta la chiave presentata dal client con quelle elencate in authorized_keys. Con una CA, sshd verifica invece firma, validità temporale e principal del certificato. Il principal rappresenta l’identità autorizzata, per esempio danp, sysadmin oppure un ruolo operativo.

Il flusso è questo:

l’amministratore crea e protegge la CA SSH;
ogni server riceve soltanto la chiave pubblica della CA;
l’utente si autentica presso step-ca tramite un provisioner;
la CA firma la chiave pubblica dell’utente per un periodo limitato;
OpenSSH accetta il certificato solo se firma, scadenza e principal sono validi.

La CA diventa quindi un componente sensibile. Non va esposta senza criterio e deve essere inclusa nel piano di backup, monitoraggio e ripristino.

Prerequisiti e inizializzazione

Servono una macchina dedicata alla CA, DNS e sincronizzazione NTP affidabili. Una VM minimale è sufficiente per un piccolo ambiente; evita però di collocarla sullo stesso host che potresti dover recuperare durante un guasto. Installa step-cli sui client e step-ca sulla macchina che emetterà i certificati, seguendo i pacchetti ufficiali per la distribuzione utilizzata.

L’inizializzazione interattiva crea configurazione, certificato root e chiavi dell’autorità:

step ca init --ssh

Usa un nome DNS stabile, per esempio ca.lab.example, e non un indirizzo IP destinato a cambiare. Conserva separatamente password e materiale di recupero. In produzione è preferibile proteggere la chiave con KMS o HSM; in homelab almeno limita permessi, accesso amministrativo e copie del filesystem.

Avvia la CA come servizio systemd e verifica la catena di fiducia dal client:

step ca bootstrap --ca-url https://ca.lab.example:9000 \
  --fingerprint SHA256_DELLA_ROOT
step ca health

Il fingerprint deve arrivare attraverso un canale fidato. Accettarlo dalla stessa pagina o sessione che potrebbe essere compromessa annulla la verifica iniziale.

Configurare i server OpenSSH

Esporta la chiave pubblica usata dalla CA per firmare i certificati SSH degli utenti e copiala su ogni server, per esempio in /etc/ssh/ssh_user_ca_key.pub. Proprietario e permessi devono impedirne modifiche non autorizzate:

chown root:root /etc/ssh/ssh_user_ca_key.pub
chmod 0644 /etc/ssh/ssh_user_ca_key.pub

Aggiungi poi a /etc/ssh/sshd_config:

TrustedUserCAKeys /etc/ssh/ssh_user_ca_key.pub

Prima del reload valida sempre la sintassi e lascia aperta una seconda sessione amministrativa:

sshd -t && systemctl reload ssh

Su alcune distribuzioni il servizio si chiama sshd. Non disabilitare subito authorized_keys: mantieni una chiave di emergenza distinta, custodita offline e verificata periodicamente. Solo dopo il collaudo puoi ridurre le chiavi permanenti e vietare password e accesso diretto di root.

Emettere e usare un certificato breve

Sul client genera una chiave moderna se non ne possiedi una dedicata:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_lab

La richiesta di certificato dipende dal provisioner configurato. Con l’integrazione SSH di step il comando tipico è:

step ssh login danp --provisioner oidc

Un provisioner OIDC consente di delegare l’autenticazione a un identity provider e applicare MFA. Per test iniziali è possibile usare altri provisioner, ma una password condivisa non offre la stessa tracciabilità. Controlla il certificato ricevuto:

ssh-keygen -L -f ~/.ssh/id_ed25519-cert.pub

L’output deve mostrare CA, intervallo di validità e principals previsti. Verifica infine l’accesso con output verboso:

ssh -v server.lab.example

Imposta durate coerenti con il rischio: da quattro a otto ore è un buon punto di partenza per gli utenti; automazioni e account tecnici richiedono un disegno separato, identità dedicate e rinnovo non interattivo controllato.

Revoca: cosa significa davvero

I certificati brevi riducono la finestra di esposizione, ma la revoca immediata non avviene magicamente. OpenSSH può consultare un file RevokedKeys, distribuito e aggiornato sui server. Puoi revocare certificati specifici o chiavi compromesse, ma la procedura deve essere automatizzata e provata.

Per incidenti ordinari, la combinazione di durata breve, blocco dell’identità nel provider e mancato rinnovo è spesso più semplice. Per una compromissione attiva, distribuisci la revoca e verifica i log su tutti i nodi. Se viene compromessa la chiave della CA, occorre sostituire la chiave fidata su ogni server: è un incidente di massima priorità.

Checklist di messa in produzione

DNS e NTP sono ridondanti e monitorati.
La root e la chiave SSH della CA hanno backup cifrati, offline e testati.
Il fingerprint iniziale è verificato fuori banda.
I principals seguono ruoli chiari e non concedono privilegi impliciti.
La durata dei certificati è breve e documentata.
sshd -t viene eseguito prima di ogni reload.
Una sessione e una chiave di emergenza restano disponibili durante il rollout.
Log di emissione, login e tentativi falliti confluiscono nel sistema centrale.
Revoca, rotazione della CA e disaster recovery sono provati, non soltanto descritti.

Parti con due server non critici e un piccolo gruppo di amministratori. Misura rinnovi falliti, differenze di orario e principals errati, poi automatizza la distribuzione della chiave pubblica con Ansible. Una SSH CA non sostituisce segmentazione, MFA o hardening, ma elimina una delle attività più soggette a errori: inseguire chiavi statiche su decine di sistemi.