Consigli per la gestione delle chiavi SSH

Qual è la migliore pratica che hai trovato per gestire molte coppie di chiavi SSH?

Uso SSH per connettermi a diversi sistemi, sia a casa che al lavoro. Al momento ho una raccolta abbastanza piccola e gestibile di coppie di chiavi sia per i sistemi di lavoro che domestici. Ho una sceneggiatura che genera una coppia di chiavi con nome in modo da evitare confusione.

La mia rete domestica è composta dal mio laptop (ubuntu), due desktop (doppio avvio ubuntu / fedora, doppio avvio fedora / windows) e un sistema multimediale (ubuntu). Al lavoro ho il mio laptop personale (che uso per lavorare da casa), il mio desktop (fedora), un sistema di produzione (RHEL) e un laptop con windows (sospiro) e una VM (fedora). Tutto bene finora.

(Non ho interesse né a mettere la mia coppia di chiavi domestica sul mio sistema di lavoro, né la mia coppia di lavoro di lavoro sui miei sistemi domestici. E abbiamo account utente virtuali per meccanizzare i trasferimenti di file con altri sistemi, in cui la chiave privata deve risiedere sulla macchina di produzione, per trasferire file tra altri sistemi.)

Ma ora arriva Hadoop, un grande cluster di oltre 100 sistemi e con maggiore complessità, più utenti e più coppie di chiavi. Ora devo gestire le chiavi.

(Devo chiarire. Sono uno sviluppatore di software che si rivolge a un cliente che sta distribuendo un cluster Hadoop. Devono gestire le chiavi. Ci saranno molte persone che accedono al cluster, che devono posizionare le loro chiavi pubbliche sul sistema. Come residenti Esperto di Linux, mi hanno chiesto aiuto. Ho consigliato di assumere un amministratore di sistema, ma fino a quando non lo fanno, sto aiutando)

Quando devo pubblicare la chiave pubblica su un sistema remoto, tutte le pagine web "how-to" suggeriscono di sovrascrivere (>) (distruggere le chiavi esistenti) o di aggiungere (>>) (che è buono, conserva le chiavi esistenti) . Ma penso che conservare ciascuna chiave pubblica sulla macchina di destinazione separatamente e combinarle sarebbe meglio. Sto cercando un consiglio.

Qual è la migliore pratica che hai trovato per gestire molte chiavi?

Grazie!

Modifica: un aspetto è la necessità di posizionare le chiavi su molti sistemi e il concomitante CRUD (creare, leggere, aggiornare, eliminare / disabilitare) per utenti specifici, il che significa che è necessario essere in grado di identificare quali chiavi appartengono a quali utenti.

Generalmente non si dovrebbe avere più di 1 chiave per macchina client (enfasi su "generalmente"). Non sono sicuro di capire correttamente la tua domanda, ma se stai dicendo che hai una chiave separata per ogni sistema remoto, allora sicuramente stai sbagliando.

Ssh utilizza la crittografia a chiave pubblica. La chiave che installi sul sistema remoto è la chiave pubblica, non c'è assolutamente nulla di male nel riutilizzare questa chiave altrove. È la chiave privata che deve essere protetta e rimane sul tuo sistema personale.

È inoltre consigliabile che la chiave privata risieda su un solo client, non condiviso. Questo è così che se un client è compromesso, puoi revocare solo quella chiave.

Ora, se stai chiedendo come ottenere la tua chiave pubblica su centinaia di sistemi, ci sono un paio di modi per farlo.

Il modo più comune è utilizzare le home directory condivise. Avere un NFS (o un altro filesystem di rete) montato (o montato automaticamente) su tutti i sistemi.

L'altro modo è sfruttare una nuova funzionalità in ssh. È una direttiva di configurazione chiamata AuthorizedKeysCommand. Fondamentalmente è un comando che sshd verrà eseguito ogni volta che è necessario cercare una chiave pubblica. Il comando scrive semplicemente la chiave pubblica dell'utente da interrogare su STDOUT. Questo è usato principalmente quando non hai montato home directory, ma hai ancora un server di autenticazione centrale ( FreeIPA ne approfitta).

Ovviamente puoi fare altre cose come cron job rsync su /homeda un server centrale. Ma questa non è una pratica comune.

Quando devo pubblicare la chiave pubblica su un sistema remoto, tutte le pagine web "how-to" suggeriscono di sovrascrivere (>) (distruggere le chiavi esistenti) o di aggiungere (>>) (che è buono, conserva le chiavi esistenti) . Ma penso che conservare ciascuna chiave pubblica sulla macchina di destinazione separatamente e combinarle sarebbe meglio. Sto cercando un consiglio

non vedo alcun vantaggio nella memorizzazione delle chiavi pubbliche sia in .ssh/authorized_keysche in un file separato.

se dai un'occhiata alle chiavi effettive memorizzate nel file * authorized_keys * vedi che contengono già meta-informazioni leggibili dall'uomo sull'origine della chiave. ad es. la chiave pubblica di user@foosolito ha una voce come:

ssh-rsa AAAAB3Nza...LiPk== user@example.net

facilitando così l'ispezione / estrazione / eliminazione di alcune chiavi (associate a determinati utenti) dal file * authorized_keys *.

l'id utente è in realtà un campo "commento" in formato libero, quindi puoi inserire qualsiasi informazione che ritieni necessaria per identificare la chiave fornita.

in ogni caso, è necessario generare solo coppie di chiavi per "utenti" che devono accedere a risorse remote. è probabile che non sia necessario accedere da ciascun host hadoop all'altro host hadoop. piuttosto avrai alcune macchine di gestione, che devono accedere a tutti gli host hadoop. hai solo bisogno di una singola coppia di chiavi per ogni macchina di gestione e installa ogni chiave pubblica su tutti gli host hadoop.

OpenSSH recente consente di ottenere chiavi ssh da LDAP, vedere 'AuthorizedKeysCommand' nella pagina man sshd_config . Personalmente preferirei i certificati OpenSSH, non le chiavi, vedere http://blog.habets.pp.se/2011/07/OpenSSH-certificates . Puoi gestire le chiavi con qualsiasi gestore della configurazione come cfengine, burattino, chef, sale ...

Un altro modo che è super facile da implementare e consente un po 'più di flessibilità in termini di aggiunta di più utenti è l'uso. https://userify.com/

Consente di definire diversi gruppi di server e di avere le chiavi per diversi utenti abilitate o disabilitate per tali server.

Installazione e gestione semplicissime.