Gentoo Logo

Guida a Keychain in Gentoo Linux

Indice:

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:

Codice 2.1: Generare un paio di chiavi

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

Avvertenza: Assicuratevi di scegliere una passphrase sicura, specialmente se questa chiave è utilizzata per i login di root!

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.

Codice 2.2: Copiare la chiave pubblica sul 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.

Codice 2.3: Testare le chiavi

$ 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.

Codice 3.1: Preparare ssh-agent

$ ssh-agent

Nota: ssh-agent manterrà le chiavi decriptate finché sarà in esecuzione. Se volete impostare un periodo di vita per le chiavi, usate l'argomento -t come descritto in man 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:

Codice 3.2: Aggiungere altre chiavi a ssh-agent

$ 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.

Codice 3.3: Ssh senza password

$ ssh server

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

Codice 3.4: Terminare ssh-agent

$ ssh-agent -k

Nota: Se avete avuto problemi a far funzionare ssh-agent, questo potrebbe essere ancora in esecuzione. Potete killarlo come ogni altro processo, eseguendo killall ssh-agent.

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.

Codice 3.5: Installare keychain

# 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:

Codice 3.6: Attivare keychain in .bash_profile

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

Nota: Potete aggiungere altre chiavi private alla linea di comando, se lo desiderate. Inoltre, se volete che vi vengano chieste le passphrase ogni volta che aprite una shell, aggiungete l'opzione --clear.

Nota: Se non state usando bash, consultate la sezione EXAMPLES di man keychain per esempi d'uso con altre shell. L'idea è quella di far eseguire quei comandi ogni volta che usate una shell.

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:

Codice 3.7: Modificare /etc/kde/agent-startup.sh

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

Codice 3.8: Modificare /etc/kde/shutdown/agent-shutdown.sh

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:

Codice 3.9: Caricare la chiave ssh

$ 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.


Stampa

Aggiornato il 16 dicembre 2010

La versione originale di questo documento non è più mantenuta

Oggetto: Questo documento descrive come usare chiavi condivise ssh con il programma keychain. Si presuppone la conoscenza di base della crittografia con chiave pubblica.

Eric Brown
Autore

Marcelo Góes
Redazione

Joshua Saddler
Redazione

Cristiano Chiucchiolo
Traduzione

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.