Come conservare le chiavi SSH?

67

Ho iniziato a usare le chiavi SSH invece delle password solo di recente (grazie a GitHub, ovviamente), quindi tieni presente che sono piuttosto nuovo a questo intero concetto. Attualmente le mie chiavi si trovano semplicemente sotto ~ / .ssh, ma non sono sicuro che questa sia una buona pratica. Ad esempio, se ho più macchine, dovrei duplicare le mie chiavi private, cosa che ritengo indesiderabile. Oppure, se il mio HDD diventa kaput, allora perderò quei tasti, il che (immagino) sia indesiderabile.

Quindi, quali sono le migliori pratiche per archiviare le chiavi SSH in modo sicuro, conveniente e affidabile?

Sembra che usare una smartcard sia un'opzione (vedi Smartcard per la memorizzazione delle chiavi gpg / ssh (Linux) - di cosa ho bisogno? ), È questa la migliore?

Aggiornamento: il motivo della domanda era che molti servizi (come GitHub, AWS EC2) forniscono guide su come impostare le chiavi SSH per l'utilizzo del servizio, ma poco o niente background (come, cosa fare se si dispone già di una chiave generata di ssh-keygen[1], quali sono le misure di sicurezza consigliate). E non è chiaro se tali informazioni non siano effettivamente importanti o se ci si aspetta che lo sappiano "per impostazione predefinita".

Riassumendo le risposte fino a questo punto (ma per favore leggile, e se hai qualcosa da aggiungere — per favore fallo): sembra che in questo caso vada bene se lasci le tue chiavi private in ~ / .ssh, purché tu tenerli dagli altri; ma assicurati di avere un altro modo per accedere al servizio per caricare o generare una nuova chiave se ne perdi una (che è normalmente il caso).

[1] GitHub era utilizzato per fornire assistenza su come gestire più chiavi .

security ssh-keys

— Anton Strogonoff
fonte

Quel link sembra essere rotto help.github.com/multiple-ssh-keys

— Prezzo KJ

@KJ Price, grazie alla Wayback Machine di Internet Archive , la pagina è ancora disponibile online, sebbene non al suo link originale. Una copia della pagina archiviata il 2 settembre 2011 è disponibile in più chiavi SSH .

— moonpoint,

41

Ad esempio, se ho più macchine, dovrei duplicare le chiavi private, che ritengo indesiderabili.

No, in realtà no. Se hai più macchine, devi solo creare una chiave privata separata su ognuna. Per ogni chiave privata, carica semplicemente la chiave pubblica corrispondente su GitHub usando lo stesso processo.

Inoltre, se il mio HDD diventa kaput, perderò la mia chiave privata, che (immagino) è indesiderabile.

Non proprio; se perdi la tua chiave privata, generane una nuova e carica la chiave pubblica corrispondente.

Per quello che vale, hai ragione a dire che duplicare una chiave privata è altamente indesiderabile. Idealmente, una chiave privata dovrebbe essere generata in un file ( ~/.ssh/id_rsaad esempio) e non dovrebbe mai lasciare quel file, ovvero non dovrebbe mai essere copiato, spostato e soprattutto non trasferito su una rete. (es. li escludo dai backup) A causa della natura dei protocolli di autenticazione asimmetrici, devi solo preoccuparti di tenere la chiave privata fuori dalle mani degli altri. Se vai un po 'fuori bordo e ne perdi la traccia da solo, generalmente non è un grosso problema. (Questo non deve essere confuso con le chiavi private di crittografia asimmetrica , ad esempio chiavi GPG, che probabilmente si desidera tenere.)

— David Z
fonte

14

Funziona solo se hai qualche altro metodo di accesso ai server a cui quella chiave privata fornisce l'accesso. È possibile caricare la nuova chiave pubblica solo se si dispone di tale accesso di backup.

— ALBERO

2

@TREE: giusto, ma nella mia esperienza è eccezionalmente raro trovare un server che non fornisca un metodo di accesso alternativo (o almeno di aggiungere una chiave pubblica aggiuntiva senza passare attraverso SSH).

