Ssh e autenticazione tramite chiavi: differenze tra le versioni
Vai alla navigazione
Vai alla ricerca
S3v (discussione | contributi) Nessun oggetto della modifica |
(modificata gerarchia titoli, revisionata) |
||
| Riga 1: | Riga 1: | ||
{{Versioni compatibili|Tutte le versioni di Debian|}} | {{Versioni compatibili|Tutte le versioni di Debian|}} | ||
=Introduzione= | == 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 | 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). | Un modo sicuro per ''aggirare'' questo problema è basato sull'autenticazione tramite una coppia di chiavi (privata e pubblica). | ||
Il concetto alla base di questo sistema di autenticazione è semplice: si demanda il compito di verificare i dati di autenticazione direttamente alle chiavi ssh, rimuovendo la richiesta della password (meno volte viene digitata, più è difficile che qualche utente male intenzionato la riesca a capire | Il concetto alla base di questo sistema di autenticazione è semplice: si demanda il compito di verificare i dati di autenticazione direttamente alle chiavi ssh, rimuovendo la richiesta della password (meno volte viene digitata, più è difficile che qualche utente male intenzionato la riesca a capire) che viene, eventualmente, sostituita dalla richiesta di una passphrase di sblocco della chiave. | ||
=Configurazione= | == Configurazione == | ||
==Generazione delle chiavi== | === Generazione delle chiavi === | ||
Per poter gestire questo processo di autenticazione è necessario generare una coppia di chiavi (pubblica e privata). Il comando è semplice: | Per poter gestire questo processo di autenticazione è necessario generare una coppia di chiavi (pubblica e privata). Il comando è semplice: | ||
<pre> | <pre> | ||
$ ssh-keygen -t dsa -b 1024 | $ ssh-keygen -t dsa -b 1024 | ||
</pre> | </pre> | ||
dove '''-b''' rappresenta la lunghezza della chiave e '''-t''' viene usato per indicare il tipo di chiave. I possibili valori sono: | dove <code>'''-b'''</code> rappresenta la lunghezza della chiave e <code>'''-t'''</code> viene usato per indicare il tipo di chiave. I possibili valori sono: | ||
; rsa1 : per la versione 1 del protocollo (altamente sconsigliata) | ; <code>rsa1</code>: per la versione 1 del protocollo (altamente sconsigliata); | ||
; rsa o dsa : per | ; <code>rsa</code> o <code>dsa</code>: per la versione 2 del protocollo. | ||
Durante la generazione delle chiavi ci viene chiesto dove salvarle (normalmente è <code>~/.ssh/id_dsa</code>) | Durante la generazione delle chiavi ci viene chiesto dove salvarle (normalmente è <code>~/.ssh/id_dsa</code>): 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: | 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 | * 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. | * 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 manuale della chiave pubblica== | === Copia manuale 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). | 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). | ||
| Riga 35: | Riga 35: | ||
Copiamo il contenuto nel file <code>~/.ssh/authorized_keys</code> presente sul server, nella home relativa all'utente usato su quella macchina e salviamo il file. | Copiamo il contenuto nel file <code>~/.ssh/authorized_keys</code> presente sul server, nella home relativa all'utente usato su quella macchina e salviamo il file. | ||
Aggiornate il file <code>/etc/ssh/sshd_config</code> e settate il campo ''HostbasedAuthentication'' a ''yes'' | Aggiornate il file <code>/etc/ssh/sshd_config</code> e settate il campo <code>''HostbasedAuthentication''</code> a <code>''yes''</code> (solo per SSH2). | ||
{{Box|Consiglio:|se '''non''' volete permettere il login tramite password, ma solo attraverso public key, settate l'opzione <code>''PasswordAuthentication''</code> a <code>''no''</code>. Da non usare se avete utilizzato una passphrase nella generazione della chiave.}} | |||
==Copia automatica della chiave pubblica== | === Copia automatica della chiave pubblica === | ||
Alternativamente, è possibile usare lo script ''ssh-copy-id'' in questo modo dal client: | Alternativamente, è possibile usare lo script ''ssh-copy-id'' in questo modo dal client: | ||
| Riga 46: | Riga 46: | ||
</pre> | </pre> | ||
=Test di funzionamento= | == Test di funzionamento == | ||
Se tutto è stato eseguito correttamente, sarà possibile connettersi al server tramite un semplice: | Se tutto è stato eseguito correttamente, sarà possibile connettersi al server tramite un semplice: | ||
<pre> | <pre> | ||
| Riga 54: | Riga 54: | ||
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. | 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= | == Approfondimenti == | ||
* [http://www.debian.org/doc/manuals/reference/ch-tune.it.html#s-ssh La guida Debian: SSH] | * [http://www.debian.org/doc/manuals/reference/ch-tune.it.html#s-ssh La guida Debian: SSH] | ||
[[Categoria:Networking]][[Categoria:Sicurezza]] | [[Categoria:Networking]][[Categoria:Sicurezza]] | ||
Versione delle 14:21, 6 feb 2010
 Versioni Compatibili ERRORE: valore non valido ( Tutte le versioni di Debian )! Vedi qui. |
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).
Il concetto alla base di questo sistema di autenticazione è semplice: si demanda il compito di verificare i dati di autenticazione direttamente alle chiavi ssh, rimuovendo la richiesta della password (meno volte viene digitata, più è difficile che qualche utente male intenzionato la riesca a capire) che viene, eventualmente, sostituita dalla richiesta di una passphrase di sblocco della chiave.
Configurazione
Generazione delle chiavi
Per poter gestire questo processo di autenticazione è necessario generare una coppia di chiavi (pubblica e privata). Il comando è semplice:
$ ssh-keygen -t dsa -b 1024
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);
rsaodsa- per la 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 manuale 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):
ssh-dss AAAAB3NzaC1kc3MAAACBAPe/PbwWkXR7qI8hcbxLRUS0/fIul0eUiSvu/hnXZXZDIZjVi1VlIbipff6n7Z6vF0hJRg6l [cut] gjLLTka0/QF8SP4JYFKs0Iasdju6y1slmx9IdzQt+hvMqF2+PPchCWcyBP3S5Zje4T6Az1MgrvuwCXIW6oUZXCA== user@comp
Copiamo il contenuto nel file ~/.ssh/authorized_keys presente sul server, nella home relativa all'utente usato su quella macchina e salviamo il file.
Aggiornate il file /etc/ssh/sshd_config e settate il campo HostbasedAuthentication a yes (solo per SSH2).
|
Consiglio: se non volete permettere il login tramite password, ma solo attraverso public key, settate l'opzione PasswordAuthentication a no. Da non usare se avete utilizzato una passphrase nella generazione della chiave.
|
Copia automatica della chiave pubblica
Alternativamente, è possibile usare lo script ssh-copy-id in questo modo dal client:
$ ssh-copy-id -i ~/.ssh/id_dsa.pub utente@server
Test di funzionamento
Se tutto è stato eseguito correttamente, sarà possibile connettersi al server tramite un semplice:
$ ssh utente@server
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.