Nella mia azienda utilizziamo LDAP per avere un set coerente di account su tutte le macchine e quindi utilizzare uno strumento di gestione della configurazione (nel nostro caso attualmente cfengine) per distribuire i authorized_keysfile per ciascun utente su tutti i server. I file delle chiavi stessi sono conservati (insieme ad altre informazioni sulla configurazione del sistema) in un repository git in modo da poter vedere quando le chiavi vanno e vengono. cfengine distribuisce anche un sudoersfile che controlla chi ha accesso per eseguire cosa come root su ciascun host, usando utenti e gruppi dalla directory LDAP.
L'autenticazione della password è completamente disabilitata sui nostri server di produzione, pertanto l'autenticazione della chiave SSH è obbligatoria. La politica incoraggia l'uso di una chiave separata per ciascun laptop / desktop / qualunque cosa e l'utilizzo di una passphrase su tutti i tasti per ridurre l'impatto di un laptop smarrito / rubato.
Abbiamo anche un host bastion che viene utilizzato per accedere agli host sulla rete di produzione, permettendoci di avere regole firewall molto restrittive su quella rete. La maggior parte degli ingegneri ha alcune speciali configurazioni SSH per rendere questo trasparente:
Host prod-*.example.com
User jsmith
ForwardAgent yes
ProxyCommand ssh -q bastion.example.com "nc %h %p"
L'aggiunta di una nuova chiave o la rimozione di una vecchia richiede un po 'di cerimonia in questa configurazione. Direi che per l'aggiunta di una nuova chiave è auspicabile che sia un'operazione che lasci una traccia di controllo ed è visibile a tutti. Tuttavia, a causa delle spese generali, penso che le persone a volte trascurano di rimuovere una vecchia chiave quando non è più necessaria e non abbiamo alcun modo reale di rintracciarla se non per ripulire quando un dipendente lascia l'azienda. Inoltre, crea un ulteriore attrito quando si trova a bordo di un nuovo ingegnere, poiché devono generare una nuova chiave e inviarla a tutti gli host prima che possano essere completamente produttivi.
Tuttavia, il vantaggio più grande è avere un nome utente separato per ciascun utente, che semplifica il controllo degli accessi più granulare quando ne abbiamo bisogno e fornisce a ciascun utente un'identità che appare nei registri di controllo, che può essere davvero utile quando si cerca di tracciare un problema di produzione torna a un'azione di amministratore di sistema.
In questa configurazione è fastidioso avere sistemi automatizzati che agiscono contro host di produzione, poiché le loro chiavi SSH "ben note" possono servire come percorso di accesso alternativo. Finora abbiamo appena creato che gli account utente per questi sistemi automatizzati abbiano solo il minimo accesso di cui hanno bisogno per fare il loro lavoro e abbiamo accettato che un utente malintenzionato (che deve già essere un ingegnere con accesso alla produzione) possa anche fare quelle stesse azioni semi- usando anonimamente la chiave dell'applicazione.