Il miglior sistema per la gestione delle chiavi ssh? [chiuso]


42

Ho diversi computer client (ad esempio laptop, desktop, ecc.), Mi collego a diversi server che gestisco e accedo a tutti tramite SSH. Posso immaginare diversi schemi di gestione dei tasti ssh che avrebbero senso, e sono curioso di sapere cosa fanno gli altri.

Opzione 1: una coppia di chiavi pubblica / privata globale.

Genererei una coppia di chiavi pubblica / privata e metterei la chiave privata su ogni macchina client e la chiave pubblica su ogni macchina server.

Opzione 2: una coppia di chiavi per macchina server.

Genererei una coppia di chiavi su ogni macchina server e metterei ciascuna chiave privata sulle macchine client.

Opzione 3: una coppia di chiavi per macchina client.

Ogni macchina client avrebbe una chiave privata univoca e ogni macchina server avrebbe le chiavi pubbliche per ogni macchina client da cui mi piacerebbe connettermi.

Opzione 4: una coppia di chiavi per coppia client / server

Totalmente fuori bordo?

Quale di questi è il migliore? Ci sono altre opzioni? Quali criteri utilizzi per valutare la giusta configurazione?

Risposte:


33

Uso l' opzione 3: una coppia di chiavi per macchina client e per me ha più senso. Ecco alcuni dei motivi:

  • Se un client è compromesso, quella chiave (e solo quella chiave) deve essere rimossa dai server.
  • È abbastanza flessibile per decidere a cosa posso accedere da dove, senza concedere l'accesso completo a tutti i server da tutti i client.
  • Molto conveniente. C'è solo 1 chiave per ssh-add, nessuna confusione.
  • Facile da configurare e amministrare tramite l' opzione 4

L'opzione 4 è carina, ma è troppo lavoro. L'opzione 3 ti porta al 98% lì con molta meno seccatura.


4
Non riesco a vedere il punto dell'opzione 4. Non serve a nulla.
niXar,

26

Uso una soluzione un po 'più complicata ma molto versatile in quanto desidero mantenere una certa separazione nelle chiavi di identità SSH utilizzate per i miei server di rete domestica, i server di ufficio, i server di rete dei client di consulenza e altri vari sistemi su cui ho account.

Detto ciò, lavoro quasi esclusivamente da workstation Linux, quindi ho una chiave USB che viene configurata utilizzando la crittografia LUKS e il mio gestore di finestre X11 insieme al demone HAL rileva l'unità crittografata LUKS e richiede la passphrase di decrittazione quando viene inserita e tentata di essere montato. Memorizzandolo su un'unità crittografata come faccio, non memorizzo mai le chiavi SSH su nessuna workstation.

Ho quindi la seguente configurazione nel mio ~/.ssh/configfile:

Host *
    Protocol 2
    IdentityFile %d/.ssh/keys.d/id_rsa.%l
    IdentityFile %d/.ssh/keys.d/id_dsa.%l
    IdentityFile %d/.ssh/keys.d/%u@%l

L' % d è tradotto per essere a casa directory dell'utente da OpenSSH e in ~ / .ssh directory ho creato keys.d come un link simbolico al percorso di directory sul drive USB cifrato quando è montato correttamente.

L' espressione % l viene tradotta in nome host delle macchine client locali e % u verrà tradotto nel nome utente del client locale.

Ciò che fa questa configurazione è consentire a SSH di cercare una chiave usando 3 espressioni diverse. Ad esempio, se il nome utente del jdoemio client locale fosse e il nome del mio computer client locale examplehostsarebbe visualizzato nel seguente ordine fino a quando non trovasse una chiave che esisteva e veniva accettata dal server remoto.

/home/jdoe/.ssh/keys.d/id_rsa.examplehost
/home/jdoe/.ssh/keys.d/id_dsa.examplehost
/home/jdoe/.ssh/keys.d/jdoe@examplehost

Puoi anche usare l' espressione % r per cercare una chiave specifica per il nome utente del server remoto o % h per il nome host del server remoto proprio come sono stati usati % u e % l .

Aggiornamento: ora utilizzo effettivamente GnuPG gpg-agent con compatibilità ssh-agent per leggere e utilizzare la chiave di autenticazione dalla mia smart card OpenPGP v2.


Caspita, ottima soluzione, grazie! Adoro la configurazione universale in ~ / .ssh / config
slacy,

Si è dimostrato abbastanza conveniente mantenere le cose separate per i server di rete client di lavoro, personali e di consulenza ... Non voglio mescolare l'autenticazione tra di loro, ma voglio anche che sia facile per me.
Jeremy Bouse,

Stupefacente! Adoro davvero questo.
Balu,

Presumo che tu stia utilizzando chiavi USB diverse per macchine client diverse. In caso contrario, qual è il punto in chiavi separate se tutti sono memorizzati nello stesso posto? In caso di violazione, è necessario revocarli tutti. A meno che (e probabilmente) mi manchi qualcosa, questo sembra complicare le cose.
Halil Özgür,

@ HalilÖzgür, Sì, faccio consulenza e non voglio sempre usare la stessa chiave. Poiché la chiave USB è crittografata e non connessa a nessun computer a meno che non sia necessario per effettuare una connessione, non vi è alcuna preoccupazione per la violazione del server e la passphrase per decrittografare il file system dell'unità è sufficientemente lunga da rendere abbastanza semplice la revoca delle chiavi.
Jeremy Bouse,

6

Eliminerei entrambe le opzioni 1 (di cui sospetto che si supponesse che si trattasse dell'opzione 2 ;-) perché le chiavi private sono dati sensibili e ha senso conservarle nel minor numero possibile. Personalmente non avrei mai copiato una chiave privata da un computer a un altro (o anche da un file all'altro sullo stesso computer), tranne forse per fare backup. Sebbene diversamente dalla maggior parte delle chiavi di crittografia, se una chiave SSH si perde non è la fine del mondo (basta crearne una nuova, non si perdono dati).


Sì, rinominato in una corretta "Opzione 2" Mi piace la regola di "non copiare mai una chiave privata". Questa è una buona regola.
slacy,


1

Opzione 3

Ciò consente anche di controllare a quali server può accedere un client. ad es. se il client X necessita dell'accesso ai server A e B, ma C o D, la chiave pubblica viene copiata solo su tali host.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.