OpenSSH gestione delle chiavi, Parte 2

1.  Introduzione a ssh-agent e keychain

Introduzione a ssh-agent

ssh-agent, incluso nella distribuzione OpenSSH, è uno speciale programma sviluppato per occuparsi di entrambe le chiavi RSA e DSA (vedi la Parte 1 di questa serie per avere un' introduzione sull' autenticazione RSA e DSA). ssh-agent, a differenza di ssh, è un servizio sviluppato solo per mantenere in memoria la tua chiave privata decifrata.

ssh include al suo interno un supporto che permette di comunicare con ssh-agent, abilitando ssh ad acquisire la vostra chiave privata decifrata senza dovervi chiedere la parola chiave per ogni singola connessione. Con ssh-agent semplicemente utilizziate ssh-add per aggiungere la vostra chiave privata nella memoria. Questo processo lo si fa una volta sola; dopodichè ssh pescherà la vostra chiave da ssh-agent, senza scocciarvi a chiedervi la parola chiave.

Utilizzare ssh-agent

Adesso diamo un occhio a come ssh-agent lavora. Quando ssh-agent parte rilascia alcune importanti variabili d'ambiente per poi rilasciarle alla shell e continuare a lavorare in background. Adesso un esempio dell' output generato da ssh-agent quando parte:

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-XX4LkMJS/agent.26916; export SSH_AUTH_SOCK;
SSH_AGENT_PID=26917; export SSH_AGENT_PID;
echo Agent pid 26917;

Come si può vedere l'output di ssh-agent è una serie di comandi bash; se eseguiti, essi impostano una copia di variabili d'ambiente, SSH_AUTH_SOCK e SSH_AGENT_PID. Tramite il comando export, queste varibili saranno poi rese disponibili per tutti gli altri comandi che verranno eseguiti successivamente. Bene, tutto questo avverrà se queste righe verranno valutate della shell, ma per ora esse vengono solo stampate sullo stdout. Per risolvere questo noi possiamo invocare ssh-agent nel modo seguente:

$ eval `ssh-agent`

Questo comando dice alla bash di eseguire ssh-agent e di valutare il suo output. Eseguito in questo modo (cone le virgolette doppie, non le virgolette semplici), le variabili SSH_AGENT_PID e SSH_AUTH_SOCK saranno impostate ed esportate alla vostra shell e saranno rese disponibili ad ogni altro nuovo precesso che verrà eseguito nella vostra sessione di login.

Il metodo migliore per eseguire ssh-agent è quello di aggiungere la seguente riga al vostro file ~/.bash_profile; così facendo tutti i programmi che verranno lanciati dalla vostra shell vedranno le variabili d'ambiente e saranno in grado di individuare ssh-agent e di chiedergli le chiavi necessarie. Una variabile d'ambiente particolarmente importante è SSH_AUTH_SOCK; Essa contiente il percorso allo UNIX domain socket che ssh e scp possono utilizzare per stabilire il dialogo con ssh-agent.

Utilizzare ssh-add

Sicuramente ssh-agent parte con una memoria cache vuota di chiavi private decifrate. Prima che noi possiamo utilizzare veramente ssh-agent, dobbiamo aggiungere la nostra (nostre) chiavi private alla memoria di ssh-agent, utilizzando il comando ssh-add. Nell esempio seguente, utilizzerò ssh-add per aggiungere la mia chiave privata RSA ~/.ssh/identity alla memoria di ssh-agent:

$ ssh-add ~/.ssh/identity
Need passphrase for /home/drobbins/.ssh/identity
Enter passphrase for /home/drobbins/.ssh/identity
(inserisci la parola segreta)

Come potete vedere, ssh-add chiede la parola segreta per poter decifrare e memorizzare la chiave privata nella memoria di ssh-agent affichè sia poi disponibile. Una volta che abbiamo utilizzato ssh-add per aggiungere la chiave privata (o le tue chiavi private) alla memoria di ssh-agent ed è definita la variabile SSH_AUTH_SOCK nella shell corrente (e lo dovrebbe essere se abbiamo eseguito ssh-agent dal nostro ~/.bash_profile), allora possiamo utilizzare scp e ssh per stabilire conessioni remote senza dovere digitare la parola segreta.

