Guida a Keychain in Gentoo Linux

1.  Introduzione

Il problema

Allora, tutte le vostre amate macchine Gentoo eseguono sshd, ma è un po' seccante per voi digitare ogni volta tutte quelle password per il login, giusto? Oppure forse avete uno script o un cron-job che ha bisogno di un modo conveniente per usare una connessione ssh. In entrambi i casi, c'è una soluzione a questo problema, ed essa si basa sull'autenticazione con chiave pubblica.

Come funziona l'autenticazione con chiave pubblica?

Supponiamo di avere un client che vuole connettersi a sshd su un server. Il client per prima cosa genera un paio di chiavi, e dà la chiave pubblica al server. Fatto ciò, ogni qualvolta il client cerca di connettersi, il server invia una sfida crittografata con quella chiave pubblica. Solo il possessore della corrispondente chiave privata (il client) è il grado di decriptarla, cosicché, come forse avrete già indovinato, la risposta corretta consente l'autenticazione.

2.  Come usare l'autenticazione con chiave pubblica

Generare il vostro paio di chiavi

Il primo passo consiste nel creare il vostro paio di chiavi. Per fare ciò, useremo il comando ssh-keygen come segue:

$ ssh-keygen -t dsa
(Accettate semplicemente i valori predefiniti, ed accertatevi di inserire una passphrase sicura)

Ora dovreste avere una chiave privata in ~/.ssh/id_dsa e una chiave pubblica in ~/.ssh/id_dsa.pub. Siamo pronti a copiare la chiave pubblica sull'host remoto.

Preparare il server

Copieremo il file ~/.ssh/id_dsa.pub sul server dove gira sshd. Lo aggiungeremo anche al file ~/.ssh/authorized_keys che appartiene all'utente che si connette a quel server. Ecco un esempio di come fare ciò se avete già l'accesso ssh al server.

$ scp ~/.ssh/id_dsa.pub server_user@server:~/myhost.pub
$ ssh server_user@server "cat ~/myhost.pub >> ~/.ssh/authorized_keys"
$ ssh server_user@server "cat ~/.ssh/authorized_keys"

L'output dell'ultima riga dovrebbe mostrare il contenuto del file ~/.ssh/authorized_keys. Assicuratevi che appaia correttamente.

Testare la configurazione

In teoria, se tutto è andato bene e se il demone ssh sul server lo consente, ora dovremmo essere in grado di ottenere l'accesso ssh sul server senza password. Avremo ancora bisogno di decriptare la chiave pubblica sul client con la passphrase usata prima, ma questa non dovrebbe essere confusa con la passphrase dell'account utente sul server.

$ ssh server_user@server

Con un po' di fortuna, vi sarà stata chiesto la vostra passphrase per id_dsa, e avrete ottenuto l'accesso ssh sul server come server_user. Se così non è stato, effettuate il login come server_user, e verificate il contenuto di ~/.ssh/authorized_keys per assicurarvi che ogni voce stia in una riga sola. Potreste anche controllare la configurazione sshd per assicurarvi che dia la precedenza all'autorizzazione con chiave pubblica, quando disponibile.

A questo punto, probabilmente starete pensando: "Qual è lo scopo, ho solo sostituito una password con un'altra?!" Rilassatevi, la prossima sezione vi mostrerà esattamente come possiamo usare questo stratagemma per risparmiare tempo prezioso.

3.  Rendere conveniente l'autenticazione con chiave pubblica

Tipica gestione delle chiavi con ssh-agent

Se avete letto fino a questo punto, starete probabilmente pensando che sarebbe grandioso se potessimo in qualche modo decriptare le nostre private una sola volta, ottenendo l'abilità di accedere a ssh liberamente, senza alcuna password. Siete fortunati, perché questo è esattamente ciò per cui esiste il programma ssh-agent.

Il programma ssh-agent di solito viene eseguito all'avvio della sessione X, oppure da uno script di shell di avvio come ~/.bash_profile. Esso funziona creando un socket unix e registrando le appropriate variabili d'ambiente, in modo che tutte le applicazioni eseguite successivamente possano sfruttare i suoi servizi per connettersi al socket. Ovviamente, ha senso solo eseguirlo nel processo genitore della vostra sessione X, se volete usare il set di chiavi decriptate in tutte le successive applicazioni X.

$ ssh-agent

