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 devi compromettere la tua chiave in alcun modo usandola per accedere a una macchina (come faresti usando una password), avendo quindi chiavi separate per destinazioni separate non ti rende più al sicuro da una prospettiva di autenticazione / sicurezza.

Pur avendo la stessa chiave autorizzata per più macchine, si dimostra che lo stesso portatore di chiavi ha accesso a entrambe le macchine da una prospettiva forense. In genere non è un problema, ma vale la pena segnalarlo.

Inoltre, più luoghi sono autorizzati a una singola chiave, più diventa preziosa quella chiave. Se quella chiave viene compromessa, più bersagli sono messi a rischio.

Inoltre, più posti viene memorizzata la chiave privata (ad esempio, il computer di lavoro, il laptop e la memoria di backup), più posti ci sono per un attaccante da raggiungere prendi una copia Quindi vale la pena considerare anche questo.

Per quanto riguarda le linee guida universalmente applicabili su come eseguire la sicurezza: non ce ne sono. Più sicurezza addizionale si aggiunge, maggiore è la comodità che si rinuncia. L'unico consiglio che può fornire categoricamente è questo: tieni la tua chiave privata crittografata. La sicurezza aggiunta è piuttosto significativa.

Penso che questa domanda possa essere considerata da due diversi punti di vista: 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 vi sia un prompt esplicito che richiede la passphrase, ma alcune (o molte) persone si concentrano ancora maggiormente sulle informazioni tra parentesi: (vuoto per nessuna passphrase) e seguendo questo suggerimento.

Combinando indipendentemente dal fatto che usi o meno coppie di chiavi SSH e indipendentemente dal fatto che entri o meno passwd aggiuntivi , abbiamo almeno quattro modi per andare. E supponiamo che tutte le coppie di chiavi e il file config siano memorizzati in ~/.ssh/ .

Non considerare prima sicurezza .

La seguente tabella fornisce una classificazione semplice sulla 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 viene intruso da qualcuno, l'interruttore può ottenere tutte le nostre chiavi private e la configurazione, anche l'autenticazione dei server remoti. Quindi in questa situazione, una coppia di chiavi e coppie di chiavi multiple sono le stesse. Il modo più sicuro è utilizzare password diverse per diverse coppie di chiavi ssh.

Quindi non pensare a convenience .

Ma più coppie di chiavi e più passwd rendono la nostra vita meno comoda, la seguente tabella fornisce una classificazione semplice sulla 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 una situazione generale, se dobbiamo scambiare con sicurezza e comodità allo stesso tempo, possiamo moltiplicare i due punteggi, e forse Una coppia di chiavi SSH (WITH passwd) è quella giusta da scegliere.

Hai solo bisogno di una chiave in quanto la chiave appartiene al tuo utente.

Non c'è bisogno (e nessun miglioramento nella sicurezza) di avere una chiave per host.

Se la tua chiave privata è privata, puoi utilizzare questa singola chiave e utilizzarla per autenticare te stesso su più host.

What is the best practice: separate ssh-key per host and user VS one ssh-key for all hosts?

Non so se ho la tua domanda giusta 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 una sola chiave privata.

cosa intendi con una sola chiave ssh per tutti gli host?

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

1. Chiave SAME su tutti gli host: i cattivi ora hanno accesso a tutto .
2. DIVERSO tasto su ciascun host: i malintenzionati hanno accesso solo a una cosa.

Quindi - più sicuro? Chiavi univoche per ciascun host.

Potrebbe arrivare un po 'in ritardo, ma penso che valga la pena di menzionare: Dal punto di vista della sicurezza e della praticità, quando si gestiscono utenti umani, è auspicabile disporre di una chiave per utente.

I vantaggi arrivano quando è necessario 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 ("account"), ma tutti i bisogni umani sono l'utente e la chiave per accedere. Lui / lei già ha la chiave in quanto è un file, non puoi controllare questo, e poi ha solo bisogno di un nome utente (forse l'utente (account) è fatto con un algoritmo standard (ad esempio prima lettera di 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 si dispone di una chiave per utente, in quanto basta disabilitare l'utente (e la chiave se lo si desidera).

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

Come regola generale, sono d'accordo con le altre risposte: una sola chiave per utente è spesso il modo più pratico per andare. Non è, tuttavia, un approccio valido per tutti.

Ecco alcune considerazioni aggiuntive.

• Se si utilizza un agente SSH, più di tre o quattro chiavi diventano problematici, poiché durante la connessione a un server, il client SSH può provare una delle chiavi memorizzate dopo l'altra. Ciò potrebbe portare a diversi accessi non riusciti sul lato server e si potrebbe effettivamente scoprire che il tuo account è bloccato prima che SSH tenti 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ù client), considera una chiave SSH separata per ogni cliente. Non è inaudito che quando la relazione finisce, il cliente può chiedere di consegnare tutte le password e le chiavi SSH. A volte, spiegando perché non è una buona idea funziona, ma se il cliente ottiene qualcosa come un ordine del tribunale, potresti avere un problema.

• Se la chiave privata SSH è compromessa, potrebbe essere necessario cambiarla su molti sistemi. Ti ricordi ricordi di ogni singolo sistema che hai mai creato negli ultimi dieci anni con quel tasto SSH? Ti ricorderai di rimuovere la chiave SSH compromessa da Github? O dal router in qualche armadio in ufficio un paio dichiara via che tu 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 bilanciarli con le preoccupazioni specifiche della tua situazione.