Ssh e autenticazione tramite chiavi: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
(da cancellare)
 
(11 versioni intermedie di 5 utenti non mostrate)
Riga 1: Riga 1:
{{Versioni compatibili}}
{{Da cancellare | guida doppione perché il contenuto è già coperto nella guida principale su [[SSH]]}}
== 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.
Riga 11: Riga 11:
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  
</pre>
</pre>
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:
Si può voler scegliere una lunghezza maggiore (default 2048) con
; <code>rsa1</code>: per la versione 1 del protocollo (altamente sconsigliata);
<pre>
; <code>rsa</code> o <code>dsa</code>: per la versione 2 del protocollo.
$ ssh-keygen -b 4096
</pre>
L'uso dell'opzione <code>'''-t'''</code> per indicare il tipo di chiave è [[OpenSSH#Configurazione_Client|fortemente sconsigliato]].


Durante la generazione delle chiavi ci viene chiesto dove salvarle (normalmente è <code>~/.ssh/id_dsa</code>): il valore di default va bene
Durante la generazione delle chiavi ci viene chiesto dove salvarle (normalmente è <code>~/.ssh/id_rsa</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; 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: 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.
In realtà questo discorso può valere in caso di utilizzo non interattivo come ad esempio in uno script, negli altri casi si può ricorrere a <code>ssh-agent</code> per mantenere in cache la passphrase per la sessione corrente:
<pre>
$ ssh-add ~/.ssh/id_rsa
</pre>


=== 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).


Prendiamo, ad esempio, la seguente chiave pubblica (contenuta nel file <code>~/.ssh/id_dsa.pub</code> presente sul client):
Prendiamo, ad esempio, la seguente chiave pubblica (contenuta nel file <code>~/.ssh/id_rsa.pub</code> presente sul client):
<pre>
<pre>
ssh-dss AAAAB3NzaC1kc3MAAACBAPe/PbwWkXR7qI8hcbxLRUS0/fIul0eUiSvu/hnXZXZDIZjVi1VlIbipff6n7Z6vF0hJRg6l
ssh-rsa AAAAB3NzaC1kc3MAAACBAPe/PbwWkXR7qI8hcbxLRUS0/fIul0eUiSvu/hnXZXZDIZjVi1VlIbipff6n7Z6vF0hJRg6l
[cut]
[cut]
gjLLTka0/QF8SP4JYFKs0Iasdju6y1slmx9IdzQt+hvMqF2+PPchCWcyBP3S5Zje4T6Az1MgrvuwCXIW6oUZXCA== user@comp
gjLLTka0/QF8SP4JYFKs0Iasdju6y1slmx9IdzQt+hvMqF2+PPchCWcyBP3S5Zje4T6Az1MgrvuwCXIW6oUZXCA== user@host
</pre>
</pre>


Riga 39: Riga 46:


<pre>
<pre>
$ ssh-copy-id -i ~/.ssh/id_dsa.pub utente@server
$ ssh-copy-id -i ~/.ssh/id_rsa.pub utente@server
</pre>
</pre>
oppure ancora utilizzando <code>scp</code>:
oppure ancora utilizzando <code>scp</code>:
<pre>
<pre>
$ scp -P <porta> ~/.ssh/id_dsa.pub <username>@<ip del server>:~/.ssh/authorized_keys
$ scp -P <porta> ~/.ssh/id_rsa.pub <username>@<ip del server>:~/.ssh/authorized_keys
</pre>
I permessi sulla directory remota <code>~/.ssh</code> devono essere settati a:
<pre>
drwxr-xr-x 2 utente utente  4096 30 dic 00:31 .ssh
</pre>
mentre sul file <code>~/.ssh/authorized_keys</code>:
<pre>
-rw-r--r-- 1 utente utente  610 30 dic 00:17 authorized_keys
</pre>
</pre>


== Configurazione del server ==
== Configurazione del server ==
Sul server, in cui deve essere già presente un'installazione di base funzionante di SSH, aggiornate il file <code>/etc/ssh/sshd_config</code> e settate il campo <code>''HostbasedAuthentication''</code> a <code>''yes''</code> (solo per SSH2).
Sul server, in cui deve essere già presente un'installazione di base funzionante di SSH, aggiornate il file <code>/etc/ssh/sshd_config</code> e settate i campi:
 
<pre>
{{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.}}
HostbasedAuthentication yes
RSAAuthentication yes
PubkeyAuthentication yes
</pre>
Riavviate il servizio:
<pre>
# /etc/init.d/ssh restart
</pre> e verificate di essere in grado di autenticarvi tramite chiave:
<pre>
$ ssh utente@server
</pre>
{{Box|Consiglio:|se '''non''' volete permettere il login tramite password, ma solo attraverso public key, settate anche le opzioni:
<pre>
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no
</pre>
Da non usare se avete utilizzato una passphrase nella generazione della chiave.}}


'''Attenzione''': in caso di autenticazione tramite chiavi, nel file di configurazione del server non va utilizzata la direttiva <code>AllowUsers</code>.
'''Attenzione''': in caso di autenticazione tramite chiavi, nel file di configurazione del server non va utilizzata la direttiva <code>AllowUsers</code>.


Per un'installazione di base di SSH si veda ad esempio la guida [[OpenSSH: configurazione di base]].
Per un'installazione di base di SSH si veda ad esempio la guida [[OpenSSH: file di configurazione]].


== Test di funzionamento ==
== Test di funzionamento ==
Riga 64: Riga 96:


== 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/ch06.it.html#_the_remote_access_server_and_utility_ssh La guida Debian: SSH]
[[Categoria:Crittografia]]
 
[[Categoria:SSH server e amministrazione remota]]

Versione attuale delle 11:06, 26 set 2015

Trash 01.png Attenzione. Questa guida è stata proposta per la cancellazione in quanto contenente materiale potenzialmente dannoso, inutile o fuorviante.
Motivo: guida doppione perché il contenuto è già coperto nella guida principale su SSH


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 

Si può voler scegliere una lunghezza maggiore (default 2048) con

$ ssh-keygen -b 4096

L'uso dell'opzione -t per indicare il tipo di chiave è fortemente sconsigliato.

Durante la generazione delle chiavi ci viene chiesto dove salvarle (normalmente è ~/.ssh/id_rsa): 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.

In realtà questo discorso può valere in caso di utilizzo non interattivo come ad esempio in uno script, negli altri casi si può ricorrere a ssh-agent per mantenere in cache la passphrase per la sessione corrente:

$ ssh-add ~/.ssh/id_rsa

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_rsa.pub presente sul client):

ssh-rsa AAAAB3NzaC1kc3MAAACBAPe/PbwWkXR7qI8hcbxLRUS0/fIul0eUiSvu/hnXZXZDIZjVi1VlIbipff6n7Z6vF0hJRg6l
[cut]
gjLLTka0/QF8SP4JYFKs0Iasdju6y1slmx9IdzQt+hvMqF2+PPchCWcyBP3S5Zje4T6Az1MgrvuwCXIW6oUZXCA== user@host

Copiamo il contenuto nel file ~/.ssh/authorized_keys presente sul server, nella home relativa all'utente usato su quella macchina e salviamo il file.

Copia automatica della chiave pubblica

Alternativamente, è possibile usare lo script ssh-copy-id in questo modo dal client:

$ ssh-copy-id -i ~/.ssh/id_rsa.pub utente@server

oppure ancora utilizzando scp:

$ scp -P <porta> ~/.ssh/id_rsa.pub <username>@<ip del server>:~/.ssh/authorized_keys

I permessi sulla directory remota ~/.ssh devono essere settati a:

drwxr-xr-x 2 utente utente  4096 30 dic 00:31 .ssh

mentre sul file ~/.ssh/authorized_keys:

-rw-r--r-- 1 utente utente  610 30 dic 00:17 authorized_keys

Configurazione del server

Sul server, in cui deve essere già presente un'installazione di base funzionante di SSH, aggiornate il file /etc/ssh/sshd_config e settate i campi:

HostbasedAuthentication yes
RSAAuthentication yes
PubkeyAuthentication yes

Riavviate il servizio:

# /etc/init.d/ssh restart

e verificate di essere in grado di autenticarvi tramite chiave:

$ ssh utente@server
Info.png Consiglio:
se non volete permettere il login tramite password, ma solo attraverso public key, settate anche le opzioni:
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Da non usare se avete utilizzato una passphrase nella generazione della chiave.


Attenzione: in caso di autenticazione tramite chiavi, nel file di configurazione del server non va utilizzata la direttiva AllowUsers.

Per un'installazione di base di SSH si veda ad esempio la guida OpenSSH: file di configurazione.

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.

Approfondimenti