Ssh e autenticazione tramite chiavi: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
mNessun oggetto della modifica
mNessun oggetto della modifica
Riga 1: Riga 1:
=Introduzione=
=Introduzione=
Spesso pu� essere necessario lavorare direttamente su un filesystem remoto (si pensi, ad esempio, alla webroot di un sito, alla home del proprio portatile, ...).
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...


sshfs permette di superare questo problema in un modo semplice e pulito: montando una directory tramite il protocollo ssh.
Un modo sicuro per ''aggirare'' questo problema è basato sull'autenticazione tramite una coppia di chiavi (privata e pubblica).


=Installazione=
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.
Il pacchetto sshfs � gi� presente in Debian, quindi l'installazione si riduce ad un semplice
<pre>
# apt-get install sshfs
</pre>
 
Per quanto riguarda il kernel, normalmente � presente il modulo ''fuse''. Se non � presente � necessaria la ricompilazione del kernel.
Il modulo da attivare si trova in: ''File systems  --->  Filesystem in Userspace support''


=Configurazione=
=Configurazione=
==Creazione del punto di mount==
==Generazione delle chiavi==
Prima di tutto � necessario creare un [[mountpoint | punto di montaggio]] in cui montare la risorsa di rete (ovviamente ognuno � liberissimo di utilizzare la directory che vuole):
Per poter gestire questo processo di autenticazione è necessario generare una coppia di chiavi (pubblica e privata). Il comando è semplice:
<pre>
<pre>
# mkdir /mnt/sshdir
$ ssh-keygen -t dsa -b 1024
</pre>
� necessario, inoltre, impostare l'utente che utilizzer� questa directory come ''[[owner]]'':
<pre>
# chown username /mnt/sshdir
</pre>
</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!


==Permessi utenti==
Per quanto riguarda la passphrase richiesta, sempre durante la generazione delle chiavi, ci sono due opzioni, entrambe con pregi e difetti:
� possibile permettere l'utilizzo di sshfs anche agli utenti normali, seguendo i seguenti passaggi:
* 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)
<pre>
* 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.
# chgrp fuse /usr/bin/fusermount
# chmod u+s /usr/bin/fusermount
# adduser nomeutente fuse
</pre>
in questo modo permettiamo l'utilizzo del comando ''fusermount'' agli utenti appartenenti al gruppo ''fuse'', e aggiungiamo l'utente che utilizzer� sshfs al gruppo fuse.


Per rendere effettiva l'aggiunta al gruppo � necessario effettuare un logout-login.
==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).


=Utilizzo e Test=
Prendiamo, ad esempio, la seguente chiave pubblica (contenuta nel file ''~/.ssh/id_dsa.pub'' presente sul client):
L'utilizzo � semplice:
<pre>
<pre>
$ sshfs user@host:/dir/to/mount /mnt/sshdir
ssh-dss AAAAB3NzaC1kc3MAAACBAPe/PbwWkXR7qI8hcbxLRUS0/fIul0eUiSvu/hnXZXZDIZjVi1VlIbipff6n7Z6vF0hJRg6l
[cut]
gjLLTka0/QF8SP4JYFKs0Iasdju6y1slmx9IdzQt+hvMqF2+PPchCWcyBP3S5Zje4T6Az1MgrvuwCXIW6oUZXCA== user@comp
</pre>
</pre>
dove
; user : l'utente della macchine remota (se omesso verr utilizzato l'username dell'utente che lancia il comando (root, in questo caso)
; host : l'indirizzo ip o l'url a cui la macchina remota risponde
; /dir/to/mount : il percorso assoluto della directory da montare... ( possibile anche utilizzare un percordo relativo a partire dalla directory home dell'utente: ''./path/to/dir'')
; /mnt/sshdir : rappresenta il punto di mount


per controllare la riuscita del comando, si pu� analizzare l'output del comando <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.
$ mount
</pre>


 
==Test di funzionamento==
Per quanto riguarda lo smontaggio (umounting) il comando � il seguente:
Se tutto è stato eseguito correttamente, sarà possibile connettersi al server tramite un semplice:
<pre>
<pre>
$ fusermount -u /mnt/sshdir
$ ssh utente@server
</pre>
</pre>


=Faq ed Errori Frequenti=
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.
==failed to open /dev/fuse: No such file or directory==
L'errore � dovuto alla mancanza del modulo del kernel relativo a ''fusefs''. � necessario compilarlo come modulo o staticamente (nei kernel pacchettizzati Debian � presente, ed � caricabile con un <pre>
# modprobe fuse
</pre>


==mountpoint is not empty==
==Approfondimenti==
Se si cerca di montare una risorsa in un [[mountpoint]] contenente gi� dei file, pu� apparire il seguente errore:
* [http://www.debian.org/doc/manuals/reference/ch-tune.it.html#s-ssh La guida Debian: SSH]
<pre>fusermount: mountpoint is not empty
[[Categoria:Networking]][[Categoria:Sicurezza]]
fusermount: if you are sure this is safe, use the 'nonempty' mount option</pre>
Le soluzioni sono:
* usare un mountpoint libero (consigliata)
* appendere, dopo il comando ''sshfs'' l'opzione ''-o nonempty''

Versione delle 21:15, 1 apr 2006

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

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

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: 

$ 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

Estratto da "https://guide.debianizzati.org/index.php?title=Ssh_e_autenticazione_tramite_chiavi&oldid=7546"