Un sistema per la distribuzione di chiavi pubbliche SSH

26

Abbiamo molti sistemi diversi che sono gestiti da più persone. Abbiamo scelto di utilizzare l'autenticazione con chiave pubblica SSH per accedere a tali sistemi. Funziona alla grande, poiché non è necessario gestire o condividere le password degli account amministrativi, non è necessario ricordare le password dei vari sistemi (solo la passphrase della chiave privata), non è necessario interagire (inserire la password) con ogni comando remoto .

Il problema è che le chiavi pubbliche installate sui sistemi devono essere gestite in qualche modo. Le persone vanno e vengono, le chiavi possono essere compromesse, le responsabilità cambiano (una persona autorizzata a entrare in un sistema oggi può essere autorizzata ad accedere a un altro domani). Attualmente lo gestiamo modificando manualmente i file ~ / .ssh / authorized_keys su ogni account che ne ha bisogno, ma è molto lavoro e soggetto a errori.

Esiste uno strumento pronto per gestire le chiavi pubbliche in tale scenario? Hai le tue soluzioni? O l'intera idea di gestire i sistemi in questo modo è imperfetta?

ssh ssh-keys public-key

— Jacek Konieczny
fonte

Non riesco davvero a rispondere alla tua domanda, ma quando l'ho letto ho potuto sentirlo urlare per un qualche tipo di sistema di database.

— John Gardeniers,

In effetti, posso vedere un posto per un database sul "backend" (il "key server"), anche se preferirei limitare l'accesso al database lì e avere le chiavi distribuite sul canale SSH. Non aprire altri canali di comunicazione sui sistemi gestiti. In effetti, mi sento in grado di implementare tale strumento / sistema, anche se preferirei qualcosa di pronto e dimostrato efficace.

— Jacek Konieczny,

18

Come già accennato da pulegium, qualsiasi software di gestione della configurazione generico come Puppet , Chef , Bcfg2 o cfengine potrebbe svolgere il compito.

Poiché il file authorized_keys non è così complicato, puoi anche usare rsync o un (D) SCM come git o hg per gestire questo file. Hai il file "master" su uno dei tuoi server e lo servi tramite rsync / git / hg /…. Su ogni altro server si esegue un processo cron che recupera periodicamente la copia principale (se è stata modificata) e la copia nella posizione locale corretta. Cavolo, funzionerebbe anche con HTTP o FTP puro.

La linea di fondo è: avere una copia "master" del file authorized_keys e aggiornarlo. Consenti ai "client" (i computer, che dovrebbero avere il file authorized_keys corrente) di recuperarli dal server principale e distribuirli localmente.

— Joschi
fonte

1

Usiamo comodamente le marionette per gestire ~ 200 server Linux (le chiavi pub sono solo un file da applicare come attributo di un utente).

— ForgeMan,

1

Accetterò questa risposta, sembra che non migliorerò. Sembra che le scelte per me siano: 1. Mantenere le cose come sono ora 2. Costruire la propria catena di strumenti per gestire i file authorized_keys 3. Utilizzare alcuni strumenti generici esistenti per la gestione dei server, come Puppet o Chef ... anche se quegli strumenti sembrano troppo grandi per questo semplice compito. 4. Usa altri meccanismi di autenticazione / autorizzazione (come Kerberos) ... anche se questo sembra anche uno strumento troppo sofisticato per un semplice compito Grazie.

— Jacek Konieczny il

questo sistema è sicuro come il canale attraverso il quale viene tirata la copia principale.

— anno

1

Ansible è un sistema CM molto leggero che ha un modulo da confondere con file di chiavi autorizzati su ssh. Vedi ansible.cc/docs/modules.html#authorized-key

— RS

11

Esiste una patch disponibile per OpenSSH che consente di utilizzare le chiavi pubbliche da un server LDAP, ma ciò ha davvero senso solo se i controlli di autenticazione / account vengono eseguiti anche su quel server LDAP (che è il modo in cui il mio ambiente è impostato). Inoltre è sicuro solo quanto la tua configurazione LDAP (quindi vuoi usare SSL e verificare le chiavi).