Limitazioni di ssh-agent

ssh-agent è ottimo, ma la sua configurazione di default lascia qualche piccolo inconveniente. Diamo uno sguardo più nel dettaglio a ciò.

Prima cosa, con eval `ssh-agent` in ~/.bash_profile, una nuova copia di ssh-agent è eseguita ad ogni sessione di login; questo è non solo dispendioso, ma anche significa che bisogna utilizzare ssh-add per aggiungere una chiave privata per ogni nuova copia di ssh-agent. Se utilizzate un solo terminale od una console di sistema questo non è poi tanto male, ma molti di noi utilizzano parecchi terminali e quindi bisogna digitare la parola chiave per ognuno. Tecnicamente non c'è ragione di questo perchè basta che ci sia in esecuzione una sola copia del processo ssh-agent.

Un altro problema con la configurazione di default di ssh-agent è che esso non è compatibile con cron jobs. Questo perchè cron jobs parte dal processo di cron, egli non può intercettare la variabile d'ambiente SSH_AUTH_SOCK dal suo ambiente e non può sapere se il processo ssh-agent sia in esecuzione e quindi non può nemmeno contattarlo. Ma questo problema è risolvibile.

Scoprendo keychain

Per risolvere questo problema l'autore ha scritto un semplice bash-based ssh-agent front-end chiamato keychain. Cosa lo rende così speciale è che di fatto abilita ad utilizzare un singolo processo ssh-agent per sistema, non solo per sessione di login. Questo significa che dovete solo eseguire una volta ssh-add per chiave privata. Detto in parole semplici, keychain vi aiuta sempre ad ottimizzare il processo ssh-add aggiungendo una sola volta le vostre chiavi private che non siano nella memoria del processo in esecuzione di ssh-agent.

Qui c'è un stralcio di come keychain lavora. Quando parte dal vostro ~/.bash_profile, egli per prima cosa verifica che ssh-agent sia in esecuzione. Se così non fosse, allora lo esegue e registra le importanti variabili SSH_AUTH_SOCK e SSH_AGENT_PID nel file ~/.keychain/<hostname>-sh per salvare in modo sicuro ed utilizzarle poi se necessario. Qui il metodo migliore per eseguire keychain; come se utilizzassimo il vecchio ssh-agent, noi faremmo la configurazione necessaria all'interno di ~/.bash_profile:

#!/bin/bash
#example ~/.bash_profile file
/usr/bin/keychain ~/.ssh/id_rsa
# reindirizzare l'output di ~/.keychain/ output su /dev/null per
# eliminare il noioso messaggio "Agent PID"
source ~/.keychain/<hostname>-sh > /dev/null

# le variabili d'ambiente sono memorizzato usando un file
# hostname-shell, pertanto sostituire <hostname> con il proprio nome host,
# e lo standard "sh" con "csh" o "fish" se si usa una di queste shell

Come si può vedere, con keychain verifichaiamo preferibilemte il file ~/.keychain/<hostname>-shlo valutiamo, non come se facessimo con ssh-agent direttamente. Nonsolo il risultato è lo stesso il nostro importantissimo SSH_AUTH_SOCK è definito e ssh-agent è in esecuzione e pronto per l'utilizzo. Siccome SSH_AUTH_SOCK è memorizzato in ~/.keychain/ , i nostri script di shell e cron jobs possono facilmente connettersi a ssh-agent utilizzando il file ~/.keychain/<hostname>-sh. keychain stesso trae anche vantaggio utilizzando questo file; vi ricordate che quando keychain parte verifica se esiste un ssh-agent in esecuzione. Se cosi fosse, utilizza il file in ~/.keychain/ per acquisire i parametri corretti di SSH_AUTH_SOCK, imponendo a se stesso di utilizzare l' agent esistente anzichè eseguirne uno nuovo. keychain eseguirà un nuovo processo ssh-agent solo se il file ~/.keychain/ è in stallo (punta ad un ssh-agent inesistente) o se ~/.keychain/ non esiste.

Installare keychain

Installare keychain è semplice:

# emerge keychain