— David Z,

3

Grazie, questo chiarisce molto le cose. In realtà, perdere la chiave SSH privata non sembra un problema, poiché per tutti i servizi che sto usando sembra esserci sempre un altro modo per accedere a un servizio per caricarne uno nuovo.

— Anton Strogonoff,

3

AWS non fornisce altre forme di accesso oltre alla chiave privata. Devi scollegare l'unità e scherzare con essa per accedere dopo aver perso la chiave privata.

— Assad Saeeduddin

1

Nota che puoi inserire una password sulla tua chiave privata se desideri un altro livello di sicurezza.

— sudo,

8

Vorrei aggiungere che ~ / .ssh / è leggibile dal tuo browser se stai usando lo stesso account utente per eseguire entrambi.

Provalo! Puntare il browser sulla chiave privata nella home directory. È divertente.

Quindi consiglierei di memorizzare ssh-keys nella home directory di un altro account utente.

una parola sulle chiavi di protezione della passphrase

In questi giorni, decifrare password non casuali è super veloce. Dai un'occhiata all'hash cat
- (Sebbene le password casuali e lunghe di 12+ caratteri impieghino ancora abbastanza tempo per forzare la forza)
- Pertanto, le chiavi ssh crittografate AES non sono crackabili per il futuro prevedibile, purché si utilizzino passphrase lunghe valide. Vedi i consigli di Github
Quindi alcuni siti Web possono indovinare la tua chiave senza JavaScript. E poi forza bruta la chiave offline.
E i browser possono anche guardare negli Appunti con JS. Quindi incollare passphrase molto lunghe ti mette anche a rischio a causa dei più sofisticati attacchi javascript.

look_at_keys.html

 9 <HTML>
10 <HEAD>
11 <TITLE>look at keys</TITLE>
12 </HEAD>
13 <FRAMESET cols="20%, 80%">
14   <FRAMESET rows="100, 200">
15       <FRAME src="/Users/yourname/.ssh/stuff.pem">
16       <FRAME src="blah.html">
17   </FRAMESET>
18   <FRAME src="contents_of_frame3.html">
19 </FRAMESET>
20 </HTML>

— HeyWatchThis
fonte

17

Per essere chiari, solo perché il browser può leggere la tua chiave privata che non significa che un sito Web in esecuzione nel browser può farlo.

— Ajedi32

6

Ma, se si inietta un processo nel processo del browser. Quindi puoi prendere anche il controllo del browser. Quindi questo argomento è perfettamente valido.

— BigSack

Ma poi devi hackerare il processo che inietta i processi nel registro dei processi dell'unità di elaborazione del tuo browser.

— Skid Kadda,

8