Quando eseguite ssh-agent, questo dovrebbe dirvi il PID del processo ssh-agent in esecuzione, oltre a impostare alcune variabili d'ambiente, ovvero SSH_AUTH_SOCK e SSH_AGENT_PID. Dovrebbe anche aggiungere automaticamente ~/.ssh/id_dsa alla sua raccolta, chiedendovi la passphrase corrispondente. Se avete altre chiavi private che volete aggiungere a ssh-agent, potete usare il comando ssh-add come segue:

$ ssh-add somekeyfile

E adesso viene il bello. Dato che ora dovreste avere decriptato la vostra chiave privata, dovreste essere in grado di accedere al server con ssh senza inserire alcuna password.

$ ssh server

Sarebbe bello sapere come terminare ssh-agent in caso di necessità, giusto?

$ ssh-agent -k

Se volete che ssh-agent vi sia ancora più utile, procedete alla prossima sezione sull'uso di keychain. Prima di proseguire, assicuratevi di killare il processo ssh-agent in esecuzione, come nell'esempio sopra.

Sfruttare ssh-agent fino all'ultima goccia

Keychain vi consentirà di riutilizzare ssh-agent per diversi login, e opzionalmente vi suggerirà le passphrase ad ogni login dell'utente. Ma prima di andare avanti, dobbiamo installarlo.

# emerge keychain

Supponendo che l'installazione sia andata a buon fine, ora possiamo usare keychain liberamente. Per attivarlo, aggiungete quanto segue al vostro ~/.bash_profile:

keychain ~/.ssh/id_dsa
. ~/.keychain/$HOSTNAME-sh
. ~/.keychain/$HOSTNAME-sh-gpg

Proviamo. Per prima cosa assicuratevi di aver killato ssh-agent, eseguito nella sezione precedente, dopodiché avviate una nuova shell, semplicemente loggandovi o aprendo un nuovo terminale. Dovrebbe esservi suggerita la password per ogni chiave specificata sulla linea di comando. Tutte le shell aperte da questo momento dovrebbero riutilizzare ssh-agent, consentendovi di effettuare connessioni ssh senza password.

Usare keychain con KDE

Se siete utenti KDE, anziché usare ~/.bash_profile, potete far sì che KDE gestisca ssh-agent per voi. Per fare ciò, dovete modificare /etc/kde/agent-startup.sh, che viene letto durante l'avvio di KDE, e /etc/kde/shutdown/agent-shutdown.sh, che viene eseguito durante la chiusura di KDE. Ecco come si potrebbero modificare i file:

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

if [ -n "${SSH_AGENT_PID}" ]; then
  eval "$(ssh-agent -k)"
fi

Ora, tutto ciò che dovete fare è lanciare un terminare a vostra scelta, come Konsole, caricando le chiavi che desiderate usare. Per esempio:

$ keychain ~/.ssh/id_dsa
(Inserite la password della chiave)

Le vostre chiavi verranno ricordate fino a quando non terminerete la vostra sessione KDE o killerete manualmente ssh-agent.

4.  Note conclusive

Considerazioni sulla sicurezza

Ovviamente, l'uso di ssh-agent può rendere il vostro sistema un po' meno sicuro. Se un altro utente volesse usare la vostra shell mentre siete in bagno, egli potrebbe accedere a tutti i vostri server senza alcuna password. Questo è un rischio per i server a cui vi state collegando, e dovreste assicurarvi di consultare la politica locale riguardo alla sicurezza. Se lo usate, assicuratevi di prendere misure appropriate per assicurare la sicurezza delle vostre sessioni.

Risoluzione problemi

La maggior parte di quanto detto dovrebbe funzionare abbastanza bene, ma se incontrate problemi, vi sarà certamente utile sapere un paio di cose.

• Se non siete in grado di connettervi senza ssh-agent, provate ad usare ssh con gli argomenti -vvv per vedere cosa sta succedendo. A volte il server non è configurato per usare l'autenticazione con chiave pubblica, talvolta è configurato per chiedere sempre le password locali! Se questo è il vostro caso, potreste usare l'opzione -o con ssh, oppure modificare il file sshd_config del server.
• Se avete problemi com ssh-agent o keychain, potrebbe darsi che la shell che state utilizzando non comprenda i comandi che essi usano. Consultate le man pages di ssh-agent e keychain per i dettagli sul funzionamento con altre shell.
• Visitare anche l'homepage di keychain per ulteriori consigli sul suo utilizzo.

I contenuti di questo documento sono rilasciati sotto la licenza Creative Commons - Attribution / Share Alike.