1 487
contributi
Buildd: differenze tra le versioni
m
nessun oggetto della modifica
mNessun oggetto della modifica |
mNessun oggetto della modifica |
||
| Riga 1: | Riga 1: | ||
=Introduzione= | |||
Quando ci si deve connettere molto spesso ad un server (o a molti server) tramite ssh, pu� essere tedioso dover inserire ogni volta la password... | |||
Un modo sicuro per ''aggirare'' questo problema � basato sull'autenticazione tramite una coppia di chiavi (privata e pubblica). | |||
=Come funziona= | |||
=Configurazione= | |||
==Generazione delle chiavi== | |||
Per poter gestire questo processo di autenticazione � necessario generare una coppia di chiavi (pubblica e privata). Il comando � semplice: | |||
<pre> | |||
$ ssh-keygen -t dsa -b 1024 | |||
</pre> | |||
dove '''-b''' rappresenta la lunghezza della chiave e '''-t''' viene usato per indicare il tipo di chiave. I possibili valori sono: | |||
; rsa1 : per la versione 1 del protocollo (altamente sconsigliata) | |||
; rsa o dsa : per al versione 2 del protocollo. | |||
Durante la generazione delle chiavi ci viene chiesto dove salvarle (normalmente � ~/.ssh/id_dsa).. il valore di default va bene! | |||
Per quanto riguarda la passphrase richiesta, sempre durante la generazione delle chiavi, ci sono due opzioni, entrambe con pregi e difetti: | |||
* inserire una passphrase: dal punto di vista della sicurezza, � ottimo... dal punto di vista pratico, per�, si � di fronte al problema che � necessario inserirla ad ogni connessione (nel caso di pi� host, comunque, rappresenterebbe un sistema molto comodo di accesso tramite la stessa ''passphrase'', invece di una password diversa per ogni host) | |||
* inserire una passphrase vuota: dal punto di vista della sicurezza lascia un po' a desiderare, in quanto il furto della chiave permetterebbe l'accesso incondizionato agli host; dal punto di vista pratico, invece, � comodissimo, in quanto slega l'accesso alla macchina remota dalla richiesta di password. | |||
==Copia della chiave pubblica== | |||
La chiave privata, come illustrato nel funzionamento, viene utilizzato dal computer che richiede la connessione (client), mentre quella pubblica deve essere salvata sul computer al quale connettersi (server). | |||
Prendiamo, ad esempio, la seguente chiave pubblica (contenuta nel file ''~/.ssh/id_dsa.pub'' presente sul client): | |||
<pre> | |||
ssh-dss AAAAB3NzaC1kc3MAAACBAPe/PbwWkXR7qI8hcbxLRUS0/fIul0eUiSvu/hnXZXZDIZjVi1VlIbipff6n7Z6vF0hJRg6l | |||
[cut] | |||
gjLLTka0/QF8SP4JYFKs0Iasdju6y1slmx9IdzQt+hvMqF2+PPchCWcyBP3S5Zje4T6Az1MgrvuwCXIW6oUZXCA== user@comp | |||
</pre> | |||
Copiamo il contenuto nel file ''~/.ssh/authorized_keys2`` presente sul server, nella home relativa all'utente usato su quella macchina e salviamo il file. | |||
==Test di funzionamento== | |||
Se tutto � stato eseguito correttamente, sar� possibile connettersi al server tramite un semplice: | |||
<pre> | |||
$ ssh utente@server | |||
</pre> | |||
Se � stata inserita, durante la generazione delle chiavi, una passphrase, sar� necessario usarla per completare il processo di autenticazione, altrimenti apparir� direttamente il prompt della macchina remota. | |||
==Approfondimenti== | |||
* [http://www.debian.org/doc/manuals/reference/ch-tune.it.html#s-ssh La guida Debian: SSH] | |||