Va bene usare una chiave SSH con una passphrase vuota?


34

Quando ho appreso per la prima volta come creare chiavi ssh, i tutorial che ho letto affermavano che si doveva scegliere una buona passphrase. Ma di recente, durante l'impostazione di un processo daemon che deve essere inviato a un'altra macchina, ho scoperto che l'unico modo (sembra) di avere una chiave che non ho bisogno di autenticare ad ogni avvio è creare una chiave con un vuoto frase d'accesso. Quindi la mia domanda è: quali sono i problemi con l'utilizzo di una chiave senza passphrase?

Risposte:


38

Una chiave senza passphrase dipende dal fatto che nessun altro sia in grado di ottenere quella chiave (chi non sarebbe in grado di ottenere le risorse a cui dà accesso comunque). Quindi, se la chiave consente l'accesso a una macchina accanto ad essa ed entrambe le macchine hanno lo stesso livello di sicurezza elettronica e fisica, allora non è davvero un grosso problema.

D'altra parte, se la tua chiave si trova su un computer con scarsa sicurezza (forse ha molti utenti non fidati, è facilmente accessibile fisicamente o non è ben aggiornato con il suo regime di patching), allora probabilmente non voglio mantenere le chiavi senza passphrase lì.

In definitiva, dipende dalla fiducia nella tua configurazione e dalla ponderazione dei rischi / costi nel farlo - se puoi essere abbastanza sicuro che un utente malintenzionato non sia realisticamente più facile ottenere l'accesso alla chiave rispetto alla risorsa a cui la chiave ti dà accesso , allora stai bene. Se non hai quella fiducia, dovresti probabilmente risolvere i motivi per cui :)


Solo le persone fidate avranno accesso alla macchina con le chiavi, quindi immagino che risponda alla mia domanda. Grazie.
mozillalives,

11

un'altra soluzione, che migliora la sicurezza e al contempo ti semplifica la vita, quindi non è necessario digitare la password in ogni momento:

se si desidera crittografare la chiave privata, è possibile utilizzare ssh-agentsulla workstation per "memorizzare nella cache" la chiave non crittografata. quando vuoi archiviare la tua chiave decodificata, corri ssh-add ~/.ssh/id_rsao come la tua chiave privata viene chiamata. ti verrà richiesta la password e la chiave decodificata sarà disponibile per le tue connessioni ssh fino a quando non ti disconnetti, uccidi ssh-agento spegni.

puoi usare killle chiavi memorizzate ssh-agent -ke puoi assegnare una vita per la chiave in memoria ssh-agent -t [seconds], ad esempio; se non vuoi mantenere la tua chiave decifrata per sempre, ma vuoi fare un sacco di sparse tra i tuoi host, puoi impostare il timeout su 5-10 minuti. quindi non è necessario inserire continuamente la password della chiave.

di nuovo, tutto questo ha a che fare con la fiducia che hai della sicurezza della tua / workstation /, che, se sei l'unico che ha accesso ad essa, e hai una password locale piuttosto sicura, e non lo fai invita exploit e rootkit su te stesso, la tua chiave privata senza passphrase è ragionevolmente sicura.

se sei come me e mantieni la tua chiave privata su una chiavetta USB, sicuramente vorrai crittografarla, anche se è solo una chiave privata (una separata dalla quale utilizzo sulla mia workstation, quindi se perdo la mia chiave, posso facilmente rimuovere la chiave pubblica della chiavetta dalla ~/.ssh/authorized_keyslista del mio server , che porta anche un / eccellente / motivo per aggiungere commenti UTILI alle tue chiavi pubbliche)

nella tua risposta a una risposta precedente, hai detto che solo le persone di cui ti fidi hanno accesso alla macchina con le chiavi. voglio solo chiarire che la tua chiave privata NON deve trovarsi sul server a cui ti stai connettendo, nel caso sia quello che stai facendo. solo la tua chiave pubblica deve trovarsi sul server, e questo è un problema, motivo per cui è una chiave "pubblica".

