Sistema di gestione centralizzata per chiavi SSH?

27

Stiamo cercando di passare alla gestione basata su chiavi degli accessi SSH e ci chiediamo se esistano sistemi di gestione delle chiavi che ci consentirebbero di gestire centralmente le chiavi di accesso in tutto il mondo.

Il sistema dovrebbe idealmente consentire il rilascio della chiave per client e, se necessario, la revoca, aggiornando al volo le chiavi della macchina server.

Qualcuno sa di un tale sistema, sia commerciale che open source?

NOTA: per chiarire, abbiamo bisogno della gestione delle chiavi per un numero piuttosto elevato di server cloud (simili a EC2) e una piccola quantità di utenti del servizio. Immagino che la patch LDAP + suggerisca di seguito potrebbe essere la strada da percorrere.

ssh cloud keys

— SyRenity
fonte

7

Sono solo io a pensare che "chiavi private e cloud" siano come "bere e guidare". Entrambi si divertono separatamente ma non vanno mai insieme.

— mailq,

1

"Cloud" è probabilmente la parola sbagliata: sembra che ciò che vogliono sia un'autenticazione centralizzata, con coerenza mondiale.

— voretaq7,

Ciao. Esatto - quello che stiamo cercando.

— SyRenity,

Ho avuto problemi con questo problema con alcuni dei miei clienti ambienti ibridi. C'è anche la domanda su dove conservare OPenLDAP o istanza centrale in una distribuzione cloud? Ho usato il webmin di tutte le cose come uno strumento di gestione delle chiavi e un libro di cucina per lo chef per sincronizzare le chiavi con i nodi.

— Tom H

Userify copre ciò che stai cercando (vedi serverfault.com/questions/647797/… )

— Jamieson Becker,

8

Ci sono molti modi per farlo. L'archiviazione delle chiavi LDAP è stata menzionata un paio di volte e l'ho fatto e funziona, per quanto possibile. LDAP ha le sue curiosità gestionali, tuttavia, che richiedono un po 'di apprendimento.

Sono un grande fan di server semplici e robusti con dipendenze di rete esterne minime per cose semplici come l'autenticazione degli amministratori, quindi mi rivolgo a una strategia di distribuzione delle chiavi SSH molto più solida: ho il sistema di gestione della configurazione che se ne occupa. La chiave pubblica di tutti viene conservata nel sistema di gestione della configurazione e ogni volta che la persona deve poter accedere, viene aggiunta la chiave. Il sistema di configurazione sa anche di rimuovere le chiavi che non sono state specificate, quindi quando qualcuno lascia o cambia la propria chiave, si tratta semplicemente di rimuovere la configurazione della chiave e alla successiva esecuzione del sistema di configurazione, la chiave viene rimossa.

— womble
fonte

Questo approccio è sicuramente valido e, come sottolinea Womble, ha un vantaggio in quanto i server restano attivi e funzionanti (e accessibili) nel caso in cui LDAP non funzioni - Ogni sistema supportato da LDAP dovrebbe (oserei dire che deve ) avere almeno un utente le cui chiavi vengono espulse come descritto da Womble. Il rovescio della medaglia è che devi eseguire una configurazione per autorizzare gli utenti. Non è un problema per un "account di emergenza" con solo pochi utenti autorizzati. Problema maggiore per un gran numero di account :)

— voretaq7

1

Devi davvero avere un modo per innescare le esecuzioni di configurazione di massa, quindi non dovrebbe essere un grosso problema farlo per un cambio di account.

— Womble

Sono d'accordo, purtroppo le esigenze / mentalità di business no: la paranoia in molti luoghi (la mia inclusa) impone che le spinte di configurazione avvengano fuori orario, ma il nuovo personale / il personale in uscita può avvenire in qualsiasi momento: - /

— voretaq7

1

Quindi sei felice di lasciare le cose rotte per un giorno lavorativo solo perché non puoi eseguire una configurazione durante il giorno? Solo perché è comune, non significa che non sia stupido.

— Womble

2

Ciao. Quindi una buona idea sarebbe usare Puppet per questo, per esempio?

— SyRenity,

23

Le coppie di chiavi dovrebbero essere generate dall'utente.

L'utente mantiene la metà privata: non dovresti mai vederla. Se hai la chiave privata di qualcuno in un modulo in cui puoi leggerla / utilizzarla, stai sbagliando la sicurezza.

La metà pubblica ti viene data (tramite qualsiasi meccanismo tu voglia: modulo Web, e-mail, regalami su un CD), da centralizzare come vuoi. Alcuni luoghi memorizzano le chiavi pubbliche in LDAP. Altri espellono i authorized_keysfile usando il loro sistema di distribuzione.

