Aggiornamento:

Una chiave privata corrisponde a una singola "identità" per un dato 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 in alcun modo la tua chiave ^[1] usandolo per accedere a una macchina (come faresti usando una password), quindi avere chiavi separate per destinazioni separate non ti rende più sicuro dal punto di vista dell'autenticazione / sicurezza.

la stessa chiave autorizzata per più macchine prova che lo stesso titolare di chiavi ha accesso a entrambe le macchine da una prospettiva forense. In genere non è un problema, ma vale la pena sottolinearlo.

Inoltre, più luoghi sono autorizzati, più preziosa diventa quella chiave. Se la chiave viene compromessa, più obiettivi vengono messi a rischio.

Inoltre, più luoghi viene archiviata la chiave privata (ad esempio, il computer di lavoro, il laptop e il backup spazio di archiviazione, ad esempio), più posti ci sono per un utente malintenzionato dove andare a prendere una copia. Quindi vale anche la pena considerarlo.

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 dare categoricamente è questo: mantieni la tua chiave privata crittografata. La sicurezza aggiunta è piuttosto significativa.

^[1] : esiste un modo importante in cui l'autorizzazione della stessa chiave SSH in contesti di sicurezza diversi potrebbe essere un problema e tale problema ha a che fare con agente inoltro . Tuttavia, i vincoli e le avvertenze sull'utilizzo sicuro dell'inoltro dell'agente non rientrano nell'ambito di questa domanda.

Penso che questa domanda possa essere considerata da due diverse angolazioni: sicurezza e comodità”.

Quando creiamo una coppia di chiavi SSH, siamo ha 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 coppia di chiavi Inserisci il file in cui salvare la chiave (/Your/HomeDir/.ssh/id_rsa):Enter passphrase (empty for no passphrase):  

Sebbene ci sia un prompt esplicito che chiede per la passphrase, ma alcune (o molte) persone si concentrano ancora maggiormente sulle informazioni tra parentesi: (vuoto per nessuna passphrase) e seguendo quel suggerimento.

Combinando se si utilizzano o meno più coppie di chiavi SSH e se si immette o meno una password aggiuntiva , abbiamo almeno quattro modi per procedere. E supponiamo che tutte le coppie di chiavi e il file config siano archiviati in ~/.ssh/.

Ora non consideriamo la sicurezza per primo.

La tabella seguente fornisce una semplice classificazione della sicurezza (un numero maggiore significa più sicuro):

  Security Ways to go 1 Una coppia di chiavi SSH (NO passwd) 1 Multi coppie di chiavi SSH (NO passwd) 2 Una coppia di chiavi SSH (WITH passwd) 2 Multi coppie di chiavi SSH (WITH passwd) (STESSO passwd) 3 Multi coppie di chiavi SSH (WITH passwd) (DIFF passwd)  

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

Quindi non pensare alla praticità .

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

  Comodi metodi di sicurezza da seguire 5 1 Una coppia di chiavi SSH (NO passwd) 4 2 Una coppia di chiavi SSH (WITH passwd) 3 1 Multi coppie di chiavi SSH (NO passwd) 2 2 Multi coppie di chiavi SSH (WITH passwd) (STESSA password) Coppie di chiavi SSH multiple (WITH passwd) (DIFF passwd)  

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

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

Non è necessario (e nessun miglioramento della sicurezza) avere una chiave per host.

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

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

Non so se ho risposto bene alla tua domanda intendi per "chiave"? ti riferisci alla crittografia asimmetrica?

quando si utilizza la crittografia asimmetrica si dispone di una coppia di chiavi pubblica e privata. La chiave pubblica di ogni utente è memorizzata sul server ssh (host). Questo permette di autenticare l'utente perché per ogni chiave pubblica dovrebbe esserci una sola chiave privata.

cosa intendi per avere una chiave ssh per tutti gli host?

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

1. STESSA chiave su tutti gli host: i malintenzionati ora hanno accesso a tutto .
2. Chiave DIVERSA su ogni host: i malintenzionati hanno accesso solo a una cosa.

Quindi, più sicuro? Chiavi univoche per ogni host.

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

Ecco alcune considerazioni aggiuntive.

• Se utilizzi un Agente SSH, più di tre o quattro chiavi diventano problematiche, perché quando ci si connette a un server, il client SSH potrebbe provare una delle chiavi memorizzate dopo l'altra. Ciò potrebbe portare a diversi accessi non riusciti sul lato server e potresti effettivamente scoprire che il tuo account è bloccato prima ancora che SSH provi la chiave corretta. Questo aspetto favorisce l'approccio una chiave per utente.

• Se stai servendo più entità indipendenti (come un consulente che serve più clienti), considera una chiave SSH separata per ogni cliente. Non è inaudito che quando la relazione finisce, il cliente può richiedere la consegna di tutte le password e le chiavi SSH. A volte, spiegare perché non è una buona idea funziona, ma se il cliente ottiene qualcosa come un'ingiunzione del tribunale, potresti avere un problema.

• Se la tua chiave privata SSH è compromessa, potrebbe essere necessario modificarlo su molti sistemi. Ti ricordi anche ogni singolo sistema che hai mai configurato, negli ultimi dieci anni, con quella chiave SSH? Ti ricorderesti di rimuovere la tua chiave SSH compromessa da Github? O dal router in qualche armadio in ufficio un paio di affermazioni di distanza che gestisci da remoto? E i sistemi che non puoi più toccare perché non lavori più per quel particolare cliente?

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

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

I vantaggi si ottengono 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). Puoi disabilitare l'utente nel server (l '"account"), ma tutti i bisogni umani sono l'utente e la chiave per ottenere l'accesso. Ha già la chiave in quanto è un file, non puoi controllarlo, quindi ha solo bisogno di un nome utente (forse l'utente (account) è fatto con un algoritmo standard (es. Prima lettera del nome + cognome)) per guadagnare 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 , poiché disabiliti semplicemente l'utente (e la chiave se vuoi).

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

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

• Le chiavi hardware stanno diventando sempre più popolari. Almeno il marchio probabilmente più popolare, Yubikey, supporta solo una singola chiave SSH.
• Se utilizzi un server LDAP per l'autenticazione, puoi aggiungere uno schama LDAP per memorizzare una chiave pubblica SSH in LDAP, invece di aggiungerlo a ciascun host individualmente. Alcune altre soluzioni IDM possono anche offrire caratteristiche simili.

Ovviamente, questo non invalida le altre considerazioni menzionate nelle risposte precedenti.