it-swarm.dev

Best practice: "chiave ssh separata per host e utente" vs. "una chiave ssh per tutti gli host"

È meglio creare una chiave SSH separata per ciascun host e utente o semplicemente usando id_rsa chiave per l'autenticazione di tutti gli host? Potrebbe uno id_rsa essere una negligenza per le politiche sulla privacy/anonimato?

Aggiornare:

avere un tasto ssh per tutti gli host:

~/.ssh/id_rsa
~/.ssh/id_rsa.pub

rispetto ai tasti ssh separati:

~/.ssh/user1_Host1
~/.ssh/user1_Host1.pub
~/.ssh/user2_Host1
~/.ssh/user2_Host1.pub
~/.ssh/user3_Host2
~/.ssh/user3_Host2.pub
~/.ssh/user4_Host3
~/.ssh/user4_Host3.pub
... etc.
155
static

Una chiave privata corrisponde a una singola "identità" per un determinato utente, qualunque cosa significhi per te. Se, per te, una "identità" è una singola persona, o una singola persona su una singola macchina, o forse una singola istanza di un'applicazione in esecuzione su una singola macchina. Il livello di granularità dipende da te.

Per quanto riguarda la sicurezza, non comprometti la tua chiave in alcun modo utilizzandola per accedere a un computer (come faresti con una password), quindi avere chiavi separate per destinazioni separate non ti rende più sicuro dal punto di vista dell'autenticazione/sicurezza.

Sebbene avere la stessa chiave autorizzata per più macchine provi che lo stesso portachiavi ha accesso a entrambe le macchine da una prospettiva forense. In genere non è un problema, ma vale la pena sottolineare.

Inoltre, più posizioni viene autorizzata una singola chiave, più preziosa diventa quella chiave. Se tale chiave viene compromessa, vengono messi a rischio più obiettivi.