Esiste uno strumento molto carino chiamato KeePass2 ( http://keepass.info/ ) con l'estensione ( http://lechnology.com/software/keeagent/ )

Puoi archiviare password, chiavi SSH e molto altro (sulla pagina ufficiale di KeePass ci sono molte estensioni molto utili)
Se vuoi accedere automaticamente con le tue chiavi SSH, devi solo installare PuTTY, Pageant e KeePass con KeeAgent. Se lo si sta configurando correttamente, non è necessario impostare i tasti in PuTTY, Pageant o FileZilla.

Lo uso da solo e ne sono abbastanza contento. Ho oltre 30 VPS e Root Server con un certo numero di chiavi SSH diverse e l'unica cosa che devo fare è aprire KeePass (non è la mia password principale sicura) e quindi devo solo digitare nella console la mia passphrase.

— CentrixDE
fonte

3

Consiglierei di memorizzare le chiavi private:

offline (non nel cloud)
in più di un posto
a parte tutto ciò a cui è correlato, ad esempio una chiave per i dati crittografati, archiviarlo in un luogo separato dai dati

Direi che il posto migliore sarebbe:

un disco rigido esterno
un tasto flash
un computer non collegato a Internet

Ancora meglio, stampalo e mettilo in una cassaforte ignifuga.

— bla
fonte

4

Sicurezza / buone pratiche lavorano di pari passo con la praticità. Se una strategia di sicurezza ostacola la capacità di utilizzare un sistema, verrà ignorata dall'utente anziché dall'attaccante.

— zaTricky,

1

Ho un file tar che ha la mia configurazione dir utente (.bashrc, .ssh / e altri file di configurazione) che conservo in un posto sicuro. Quando ottengo un nuovo account shell ovunque, decomprimo il file tar in esso.

Dovresti mettere le tue chiavi private solo sui server di cui ti fidi, altrimenti dovresti creare una nuova chiave privata sul server solo per quel server e consentirgli di accedere alle cose a cui vuoi che abbiano accesso.

Personalmente, mi sento a mio agio semplicemente copiando il mio .ssh / stuff ovunque (significa anche che con il normale tasto ssh si ottiene immediatamente l'accesso ssh, poiché è già nel file authorized_keys).

— EightBitTony
fonte

Immagino che avere crittografato ~ / .ssh in giro su una chiavetta USB salverebbe dalla necessità di generare e caricare una nuova chiave in caso di guasto dell'hardware. Tuttavia, poiché ci sono pochissimi server a cui utilizzo le chiavi SSH per accedere (e pochissime macchine da cui mi connetto), la generazione di nuove chiavi non causerà un sovraccarico.

— Anton Strogonoff,

2

È cavalli per corsi e dipende dal motivo per cui usi le chiavi. Non vedo problemi a copiare una chiave privata ssh su un collegamento SSH già crittografato. Ma se non ti fidi della macchina target e non sai chi ha accesso come root, non dovresti mettere nulla sul server che non puoi permetterti di perdere.

— EightBitTony,

Non vuoi mettere la tua chiave privata sul server di qualcun altro. Chiunque abbia accesso root su quel server può leggere la tua chiave privata e quindi può impersonarti su sistemi a cui accedi con quella chiave privata. Dovresti solo inserire la tua chiave pubblica per l'accesso al server. E non pensare che la passphrase sia di grande aiuto se la usi su un computer remoto per decrittografare una chiave privata.

— Codeguy007,

È possibile inoltrare ssh-agent su ssh. In questo modo non è necessario archiviare la chiave privata sul server o inviare la passphrase in rete. stackoverflow.com/questions/12257968/...

— Codeguy007

1

È possibile memorizzare le chiavi ssh in una directory separata all'interno di una partizione crittografata. Quindi puoi usare ssh che punta a quella directory con -i:

ssh -i identity_file me@example.com

Descrizione completa ( man ssh):

-i file_identità

Seleziona un file da cui viene letta l'identità (chiave privata) per l'autenticazione con chiave pubblica. L'impostazione predefinita è ~ / .ssh / identità per la versione 1 del protocollo e ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa, ~ / .ssh / id_ed25519 e ~ / .ssh / id_rsa per la versione 2. del protocollo. anche essere specificato su base per host nel file di configurazione.
È possibile avere più opzioni -i (e più identità specificate nei file di configurazione). Se nessun certificato è stato esplicitamente specificato dalla direttiva CertificateFile, ssh proverà anche a caricare le informazioni sul certificato dal nome file ottenuto aggiungendo -cert.pub ai nomi dei file di identità.

Il mio approccio alla sicurezza è quello di dividere le informazioni in private e generali. Non voglio crittografare la mia intera partizione home, ecco perché copio i file segreti (come quelli in ~/.ssh) in una partizione crittografata.

Penso che questo offra una sicurezza piuttosto efficiente, perché il malware non troverà nulla in ~ / .ssh e probabilmente non eseguirà la scansione dell'intero sistema o dei profili della shell per trovare quella posizione.

-F configfile

imposta il percorso del file di configurazione.

PS Vorrei creare un alias alias ssh='ssh -i ... -F ...'e inserirlo nel tuo profilo.

PPS Non l'ho ancora verificato e non so come altri programmi (come git) funzioneranno con queste impostazioni ssh.

— Yaroslav Nikitenko
fonte