Domanda:
Best practice: "chiave ssh separata per host e utente" vs. "una chiave ssh per tutti gli host"
static
2013-08-05 01:12:30 UTC
view on stackexchange narkive permalink

È meglio creare una chiave SSH separata per ogni host e utente o utilizzare semplicemente la chiave id_rsa per l'autenticazione di tutti gli host? Un id_rsa potrebbe rappresentare un illecito per le politiche sulla privacy / anonimato?

Aggiornamento:

avere una chiave ssh per tutti gli host:

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

rispetto a chiavi ssh separate:

  ~ / .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 ... ecc.  
correlate: ["Riutilizzo di chiavi private / pubbliche"] (http://security.stackexchange.com/questions/10203/reusing-private-public-keys)
Otto risposte:
#1
+181
tylerl
2013-08-05 10:52:30 UTC
view on stackexchange narkive permalink

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.

Grazie per la risposta così ricca! Conosci un buon articolo sulla crittografia della chiave privata? Questo si adatta abbastanza [http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html]?
Va bene; [informazioni simili qui] (http://security.stackexchange.com/a/39293/2264). Usa `ssh-keygen -p` per crittografare nuovamente le chiavi esistenti. ([Docs] (http://linux.die.net/man/1/ssh-keygen))
"quindi avere chiavi separate per destinazioni separate non ti rende più sicuro dal punto di vista dell'autenticazione / sicurezza" non è come dire "usare password separate per gli accessi al tuo sito web non è più sicuro che usare una password diversa per ogni sito web"?
PastaFeline, penso che la differenza fondamentale (vedi cosa ho fatto lì?) È che i bit segreti (la chiave privata) per SSH non lasciano mai la macchina client, mentre i bit segreti (la password) o un hash di essi vengono trasmessi ala macchina remota per l'autenticazione della password.Se la password di un utente è debole, è vulnerabile al cracking a forza bruta (vedi Rainbow Tables) anche se tutto ciò che hai è l'hash.
@SpaghettiCat no, quello che sto dicendo è che l'utilizzo di una singola chiave ssh su più destinazioni non fornisce a nessuna destinazione informazioni sufficienti per impersonarti a nessuno degli altri.
Lancio i miei due centesimi. Uso una chiave diversa per ogni host.Lavoro per più clienti e da più macchine.Pertanto, devo archiviare la mia chiave privata (crittografata) in alcuni archivi cloud (crittografati), nel caso in cui avessi bisogno di accedere a un host da un'altra macchina.Se devo rischiare di togliere la chiave dalla mia macchina, preferirei che fosse per un host e non per tutto ciò a cui ho i permessi di accesso.È un bel po 'di seccatura, ma credo che sia più sicuro che spostare una chiave con super privilegi.
#2
+26
YaOzI
2017-07-20 14:37:53 UTC
view on stackexchange narkive permalink

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.

Questa dovrebbe essere la risposta accettata in quanto risponde esplicitamente alla domanda in modo molto chiaro.
#3
+4
Uwe Plonus
2013-08-05 10:41:17 UTC
view on stackexchange narkive permalink

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.

Questo è sbagliato. L'uso della stessa chiave per accedere a 2 server / account rivela che entrambi gli utenti sono probabilmente la stessa persona.
@Navin Cosa c'è di sbagliato in questo?
@AsfandYarQazi Se utilizzi la stessa chiave su siti diversi, puoi facilmente deanonimizzarti.Vai avanti e google "Uccidiamo le persone in base ai metadati".
Vedo.Ti rendi conto di esserti appena deanonimizzato postando due commenti con lo stesso account?Spero che non ti prendano.
[email protected] == Asfand Qazi !!
#4
+2
enigma
2013-08-05 04:06:26 UTC
view on stackexchange narkive permalink

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.

enter image description here

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

Ho già visto l'immagine, ma mi interessano i dettagli del passaggio dal passaggio "Server SSH remoto configurato con" Chiave pubblica "" a "Coppie di chiavi private e pubbliche ABBINATE?"
se sei interessato solo alla transizione da "Server SSH remoto configurato con" Chiave pubblica "" a "Coppie di chiavi private e pubbliche ABBINATE?" quindi dai un'occhiata [questo] (http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_04.htm)
#5
+2
James
2016-05-07 21:36:42 UTC
view on stackexchange narkive permalink

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.

Se l'aggressore ha accesso alla cartella dalla domanda, non solo ha accesso alla tua chiave privata, ma anche un elenco di nomi utente e host con cui funzionano le chiavi
sì;le persone devono essere effettivamente produttive con le misurazioni della sicurezza.Se aumenti il carico di utilizzo, puoi anche aumentare la probabilità di un exploit.
Su una macchina tipica, ad esempio un computer OSX, le chiavi risiedono in genere in ~ / .ssh / Se un utente malintenzionato ha accesso a una chiave, probabilmente significa che ha accesso a tutte.In questo senso, non c'è alcun vantaggio nell'avere più chiavi su una macchina, tuttavia, è probabilmente prudente avere chiavi individuali per ogni macchina client, tutte registrate su un certo endpoint (diciamo GitHub)?Oppure mi sfugge qualcosa?
@Kris.C'è un vantaggio nell'avere più chiavi su una macchina, [IFF] (https://en.wikipedia.org/wiki/If_and_only_if) le chiavi sono protette da una passphrase e le passphrase sono diverse.Se un utente malintenzionato ottiene l'accesso alle tue chiavi private, dovrà comunque violare la passphrase per ciascuna di esse.Tutto dipende dal livello di minaccia e dallo sforzo che sei disposto a spendere.Vedi anche https://superuser.com/a/121348/478867
@NZD Non è IFF.C'è ancora un vantaggio anche se le passphrase sono le stesse.Ad esempio, il tuo laptop viene rubato mentre una delle chiavi viene decrittografata perché è in uso.L'aggressore ottiene l'unica chiave, ma il fatto che le passphrase siano le stesse non lo aiuta ad accedere alle altre.
@JonBentley Sì, in questo caso hai ragione.Il mio scenario è che, se una (singola) passphrase viene compromessa, l'aggressore avrà accesso solo a un set di chiavi e non a tutte;il danno sarà limitato.Di nuovo, dipende tutto da quanto sei paranoico e da cosa è in gioco.Potresti anche avere chiavi diverse per lavoro e privato e sei costretto a consegnare le tue chiavi di lavoro e passphrase quando lasci l'azienda (potresti rimuovere o modificare la passphrase anche in quel caso).Quindi, immagino, ogni situazione è diversa e richiede un'analisi di sicurezza e protezione.Non esiste una panacea.
Ma se hai una coppia di chiavi `A` su un laptop di lavoro e una coppia` B` su un laptop privato, (una per github e una per bitbucket, ad esempio), non è più sicuro di una singola coppia di chiavianche se le password sono le stesse per "A" e "B"?Nello scenario un utente malintenzionato irrompe in una sola macchina e ottiene la chiave privata.
#6
+2
Kevin Keane
2018-06-08 22:04:15 UTC
view on stackexchange narkive permalink

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.

Scenario 1: non è possibile configurare le chiavi per sito utilizzando un file SSH `config`?
@jdk1.0 Questa è una buona idea a cui non avevo pensato.Penso che probabilmente funzionerebbe anche con Putty.
#7
+1
Manuel Herrera
2018-02-15 01:36:43 UTC
view on stackexchange narkive permalink

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à.

Questo è un grande punto, la minaccia interna è la minaccia maggiore per un'organizzazione.
Credo che tu abbia frainteso la domanda.L'OP non confronta una chiave per utente con una chiave per tutti gli utenti.Sta confrontando una chiave per utente con più chiavi * per utente * per host.
Credo che tu abbia ragione, anche se la mia risposta era prima dell'aggiornamento.Detto questo, la questione del PO è solo una questione di governance, non di migliori pratiche.
#8
  0
Kevin Keane
2019-08-06 01:38:27 UTC
view on stackexchange narkive permalink

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.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...