Nel mio ambiente gli utenti che hanno bisogno dell'accesso alla shell mi danno le loro chiavi pubbliche. Queste chiavi vengono aggiunte al nostro sistema LDAP e sshdconsulta le chiavi pubbliche elencate per ciascun utente per autenticarle, tramite la patch di chiave pubblica LDAP .
Quando qualcuno deve aggiungere una chiave aggiuntiva o revocare una chiave esistente, lo fa sapere a un amministratore e noi ce ne occupiamo noi. Alla fine scalando implementerò un sistema che consente alle persone di ruotare le proprie chiavi pubbliche.

Ognuno dei nostri siti ha una coppia di server LDAP, sincronizzati con il nostro master con replica LDAP, che mantiene i dati coerenti (e accessibili) in ogni posizione.

Tutto ciò che ho descritto può essere fatto con un software open source. Ci sono anche prodotti commerciali che fanno la stessa cosa.
È necessario ricercare più a fondo le opzioni disponibili e decidere quale (e) si adatta meglio al proprio ambiente. Se hai ulteriori domande (più specifiche), possiamo probabilmente essere più utili.

— voretaq7
fonte

Quindi, in sostanza, suggerisci di utilizzare l'infrastruttura LDAP, con OpenSSH con patch che funzionerà con LDAP? Quanto bene questo scala nella produzione? Può supportare una grande quantità di macchine? Dobbiamo supportare solo una piccola quantità di utenti del servizio.

— SyRenity,

1

@SyRenity: LDAP supporta la replica e il clustering in modo che si ridimensioni molto bene

— Hubert Kario,

@SyRenity Teoricamente puoi supportare un numero illimitato di macchine in un numero illimitato di posizioni (pensa a "Implementazione di Active Directory davvero grande" - AD è sostanzialmente LDAP con alcuni accessori alla moda). Per gli utenti del servizio, il mio suggerimento è di standardizzarli nel proprio ambiente e distribuire file /etc/passwde /etc/groupfile standardizzati (consente alle macchine di funzionare normalmente e di avviare / eseguire i servizi associati anche se LDAP non è disponibile)

— voretaq7,

@ voretaq7 Vuoi dire che gli utenti del servizio saranno gestiti separatamente da LDAP, tramite la gestione della configurazione?

— SyRenity,

@SyRenity sì - e soprattutto disponibile per i servizi che li utilizzano se LDAP non è attivo . Pianificare guasti o si verificheranno disastri.

— voretaq7,

9

Le chiavi di tastiera non dovrebbero essere generate ovunque ma sul computer di ciascun utente. Le chiavi private sono nominate come tali per un motivo.

Detto questo, ho potuto vedere un caso d'uso per una sorta di repository centralizzato di chiavi pubbliche degli utenti. Un'opzione sarebbe quella di archiviare le chiavi pubbliche in OpenLDAP: le versioni recenti di OpenSSH possono leggere le chiavi da LDAP.

— EEAA
fonte

2

La roba della chiave pubblica LDAP nella mainline OpenSSH ora? Conosco solo la patch LPK (che posso garantire - funziona benissimo). Inoltre +1 per mantenere private le chiavi private.

— voretaq7,

@ voretaq7 Immagino di aver sentito che si stava unendo alla linea principale, ma non l'ho ancora verificato. Realizziamo home directory condivise tramite NFS, in modo che si occupi della nostra distribuzione chiave per noi.

— EEAA,

+1 bene non lo sapevo. questo mi risparmierebbe un sacco di problemi. questo è ora nella mia lista di cose da esaminare.

— Tom H

1

So che questa è una domanda leggermente più vecchia, ma Google la restituisce abbastanza in alto quando si cerca questo tipo di cose.

Per quelli di noi che cercano una soluzione oltre a LDAP, ho appena trovato il progetto "SKM": https://sites.google.com/site/jeromeboismartel/code-s-corner/ssh-key-management-with-skimp

— fukawi2
fonte

1

Ci sono molte grandi soluzioni commerciali e open source, come Userify [1] (dove lavoro), Universal Key Manager [2], SSH Key Box [3], ecc. Dipende da quali sono le tue esigenze e se lo sei alla ricerca di qualcosa che centralizzi la gestione durante il decentramento delle operazioni (in modo che i server non si affidino a un'autorità centrale per accedere ... in tal caso, potresti non essere in grado di accedere a nessuno dei tuoi server, se, per esempio, il tuo Il server LDAP non è attivo!)

Vedi anche questa discussione inclinata:

https://www.slant.co/topics/8010/~managers-for-ssh-keys

— Jamieson Becker
fonte