Adesso keychain è in /usr/bin/, aggiungilo al vostro ~/.bash_profile, fornendo il percorso della vostra chiave privata come argomento. Qui c'è un ottimo esempio di avvio di keychain insieme a ~/.bash_profile:

#!/bin/bash
# nella linea seguente, lanciamo keychain e puntiamo alla chiave
# privata che vogliamo inserire nella sua cache

/usr/bin/keychain ~/.ssh/id_rsa ~/.ssh/id_dsa

# le variabili d'ambiente sono memorizzato usando un file
# hostname-shell, pertanto sostituire <hostname> con il proprio nome host,
# e lo standard "sh" con "csh" o "fish" se si usa una di queste shell

source ~/.keychain/<hostname>-sh > /dev/null

# effettuare la derivazione di ~/.bashrc è un'ottima cosa
source ~/.bashrc

Keychain in azione

Una volta che avete configurato il vostro ~/.bash_profile per chiamare ad ogni login, sconnettetevi e riconnettetevi. Quando lo farete, keychain eseguirà ssh-agent e memorizzera l'impotazione della variabile d'ambiente in ~/.keychain/, e chiederà la parola chiave per ogni vostra chiave privata specificata nella linea di comando di keychain dal ~/.bash_profile:

Figura 1.1: Keychain viene eseguito per la prima volta

Una volta che avete inserito la parola chiave, le vostre chiavi private saranno caricate in memoria, e keychain uscirà. Dopodichè, ~/.keychain/<hostname>-sh verrà derivato, inizializzando la vostra sessione di login per lavorare con ssh-agent. Adesso, se vi loggate nuovamente, vedrete che keychain trovarà il processo esistente di ssh-agent; esso non è terminato quando avete chiuso la sessione di login. Inoltre, keychain verificherà che la (le) chive privata che avete specificato sia presente nella memoria di ssh-agent. Se così non fosse, vi sarà chiesta la rispettiva parola chiave, me se invece tutto filasse liscio, il processo esistente di ssh-agent continuerà a contenere le chiavi private precedentemente aggiunte; questo significa che non vi sarà richiesta la password:

Figura 1.2: Keychain trova il processo esistente di ssh-agent

Congratulazioni; vi siete appena loggati e siete in grado di eseguire ssh e scp si sistemi remoti; Non necessitate di eseguire ssh-add dopo il login,ssh e scp non chiederanno la parola segreta. Di fatto, finchè il vostro processo iniziale di ssh-agent resterà in esecuzione, sarete in grado di loggarvi e stabiliere connessioni ssh senza fornire la password. Ed è molto utile che il vostro processo ssh-agent continuerà a restare in esecuzione finchè non verrà riavviata la macchina; Da quando lo avrete configurato correttamente su un sistema Linux, non sarà necessario inserire una password per parecchi mesi! Benvenuti nel mondo della sicurezza, connessini senza password utilizzando autenticazioni RSA e DSA.

Proseguire e create parecchie sessioni di login, e vedrete che keychain catturerà perfettamente sempre lo stesso processo ssh-agent.Non dimenticate che anche i vostri scripts di cron jobs cattureranno il processo in esecuzione di ssh-agent. Per utilizzare i comandi ssh o scp dalla vostra shell o i vostri cron job, assicuratevi che puntino a ~/.keychain/<hostname>-shell:

(Le variabili d'ambiente sono memorizzato usando un file
hostname-shell, pertanto sostituire <hostname> con il proprio nome host, e
lo standard "sh" con "csh" o "fish" se si usa una di queste shell)

$ source ~/.keychain/<hostname>-sh

Allora ogni comando seguente di ssh o scp sarà in grado di trovare il processo correntemente in esecuzione di ssh-agent e di stabilire connessioni sicure senza password come se foste dalla shell.

Opzioni di Keychain

Dopo che avere reso keychain funzionante, siate sicuri di scrivere keychain --help per famigliarizzare voi stessi con tutte le opzioni di riga di comando di keychain. Date un occhiata in modo particolare all'opzione --clear.