oh, ho dimenticato di menzionare; avvio ssh-agentquando avvio X, altrimenti le chiavi crittografate con cui conservo ssh-addnon vengono conservate attraverso xtermsessioni diverse e devo reinserire la password ogni volta che chiudo l' xtermavvio ssh-add. nel mio ~/.xinitrcfile, ho:

if [ -x /usr/bin/ssh-agent ]; then
   eval $(/usr/bin/ssh-agent)
fi

ho la chiamata da ssh-agentconcludere evalperché ssh-agent restituisce alcune variabili di ambiente che devono essere impostate quando viene eseguito e, da quando vengono eseguite ~/.xinitrc, le variabili di ambiente sono costanti durante la sessione X.


Sì, lo so che devo solo caricare la chiave pubblica. È solo che sto collegando un server a un altro, motivo per cui l'ho menzionato. Ma grazie per aver scritto questa risposta chiara e ponderata.
mozillalives,

bene, se lo usi ssh-agente lo usi ssh -A -i privkey user@host, consentirà l'inoltro dell'agente ssh, che ti permetterebbe di accedere a un server dal server iniziale, senza posizionare la tua chiave privata sul primo server. il concatenamento di ssh non è raccomandato, anche senza l'inoltro di chiavi ssh abilitato e ssh -Aha i suoi problemi di sicurezza. non vi è alcun motivo per cui la chiave sul server non possa essere crittografata, mentre la chiave sulla workstation è senza passphrase.
cpbills,

3

Puoi dare un'occhiata a una domanda simile che ho posto sulle chiavi private SSL per i server web. Fondamentalmente, ci sono tre opzioni:

  1. Proteggi la chiave con i permessi del file system.
  2. Utilizzare una chiave protetta da password e inserire la chiave manualmente ad ogni riavvio.
  3. Utilizzare una chiave protetta da password e archiviare la chiave nel filesystem per automatizzare il riavvio.

Ognuno di essi è difettoso, quindi tutto dipende da cosa temi di più.


1

Per l'accesso automatizzato, che come dici tu richiede chiavi senza passphrase, utilizzo sempre le opzioni extra di authorized_keys (vedi sshd (8)) per limitare il comando che può essere eseguito.

Di solito fornisco uno script accuratamente scritto all'estremità remota, che fa esattamente il lavoro (o i lavori - può guardare i parametri) che voglio essere autorizzato.

Quindi lo blocco anche agli indirizzi IP che possono connettersi con quella chiave (non sicuro al 100%, ma va bene anche con la restrizione del comando).


Punto eccellente: se trovi necessario usare chiavi non protette, la cosa migliore che puoi fare è bloccarla!
MikeyB,

1

Finché nessuno oltre a te ha accesso alla chiave, non hai bisogno di una passphrase. In effetti, non è possibile utilizzare una passphrase sui tasti utilizzati dal software automatizzato.


0

Se vuoi usare ssh per fare qualsiasi tipo di procedura automatizzata - sto pensando specificamente ai controlli Nagios - probabilmente non vorrai usare una passphrase.

In questa situazione, probabilmente non lo useresti al di fuori di una LAN e la chiave verrà archiviata in modo sicuro sul server durante la procedura.

La maggior parte dei tutorial che parlano di SSH prevedono che una persona acceda da una rete esterna, possibilmente da un computer non sicuro, nel qual caso il consiglio è valido.

Fondamentalmente, a meno che tu non sappia che c'è una buona ragione per non crearne una passphrase. Essere troppo pigro per digitare la password ogni volta potrebbe essere un motivo abbastanza buono per te :-)


Anche se accedono da una rete esterna, in che modo fa la differenza? È importante solo la sicurezza del computer client, la passphrase viene gestita sul lato client, giusto?
njsg,

Fino a quando il laptop client non viene rubato e utilizzato per violare il perimetro prima che qualcuno abbia la possibilità di revocare la chiave SSH. Una passphrase sulla chiave ti darebbe più tempo per revocare le chiavi.
Dunxd

Quindi, come ho detto, "conta solo la sicurezza del computer client".
njsg,
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.