Vedi http://code.google.com/p/openssh-lpk/ per la patch e ulteriori dettagli. Non conosco alcun sistema operativo fornito con questa patch per impostazione predefinita, ma se stai eseguendo FreeBSD è una patch opzionale se usi OpenSSH dalle porte.

— voretaq7
fonte

1

L'uso accidentale di pam_ldap ti consente anche di risolvere il problema "qualcuno autorizzato ad accedere alla macchina A oggi potrebbe non essere autorizzato ad accedervi domani" - leggi su pam_ldap se sei interessato a quell'aspetto ...

— voretaq7,

5

corro una soluzione molto semplice, che fa lo stesso con le regole del firewall

file di esempio hosts.conf:

192.168.0.1
192.168.2.99
192.168.2.100

distribute.sh:

#!/bin/bash
for d in `cat ./hosts.conf`; do
  echo "copying to $d ...";
  scp /root/.ssh./authorized_keys root@$d:/root/.ssh./authorized_keys
done;

questa è tutta la magia :-)

— bmaeser
fonte

5

Attualmente sto controllando SSD KeyDB . Ha lo scopo di fare esattamente questo, amministrare ruoli, server e utenti, distribuire chiavi utente, raccogliere chiavi host ecc. Ha persino qualcosa chiamato "percorsi".

Non ho ancora capito tutto e non sono sicuro che funzioni completamente. Il codice è comunque in Python e sembra essere abbastanza gestibile, quindi non dovrebbe essere troppo difficile rispolverarlo e farlo funzionare.

— andsens
fonte

1

Non sono sicuro di cosa intendi per molti, né so se sei disposto a cambiare, ma Kerberos è il droide che stai cercando. Ciò risolverà i tuoi problemi in modo elegante e autenticherà persone e macchine.

— pboin
fonte

1

Hai due (che generalmente si trasformano in 3) diversi problemi che stai cercando di risolvere:

Autenticazione (chi sei?)
Autorizzazione (sei autorizzato ad accedere a questo server?)
Audit (cosa hai fatto?)

L'autorizzazione a chiave pubblica è un modo corretto per eseguire l'autenticazione a volte, ma non indirizza affatto l'autorizzazione. Non mi piace l'autorizzazione a chiave pubblica, in quanto è molto facile scendere a compromessi (soprattutto internamente) a meno che non si disponga di buoni controlli.

È qui che entrano in gioco soluzioni come Kerberos. Nel mondo Windows, Active Directory risolve questo problema. Nel mondo Unix, ci sono molte scelte, che è sia una cosa positiva che una cattiva.

Mi piacerebbe verificare la Red Hat FreeIPA progetto, che è un insieme di software che rende facile ottenere un sistema AD-come Kerberos / LDAP / DNS rapidamente operativi.

— duffbeer703
fonte

Comprendo la differenza tra autenticazione, autorizzazione e audit. E le "chiavi autorizzate" di SSH forniscono dati di autenticazione e autorizzazione. È lungi dall'essere perfetto, ma è semplice. E la semplicità è spesso un grande vantaggio, anche in termini di sicurezza. Kerberos, con la sua complicata infrastruttura, potrebbe non riuscire a garantire la sicurezza in molti modi diversi da ssh con i suoi file authorized_keys. Tuttavia, ciò non significa che l'uno o l'altro sia più sicuro.

— Jacek Konieczny,

La gestione dei file authorized_keys è np per una manciata di server, ma si raggiunge rapidamente un punto in cui è impossibile da gestire. Non stavo cercando di dire che è una soluzione "cattiva". Allo stesso modo, le complessità in Kerberos sono inadeguate per due server ... ma vale la pena investire in progettazione / implementazione di Kerberos in un ambiente più ampio.

— duffbeer703,

1

È possibile utilizzare Bcfg2 con bcfg2-account per distribuire authorized_keys. Come bonus aggiuntivo, avrai la possibilità di controllare utenti e gruppi.

Bcfg2 consente anche una manutenzione indolore/etc/ssh/ssh_known_hosts con SSHbase .

— Myroslav
fonte

1

C'è anche SKM

— andsens
fonte