Devo creare una nuova chiave ssh privata su ciascun sistema?


10

Devo connettermi a più server da più dispositivi tramite SSH. Mi chiedo se dovrei creare un nuovo file id_dsa su ciascun dispositivo da cui mi connetto o se non c'è alcun problema a copiare lo stesso file id_dsa su ciascun dispositivo.

Ad esempio, ho il mio principale sistema desktop basato su Ubuntu e un MacBook Pro con ssh. E ho un netbook basato su Windows con Putty installato. E ho un telefono Android con ConnectBot. Da uno di questi dispositivi, potrei aver bisogno di SSH in dozzine di server fisici e virtuali diversi.

Ogni server ha bisogno della mia chiave pubblica installata. Inoltre, i miei account GitHub e Codaset richiedono la mia chiave pubblica.

Per semplificare la gestione delle chiavi, sto pensando di utilizzare la stessa chiave privata su tutti questi sistemi. È una pratica comune o è meglio avere una chiave privata su ciascun sistema?

Risposte:


3

Se si utilizza la stessa chiave pubblica su ciascun sistema e la chiave privata viene compromessa, qualsiasi sistema che utilizza tale chiave, salvo altre restrizioni, sarà accessibile.

Sono sicuro che stai usando chiavi private protette da password?

Nella nostra pratica di gestione, abbiamo "ruoli" a bassa, media e alta sicurezza. Ogni ruolo utilizza una chiave diversa. Le chiavi private di alta sicurezza non devono mai essere trasmesse a risorse esterne, utilizzate su laptop che potrebbero essere persi / rubati, ecc. Le chiavi di sicurezza medio-basse possono essere distribuite in una gamma più ampia di scenari.

Ti suggerisco di esaminare i tuoi modelli di utilizzo e vedere cosa rende in termini di ruoli di sicurezza. Qual è il danno causato dalla tua chiave privata?

Hai considerato di collocare la tua chiave privata SSH su un dispositivo hardware da cui non può essere rubata, rimuovendo il potenziale compromesso della chiave in un problema?

Sia i moduli di sicurezza hardware che le smart card possono essere utilizzati per archiviare le chiavi private SSH in modo sicuro, consentendo di eseguire tutte le operazioni crittografiche sul dispositivo, anziché sui sistemi operativi. Tuttavia, non sono una panacea, in quanto richiedono anche dispositivi hardware di backup, in caso di guasto hardware.


Sì, le mie chiavi sono protette da password. Grazie per la tua risposta. Mi hai aiutato a confermare la mia preoccupazione che se avessi usato la stessa chiave su tutti i miei dispositivi, ciò avrebbe potuto comportare problemi più grandi lungo la strada.
Tauren,

2

Assolutamente si dovrebbe. Puoi sempre aggiungere tutte le chiavi al file authorized_keys2. Mi piace il suggerimento di jeffatrackaid. Tuttavia, utilizzerei chiavi private diverse per ciascun dispositivo, perché no. Perdi il tuo Android. Semplice, rimuovere la chiave dall'elenco delle chiavi autorizzate. In caso contrario, dovrai rigenerare nuovamente quel livello di chiave.

Detto questo, dipende da come percepisci il rischio di queste attività. Ovviamente non vuoi perdere le chiavi, ma alcune possono essere esposte a un rischio maggiore, ad esempio github vs root sul tuo vps, ad esempio.


Cordiali saluti, authorized_keys2è obsoleto dal 2001 - OpenSSH ora utilizza authorized_keys(anche se legge ancora entrambi i file per la compatibilità)
user1686

Ah ok grazie. Ho sempre pensato di disabilitare SSHv1 e codici a bassa resistenza ecc.

2

Ti ricordi quando Debian ha avuto quel piccolo problema di entropia durante la generazione di chiavi SSH? Fu allora che imparai bene la mia lezione.

Ho le mie chiavi private per le mie cose, come entrare nei miei server personali. Ho la mia chiave "All Purpose" che mi porta nella maggior parte delle mie caselle di sviluppo, quindi taglio le chiavi per client che offro.

Tengo anche un elenco molto dettagliato di quali chiavi sono su quali macchine, nel caso dovessi sostituirle o rimuoverle in fretta.

Per tutto ciò che è serio, uso semplicemente LDAP / PAM, nel caso dovessi rimuovere qualcun altro in fretta.

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.