Una vecchia chiave di amministrazione è ancora nella cartella del progetto. Funziona su diversi server, ma nessuno sa più con certezza chi ne possieda una copia. Il passaggio dalle password alle chiavi SSH ha cambiato l’autenticazione senza chiarire le responsabilità.
Una gestione SSH efficace collega identità individuali, permessi adeguati sui sistemi di destinazione e revoca affidabile. Secondo l’ambiente, possono bastare chiavi pubbliche mantenute con un inventario accurato. Gli ambienti più grandi o soggetti a frequenti cambiamenti possono beneficiare di certificati SSH di breve durata. Entrambi gli approcci richiedono una gestione sostenibile.
Quattro elementi da non confondere
La chiave privata dell’utente permette di dimostrare la propria identità. Viene custodita in modo protetto e non distribuita tramite chat, email o cartelle di progetto non protette. La corrispondente chiave pubblica può essere registrata sui sistemi previsti per autorizzare l’accesso. La sua impronta consente di identificarla senza ambiguità nell’inventario.
La chiave host identifica invece il server contattato. La verifica dell’host impedisce che una connessione raggiunga un interlocutore sbagliato senza che l’utente se ne accorga. Un certificato SSH aggiunge a una chiave pubblica una dichiarazione firmata, ad esempio su identità e validità. I certificati OpenSSH usano un formato proprio e non sono comuni certificati TLS/X.509.
Separare gli accessi personali dai processi automatici
Le attività amministrative vengono assegnate a persone e compiti autorizzati. Una chiave root condivisa e di lunga durata rende inutilmente difficili l’uscita di una persona, la rotazione e la tracciabilità. Accessi individuali con privilegi amministrativi regolati offrono una base migliore.
Un processo di backup o distribuzione necessita di un’identità tecnica propria con responsabilità documentata. Ove possibile, l’accesso viene limitato alla funzione prevista, per esempio tramite un comando obbligato e regole di inoltro adeguate. La chiave privata di un dipendente non dovrebbe diventare silenziosamente un requisito permanente di un processo automatico.
Dall’inventario delle chiavi ai certificati di breve durata
Con pochi sistemi può bastare una distribuzione controllata delle chiavi pubbliche. L’inventario registra persona o servizio, impronta, sistemi di destinazione, ambito e data prevista di verifica o sostituzione. È decisivo mantenere in modo affidabile i permessi su tutte le destinazioni interessate.
Un’autorità di certificazione SSH può invece firmare chiavi pubbliche per un periodo limitato e identità definite. I server si fidano della CA designata e verificano le ulteriori regole. La chiave privata di accesso non deve essere trasmessa alla CA. Le chiavi della CA e le regole di emissione ricevono una protezione particolare.
Una validità breve riduce il periodo di utilizzo della credenziale emessa. Non termina però una sessione già attiva e non sostituisce il processo di revoca. Dopo l’uscita di una persona va impedita anche l’emissione di nuovi certificati. Una piattaforma centrale per i segreti è una possibile modalità operativa, purché supporti realmente il flusso SSH previsto.
| Modalità di gestione | Quando è adatta | Requisiti operativi |
|---|---|---|
| Mantenere le chiavi pubbliche | Un insieme di destinazioni contenuto e ben inventariato. | Distribuzione, rimozione dei vecchi permessi e sostituzione dei responsabili assenti. |
| Emettere certificati SSH | Validità limitata e identità definite. | Protezione della CA, regole di emissione, fiducia dei server e revoca. |
| Identità tecniche | Automazione con un compito chiaro. | Permessi limitati sulle destinazioni, responsabilità e procedure di rotazione. |
| Agent o chiave hardware | Modalità adatte all’autenticazione personale. | Limiti di inoltro, verifica delle versioni e ripristino. |
Usare consapevolmente agent e chiavi hardware
Un agent SSH permette l’autenticazione con le chiavi caricate senza copiare il file della chiave privata su ogni server. Inoltrare l’agent concede però a un sistema remoto l’accesso alle sue capacità di firma. OpenSSH avverte espressamente che un aggressore con accesso sufficiente a quel sistema può autenticarsi con le identità caricate anche senza estrarre il materiale delle chiavi.
L’inoltro dell’agent viene quindi previsto solo per il percorso necessario. Le restrizioni temporali o di destinazione supportate possono aggiungere ulteriori limiti. Le chiavi di sicurezza hardware sono un’altra opzione per accessi interattivi adatti. Client, server, tipo di chiave e requisiti di tocco o PIN devono essere compatibili; un processo non presidiato ha esigenze diverse da un accesso personale.
Rotazione e revoca devono raggiungere la destinazione
Sostituire una chiave sul notebook non elimina il vecchio accesso dal server. Con chiavi pubbliche registrate, occorre aggiornare i permessi su tutte le destinazioni interessate. Per i certificati si possono aggiungere meccanismi come le OpenSSH Key Revocation Lists. La revoca è efficace solo quando i server previsti la applicano correttamente.
La procedura comprende anche la perdita di un dispositivo, una chiave compromessa e un servizio di gestione indisponibile. Un accesso di emergenza indipendente viene protetto, documentato e testato in modo controllato. Il ripristino non deve dipendere proprio dal percorso di accesso che non funziona.
Procedere in modo differenziato in ambienti Linux e Proxmox
Negli ambienti eterogenei si rilevano versioni e funzioni OpenSSH realmente supportate. Un manuale aggiornato non garantisce che ogni installazione Linux disponga delle stesse opzioni. Le nuove regole vengono introdotte con un accesso di prova dedicato e un percorso di ritorno verificato.
Proxmox VE usa SSH anche per proprie funzioni di cluster, tra cui determinati percorsi di console, migrazione e replica. Queste relazioni tecniche di fiducia vanno valutate separatamente dagli accessi personali degli amministratori. Una pulizia indiscriminata o la sovrascrittura dei file delle chiavi può compromettere il funzionamento. Le modifiche si verificano quindi sulla documentazione della versione installata.
Che cosa comprende un primo passo gestibile
DAXS censisce gli accessi SSH esistenti, assegna le responsabilità e pianifica una gestione adeguata. Nel progetto pilota si testano accesso, permessi, revoca, registrazione e ripristino. Un’autenticazione riuscita da sola non basta per il collaudo. Neppure i soli log di accesso costituiscono automaticamente una registrazione completa di tutti i comandi eseguiti.
I servizi di infrastruttura e il contributo su Proxmox in azienda inquadrano la gestione operativa. Per i portali condivisi, il contributo su casseforti, ruoli e offboarding completa la prospettiva. È possibile richiedere un inventario degli accessi amministrativi.
Domande frequenti
Posso condividere una chiave pubblica?
La parte pubblica è destinata a una distribuzione appropriata. Va comunque verificata l’associazione alla persona e alla destinazione corrette. La parte privata resta protetta e non circola come file di accesso condiviso.
Un certificato di breve durata basta per una revoca immediata?
No. Emissione, validità residua, verifica della revoca e sessioni già attive vanno considerate insieme. Una durata breve non sostituisce questo processo.
Serve sempre un’autorità di certificazione centrale?
No. Dimensioni, frequenza dei cambiamenti, automazione e capacità operative determinano la soluzione adatta. Una gestione accurata delle chiavi può essere adeguata a un insieme di sistemi contenuto.
Fonti: OpenSSH: autenticazione e chiavi autorizzate (link esterno) · OpenSSH: certificati e liste di revoca (link esterno) · OpenSSH: regole di fiducia e revoca lato server (link esterno) · OpenSSH: inoltro dell’agent (link esterno) · OpenSSH: chiavi dell’agent e restrizioni (link esterno) · Proxmox VE: manuale di amministrazione, SSH nel cluster (link esterno)
Inquadramento concettuale; le funzioni concrete dipendono dalle versioni installate e dalla gestione prevista.
