Questo è un tipico esempio di compromesso tra sicurezza e convenienza. Fortunatamente ci sono una serie di opzioni. La soluzione più appropriata dipende dallo scenario di utilizzo e dal livello di sicurezza desiderato.
ssh-key con passphrase, no ssh-agent
Ora la passphrase deve essere inserita ogni volta che la chiave viene utilizzata per l'autenticazione. Sebbene questa sia l'opzione migliore dal punto di vista della sicurezza, offre la peggiore usabilità. Ciò può anche portare alla scelta di una passphrase debole per ridurre l'onere di inserirla ripetutamente.
ssh-key con passphrase, con ssh-agent
Aggiungendo quanto segue ~/.bash_profile
si avvierà ssh-agent
e caricherà automaticamente le chiavi ssh all'accesso:
if [ -z "$SSH_AUTH_SOCK" ] ; then
eval `ssh-agent -s`
ssh-add
fi
Ora la passphrase deve essere inserita ad ogni accesso. Sebbene leggermente migliore dal punto di vista dell'usabilità, questo ha lo svantaggio che ssh-agent
richiede la passphrase indipendentemente dal fatto che la chiave debba essere utilizzata o meno durante la sessione di accesso. Ogni nuovo accesso genera anche ssh-agent
un'istanza distinta che rimane in esecuzione con le chiavi aggiunte in memoria anche dopo il logout, a meno che non sia stata esplicitamente uccisa.
Per terminare ssh_agent
al logout, aggiungi quanto segue a~/.bash_logout
if [ -n "$SSH_AUTH_SOCK" ] ; then
eval `/usr/bin/ssh-agent -k`
fi
o il seguente a ~/.bash_profile
trap 'test -n "$SSH_AUTH_SOCK" && eval `/usr/bin/ssh-agent -k`' 0
La creazione di più ssh-agent
istanze può essere evitata creando un socket di comunicazione persistente all'agente in una posizione fissa nel file system, come nella risposta di Collin Anderson . Questo è un miglioramento rispetto alla generazione di istanze di più agenti, tuttavia, a meno che la chiave decodificata non rimanga esplicitamente rimasta in memoria dopo il logout.
Sui desktop, gli agenti ssh inclusi nell'ambiente desktop, come l' agente SSH di Gnome Keyring , possono essere un approccio migliore in quanto in genere possono essere richiesti per richiedere la passphrase la prima volta che si utilizza ssh-key durante una sessione di accesso e archivia la chiave privata decifrata in memoria fino alla fine della sessione.
ssh-key con passphrase, con ssh-ident
ssh-ident
è un'utilità che può gestire ssh-agent
per tuo conto e caricare identità se necessario. Aggiunge le chiavi solo una volta quando sono necessarie, indipendentemente da quanti terminali, ssh o sessioni di accesso richiedono l'accesso a un ssh-agent
. Può anche aggiungere e utilizzare un agente diverso e un diverso set di chiavi a seconda dell'host a cui si è connessi o da cui viene invocata la directory ssh. Ciò consente di isolare le chiavi quando si utilizza l'inoltro dell'agente con host diversi. Inoltre, consente di utilizzare più account su siti come GitHub.
Per abilitarlo ssh-ident
, installalo e aggiungi il seguente alias al tuo ~/bash_profile
:
alias ssh='/path/to/ssh-ident'
ssh-key con passphrase, con keychain
keychain
è una piccola utility che gestisce ssh-agent
per tuo conto e consente ssh-agent
di rimanere in esecuzione al termine della sessione di accesso. Su accessi successivi, keychain
si connetterà ssh-agent
all'istanza esistente . In pratica, ciò significa che la passphrase deve essere inserita solo durante il primo accesso dopo un riavvio. Negli accessi successivi, ssh-agent
viene utilizzata la chiave non crittografata dall'istanza esistente . Questo può essere utile anche per consentire l'autenticazione RSA / DSA cron
senza password in lavori senza ssh-key senza password.
Per abilitarlo keychain
, installalo e aggiungi qualcosa di simile al seguente a ~/.bash_profile
:
eval `keychain --agents ssh --eval id_rsa`
Da un punto di vista della sicurezza, ssh-ident
e keychain
sono peggiori delle ssh-agent
istanze limitate alla durata di una determinata sessione, ma offrono un elevato livello di praticità. Per migliorare la sicurezza di keychain
, alcune persone aggiungono l' --clear
opzione alla loro ~/.bash_profile
chiamata portachiavi. In questo modo le passphrase devono essere reinserite all'accesso come sopra, ma i cron
lavori avranno comunque accesso alle chiavi non crittografate dopo che l'utente si è disconnesso. La keychain
pagina wiki contiene ulteriori informazioni ed esempi.
ssh-key senza passphrase
Dal punto di vista della sicurezza, questa è l'opzione peggiore poiché la chiave privata è completamente non protetta nel caso in cui venga esposta. Questo è, tuttavia, l'unico modo per assicurarsi che la passphrase non debba essere reinserita dopo un riavvio.
ssh-key con passphrase, con ssh-agent
, passando passphrase a ssh-add
dallo script
Mentre potrebbe sembrare un'idea semplice passare la passphrase ssh-add
da una sceneggiatura, ad esempio echo "passphrase\n" | ssh-add
, non è così semplice come sembra ssh-add
non leggere la passphrase stdin
, ma si apre /dev/tty
direttamente alla lettura .
Questo può essere risolto con expect
, uno strumento per automatizzare le applicazioni interattive. Di seguito è riportato un esempio di uno script che aggiunge una ssh-key usando una passphrase memorizzata nello script:
#!/usr/bin/expect -f
spawn ssh-add /home/user/.ssh/id_rsa
expect "Enter passphrase for /home/user/.ssh/id_rsa:"
send "passphrase\n";
expect "Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)"
interact
Si noti che poiché la passphrase è memorizzata in testo normale nello script, dal punto di vista della sicurezza, ciò non è affatto meglio che avere una ssh-key senza password. Se si deve utilizzare questo approccio, è importante assicurarsi che lo expect
script contenente la passphrase abbia le autorizzazioni appropriate impostate su di esso, rendendolo leggibile, scrivibile e eseguibile solo dal proprietario della chiave.