Inoltre, più posizioni viene memorizzata la chiave privata (ad esempio il computer di lavoro, il laptop e l'archivio di backup), più posizioni ci sono per un attaccante per andare a prendere una copia. Quindi vale la pena considerare anche.

Per quanto riguarda le linee guida universalmente applicabili su come eseguire la sicurezza: non ce ne sono. Maggiore è la sicurezza aggiuntiva che aggiungi, maggiore è la comodità che rinunci. L'unico consiglio che posso fornisco categoricamente è questo: mantieni la tua chiave privata crittografata. La sicurezza aggiunta è piuttosto significativa.

171
tylerl

Penso che questa domanda possa essere considerata da due diverse angolazioni: sicurezza e convenienza.

Quando creiamo una coppia di chiavi SSH, ci viene chiesto di fornire una passphrase per aggiungere un ulteriore livello per proteggere la chiave privata, come segue:

$ ssh-keygen -t rsa -b 4096 -C 'With_OR_Without_Passwd'
Generating public/private rsa key pair.
Enter file in which to save the key (/Your/HomeDir/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):

Sebbene esista un Prompt esplicito che richiede la passphrase, ma alcune (o molte) persone continuano a concentrarsi maggiormente sulle informazioni tra parentesi: (vuoto per nessuna passphrase) e seguendo tale suggerimento.

Combinazione di indipendentemente dall'utilizzo di più coppie di chiavi SSH e indipendentemente dal fatto che non inserire passwd aggiuntivo , abbiamo almeno quattro modi di procedere. Supponiamo che tutte le coppie di chiavi e il file config siano memorizzati in ~/.ssh/.

Ora non considerare prima sicurezza.

La tabella seguente fornisce un semplice rango di sicurezza (un numero maggiore significa più sicuro):

Security     Ways to go
   1         One   SSH key-pair  (NO passwd)
   1         Multi SSH key-pairs (NO passwd)
   2         One   SSH key-pair  (WITH passwd)
   2         Multi SSH key-pairs (WITH passwd) (SAME passwd)
   3         Multi SSH key-pairs (WITH passwd) (DIFF passwds)

Senza passwd , se il nostro sistema è intruso da qualcuno, allora l'interruttore può ottenere tutte le nostre chiavi private e la nostra configurazione, anche l'autenticazione dei server remoti. Quindi, in questa situazione, una coppia di chiavi e più coppie di chiavi sono uguali. Il modo più sicuro è usare passwd diversi per coppie di chiavi ssh diverse.

Quindi non pensare a convenienza.

Ma più coppie di chiavi e più passwd rendono anche la nostra vita meno comoda, la tabella seguente offre un semplice rango di sicurezza (un numero maggiore significa più sicuro):

Convenient  Security  Ways to go
   5           1      One   SSH key-pair  (NO passwd)
   4           2      One   SSH key-pair  (WITH passwd)
   3           1      Multi SSH key-pairs (NO passwd)
   2           2      Multi SSH key-pairs (WITH passwd) (SAME passwd)
   1           3      Multi SSH key-pairs (WITH passwd) (DIFF passwds)

Quindi, in generale, se dobbiamo scambiare con sicurezza e convenienza allo stesso tempo, possiamo moltiplicare i due punteggi e forse Una coppia di chiavi SSH (WITH passwd) è quella giusta da scegliere.

20
YaOzI

Hai solo bisogno di una chiave poiché la chiave appartiene al tuo utente.

Non è necessario (e nessun miglioramento nella sicurezza) avere una chiave per Host.

Finché la chiave privata è mantenuta privata, puoi utilizzare questa chiave singola e utilizzarla per autenticarti su più host.

4
Uwe Plonus

Qual è la migliore pratica: chiave ssh separata per host e utente VS una chiave ssh per tutti gli host?

Non so se ho capito bene la tua domanda, cosa intendi con "chiave"? ti riferisci alla cripto asimmetrica?

quando usi la crittografia asimmetrica hai una coppia di chiavi privata e pubblica. La chiave pubblica di ciascun utente è memorizzata sul server ssh (Host). Ciò consente di autenticare l'utente perché per ogni chiave pubblica dovrebbe esserci solo una chiave privata.

enter image description here

cosa intendi con un tasto ssh per tutti gli host?

2
enigma

Il vantaggio principale di chiavi separate è ciò che accade nello scenario peggiore: qualcuno ottiene la tua chiave privata.

  1. Tasto SAME su tutti gli host: i cattivi ora hanno accesso a tutto.
  2. Chiave DIVERSA su ciascun Host: i cattivi hanno accesso solo a una cosa.

Quindi, il più sicuro? Chiavi univoche per ciascun host.

2
James

Come regola generale, sono d'accordo con le altre risposte: un singolo tasto per utente è spesso il modo più pratico di procedere. Tuttavia, non è un approccio valido per tutti.

Ecco alcune considerazioni aggiuntive.

  • Se si utilizza un agente SSH, più di tre o quattro chiavi diventano problematiche, poiché durante la connessione a un server, il client SSH può provare una delle chiavi memorizzate dopo l'altra. Ciò potrebbe comportare diversi accessi non riusciti sul lato server e potresti effettivamente scoprire che il tuo account è bloccato prima che SSH provi anche la chiave corretta. Questo aspetto favorisce l'approccio one-key-per-user.

  • Se stai servendo più entità indipendenti (come un consulente che serve più clienti), considera una chiave SSH separata per ciascun cliente. Non è inaudito che al termine della relazione, il client potrebbe richiedere la consegna di tutte le password e le chiavi SSH. A volte, spiegare perché questa non è una buona idea funziona, ma se il cliente riceve qualcosa come un ordine del tribunale, potresti avere un problema.

  • Se la chiave privata SSH è compromessa, potrebbe essere necessario modificarla su molti sistemi. ricorda ogni singolo sistema che tu abbia mai impostato, negli ultimi dieci anni, con quella chiave SSH? Ti ricordi di rimuovere la tua chiave SSH compromessa da Github? O dal router in un ripostiglio in ufficio un paio afferma che gestisci da remoto? Che dire dei sistemi che non puoi più toccare perché non lavori più per quel particolare client?

Alla fine, si tratta di comprendere le implicazioni dei due approcci e di bilanciarli con le preoccupazioni particolari della tua situazione.

2
Kevin Keane

Questo potrebbe arrivare un po 'in ritardo, ma penso che valga la pena menzionare: dal punto di vista della sicurezza e della convenienza, quando si gestiscono utenti umani, è preferibile avere una chiave per utente.

I vantaggi derivano dalla necessità di revocare l'accesso a un singolo utente.

Diciamo che stai usando una chiave per tutti gli utenti e senza password (o con la stessa password). È possibile disabilitare l'utente nel server (l '"account"), ma tutte le esigenze umane sono l'utente e la chiave per ottenere l'accesso. Ha già la chiave in quanto è un file, non puoi controllarlo, e quindi ha solo bisogno di un nome utente (forse l'utente (gli account) sono creati con un algoritmo standard (ad es. Prima lettera del nome + cognome)) per ottenere accedere come un altro utente. Quindi, per motivi di sicurezza, dovresti creare una nuova coppia di chiavi (e consegnarla agli utenti) e disabilitare la vecchia coppia di chiavi.

È molto più semplice se hai una chiave per utente, in quanto disabiliti l'utente (e la chiave se vuoi).

Quando si gestiscono sistemi o server che gestiscono dati sensibili, in cui il pool di utenti è variabile (e quasi sicuramente lo sarà, ciò che varia è la velocità di rotazione), ciò diventa una buona pratica in termini di sicurezza e convenienza.

1
Manuel Herrera

Da quando è stata posta la domanda, il panorama è cambiato notevolmente. Oggi, ci sono due punti che favoriscono una singola chiave SSH per tutti gli host.

  • Le chiavi hardware stanno diventando più popolari. Almeno il marchio probabilmente più popolare, Yubikey, supporta solo una singola chiave SSH.
  • Se si utilizza un server LDAP per l'autenticazione, è possibile aggiungere uno schama LDAP per archiviare una chiave pubblica SSH in LDAP, anziché aggiungerla a ciascun host singolarmente. Alcune altre soluzioni IDM possono anche offrire funzionalità simili.

Naturalmente, ciò non invalida le altre considerazioni menzionate nelle risposte precedenti.

0
Kevin Keane