Se vi ricordate la Parte 1, Ho spiegato che utilizzare chiavi decifrate è una pratica rischiosa perchè questo abilita qualcuno a rubare la vostra chiave privata ed ad utilizzarla per accedere ai vostri account remoti di ogni altro sistema che non richieda password. Bene, mentre il keychain non è vulnerabile a questo genere di abuso (finchè usate le chiavi private cifrate, questo è), c' è una potenziale debolezza utilizzabile direttamente relativa al fatto che keychain rende facile "agganciare" il processo long-running dell agente ssh. Che cosa accadrebbe, ho pensato, se un certo intruso potesse in qualche modo calcolare la mia password o parola segreta ed accedere al mio sistema? Se così fosse, ed entrasse con il mio username, keychain gli assegnerebbe l'accesso alle mie chiavi privare decifrate, dandogli la possibilità senza sforzo di accedere agli altri miei accounts.

Adesso, prima che continui, rivedremo questo argomento sulla sicurezza più avanti. Se qualche utente malintenzionato o qualcuno in grado di loggarsi con le mie credenziali, keychain gli darà effettivamente accesso ad ogni mio account remoto. Tuttavia sarebbe difficile per l'intruso decifrare la mia chiave privata finchè essa restera cifrata sul disco. In aggiunta, per guadagnare l'accesso alla mia chiave privata è richiesto anche che sia loggato con le mie credenziali, non solo leggerlo dal disco. Cosi, abusare di ssh-agent sarà un compilto molto più difficile che semplicemente rubare una chiave privata decifrata, il quale solo richiede che l'intruso guadagni l'accesso al mio file ~/.ssh, sia esso entrato con in mio account o no. Tuttavia, se un intruso potesse con successo entrare come me, potrebbe creare molti danni supplementari utilizzando le mie chiavi riservate decifrate. Così se voi utilzziate keychain su un server di cui non verificate i log e non monitorizzare i bugs della sicurezza, l'idea di utilizzare l'opzione --clear può solo che aumentare la sicurezza.

L'opzione --clear vi abilita a chiedere a keychain di supporre che ogni nuovo login nell'account sia da considerare un potenziale buco nella sicurezza fino al caso contrario. Quando voi eseguite keychain con l'opzione --clear, keychain immediatemente svuoterà tutte le vostre chiavi private dalla memoria durante il processo di login, prima di eseguire il suo normale lavoro.Così, se voi siete un intruso, keychain vi chiederà di inserire la parola segreata per darvi l'accesso alle chiavi private già presenti in memoria. Tuttavia questa cosa migliora la sicurezza ma crea qualcosa di poco conveniente, simile a come se utilizzassimo ssh-agent da solo, senza keychain. Qui dipende dai casi, ognuno può optare per una migliore sicurezza o convenienza, ma non per entrambe le cose.

Malgrado questo, usando keychain con -- clear ancora presenta i vantaggi elencati sopra usando l'ssh-agente da solo; ricordardatevi, quando usate keychain --clear, i vostri cron-job e scripts potranno ancora stabilire connessoni senza password; questo perché le vostre chiavi private sono svuotate al login e non al logout. Poiché un logout dal sistema non costituisce una rottura della sicurezza, non c'è motivo affinchè il keychain risponda eliminando le chiavi dell' ssh-agent. Quindi, l' opzione --clear è una scelta ideale per server con rari accessi e che devono effettuare mansioni di copie sicure occasionali, quali backup, firewall e routers.

Siamo ok!

Adesso la serie sulla gestione delle chiavi di OpenSSH è completa, dovreste aver acquisito una buona familiarità con le chiavi RSA e DSA ed una buona conoscenza per utilizzare un metodo sicuro e conveniente. Siate sicuri anche di continuare con le seguenti risorse:

2.  Risorse

• Leggete la serie di Daniel su OpenSSH gestione delle chiavi Parte 1 e Parte 3.
• Visitate la pagina degli sviluppatori di OpenSSH
• Controllare le FAQ di OpenSSH
• Putty è un ottimo client ssh per macchine Windows.
• Puoi inoltre trovare Reilly's SSH, The Secure Shell: The Definitive Guide per essere soddisfatto. Il sito dell'autore contiene informazioni sul libro, FAQ, news, ed aggiornamenti.