Ssh e autenticazione tramite chiavi: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
(da cancellare)
 
(38 versioni intermedie di 13 utenti non mostrate)
Riga 1: Riga 1:
{{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.


Gli '''Hard Disk''' sono una delle parti pi� delicate degli odierni pc, ed infatti sono tra le periferiche che pi� facilmente sono soggette a rompersi.
Un modo sicuro per ''aggirare'' questo problema è basato sull'autenticazione tramite una coppia di chiavi (privata e pubblica).


Fortunantamente ci sono degli strumenti studiati per diagnosticare i malfunzionamenti prima ancora che possano creare danno (speriamo ;-)). Ma ricordate che un backup periodico dei dati importanti � sempre la scelta migliore.
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.


In questa guida vedremo come usare alcuni strumenti come '''smartmontools''' e '''badblocks''' per monitorare lo stato di salute di un hard disk, vedremo come effettuare le basilari operazioni di backup di emergenza e come affrontare un eventuale ripristino dei dati.  
== 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
</pre>
Si può voler scegliere una lunghezza maggiore (default 2048) con
<pre>
$ ssh-keygen -b 4096
</pre>
L'uso dell'opzione <code>'''-t'''</code> per indicare il tipo di chiave è [[OpenSSH#Configurazione_Client|fortemente sconsigliato]].


{{Box|Nota|Questa guida raccoglie le mie (limitate) conoscenze in materia nella speranza che siano utili ad altri. Sentitevi liberi di contribuire con approfondimenti o link ad ulteriori documenti.}}
Durante la generazione delle chiavi ci viene chiesto dove salvarle (normalmente è <code>~/.ssh/id_rsa</code>): il valore di default va bene.


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


Per quanto abbia fatto del mio meglio per verificare l'attendibilit� delle informazioni, non posso garantire in alcun modo che alcune delle tecniche illustrate di seguito non possano danneggire i vostri dati, bruciare la vostra casa o uccidere il vostro gatto.
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>


Faccio notare, inoltre, che il ripristino dei dati da una partizione corrotta � pi� una specie di magia nera che una scienza esatta, e richiede oltre che doti da chiromante anche una buona dose di fortuna. Quindi, e non lo ripeter� pi�, fate backup sistematici dei vostri dati o non lamentatevi se doveste perderli accidentalmente e non riuscire pi� a recuperarli!
=== 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).


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


Gli ''smartmontools'' permettono di usare la funzionalit� [http://en.wikipedia.org/wiki/Self-Monitoring%2C_Analysis_and_Reporting_Technology SMART] di tutti i moderni HD grazie alla quale � possibile prevedere con 24 ore di anticipo la rottura di un HD.
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.


In debian basta installare il pacchetto smartmontools:
=== Copia automatica della chiave pubblica ===
 
Alternativamente, è possibile usare lo script ''ssh-copy-id'' in questo modo dal client:
# aptitude install smartmontools
 
=== Analizzare lo stato dell'HD ===
Possiamo usare l'utility <tt>'''smartctl'''</tt> per analizzare lo stato dell'HD.
 
Innanzi tutto vediamo alcune informazioni generiche sul nostro HD:


<pre>
<pre>
# smartctl -i /dev/hda
$ ssh-copy-id -i ~/.ssh/id_rsa.pub utente@server
smartctl version 5.34 [i686-pc-linux-gnu] Copyright (C) 2002-5 Bruce Allen
</pre>
Home page is http://smartmontools.sourceforge.net/
oppure ancora utilizzando <code>scp</code>:
 
<pre>
=== START OF INFORMATION SECTION ===
$ scp -P <porta> ~/.ssh/id_rsa.pub <username>@<ip del server>:~/.ssh/authorized_keys
Model Family:     Western Digital Caviar family
</pre>
Device Model:    WDC WD600BB-00CAA1
I permessi sulla directory remota <code>~/.ssh</code> devono essere settati a:
Serial Number:    WD-WMA8F1747570
<pre>
Firmware Version: 17.07W17
drwxr-xr-x 2 utente utente 4096 30 dic 00:31 .ssh
User Capacity:    60,022,480,896 bytes
Device is:        In smartctl database [for details use: -P show]
ATA Version is:  5
ATA Standard is: Exact ATA specification draft version not indicated
Local Time is:   Tue Jan 31 17:36:07 2006 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
</pre>
</pre>
 
mentre sul file <code>~/.ssh/authorized_keys</code>:
oltre alle informazioni generiche, dalle ultime due righe si capisce che l'HD supporta la tecnologia SMART e che il supporto � attivato. Se non fosse attivato basterebbe questo comando:
<pre>
<pre>
# smatmontools -s on /dev/hda
-rw-r--r-- 1 utente utente  610 30 dic 00:17 authorized_keys
</pre>
</pre>
per attivare il supporto SMART.
Per controllare lo stato di salute attuale:


== 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 i campi:
<pre>
<pre>
# smartctl -H /dev/hda
HostbasedAuthentication yes
smartctl version 5.34 [i686-pc-linux-gnu] Copyright (C) 2002-5 Bruce Allen
RSAAuthentication yes
Home page is http://smartmontools.sourceforge.net/
PubkeyAuthentication yes
 
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
</pre>
</pre>
 
Riavviate il servizio:
L'ultima riga ci dice che la salute sembra buona e nessuno dei parametri interni controllati da SMART ha superato il livello di guardia.
<pre>
 
# /etc/init.d/ssh restart
{{Warningbox| Se il precendente comando non riporta '''PASSED''' smontate immediatamente tutte le partizioni presenti su quell'HD ed effettuate un backup dei dati: la rottura definitiva ed irreversibile del disco � prevista nelle successive 24 ore!}}
</pre> e verificate di essere in grado di autenticarvi tramite chiave:
 
Per avere tutte le informazioni possibili sul nostro HD diamo:
<pre>
<pre>
# smartmontools -a /dev/hda
$ ssh utente@server
</pre>
</pre>
 
{{Box|Consiglio:|se '''non''' volete permettere il login tramite password, ma solo attraverso public key, settate anche le opzioni:
L'output, abbastanza lungo (-a sta per "all"), � diviso in quattro sezioni. Il primo blocco rappresenta le informazioni generiche sull'HD (le stesse ottenute prima con <tt>-i</tt>), la seconda sezione riporta le informazioni sul supporto SMART. La terza sezione elenca i parametri interni monitorati da SMART e se hanno mai superato il livello di guardia, nel mio caso:
 
<pre>
<pre>
SMART Attributes Data Structure revision number: 16
ChallengeResponseAuthentication no
Vendor Specific SMART Attributes with Thresholds:
PasswordAuthentication no
ID# ATTRIBUTE_NAME          FLAG    VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
UsePAM no
  1 Raw_Read_Error_Rate    0x000b  200  200  051    Pre-fail  Always      -      0
  3 Spin_Up_Time            0x0007  099  091  021    Pre-fail  Always      -      4108
  4 Start_Stop_Count        0x0032  098  098  040    Old_age  Always      -      2590
  5 Reallocated_Sector_Ct  0x0033  200  200  140    Pre-fail  Always      -      0
  7 Seek_Error_Rate        0x000b  200  200  051    Pre-fail  Always      -      0
  9 Power_On_Hours          0x0032  092  092  000    Old_age  Always      -      6494
10 Spin_Retry_Count        0x0013  100  100  051    Pre-fail  Always      -      0
11 Calibration_Retry_Count 0x0013  100  100  051    Pre-fail  Always      -      0
12 Power_Cycle_Count      0x0032  098  098  000    Old_age  Always      -      2435
196 Reallocated_Event_Count 0x0032  200  200  000    Old_age  Always      -      0
197 Current_Pending_Sector  0x0012  200  200  000    Old_age  Always      -      0
198 Offline_Uncorrectable  0x0012  200  200  000    Old_age  Always      -      0
199 UDMA_CRC_Error_Count    0x000a  200  200  000    Old_age  Always      -      19
200 Multi_Zone_Error_Rate  0x0009  200  200  051    Pre-fail  Offline      -      0
</pre>
</pre>
Da non usare se avete utilizzato una passphrase nella generazione della chiave.}}


I parametri indicati come ''Pre-fail'' sono quelli che superano la soglia di guardia nelle 24 ore che precedono la rottura dell'HD, mentre quelli ''Old_age'' sono i parametri che superano la soglia di guardia quando ormai l'HD � vecchio e non � considerato pi� affidabile dal costruttore. Nel mio esempio si vede che nessun parametro ha mai superato la soglia di guardia.
'''Attenzione''': in caso di autenticazione tramite chiavi, nel file di configurazione del server non va utilizzata la direttiva <code>AllowUsers</code>.


L'ultima sezione del comando <tt>smartctl -a /dev/hda</tt> riguarda il log dei test manualmente effettuati sull'HD:
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:
<pre>
<pre>
SMART Error Log Version: 1
$ ssh utente@server
No Errors Logged
 
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline      Completed without error      00%      952        -
# 2  Conveyance offline  Completed without error      00%      951        -
# 3  Short offline      Completed without error      00%      951        -
# 4  Short offline      Completed without error      00%      875        -
</pre>
</pre>


Nell'esempio si pu� vedere che sono stati effettuati 4 test, di cui tre di tipo ''short'' e uno di tipo ''conveyance''. Nessuno di loro ha dato esito positivo (cio� non sono stati rilevati malfunzionamenti).
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.
 
=== Effettuare manualmente i test ===
 
E' possibile effettuare dei test pi� o meno approfonditi sul disco. Alcuni test si possono effettuare con l'HD montato e funzionate, ed il test stesso avr� un impatto minimo o nullo sulle prestazioni del sistema.
 
Per effettuare un test:
 
# smartctl -t tipo_test /dev/hda
 
dove ''<tt>tipo_test</tt>'' pu� essere:
 
;<tt>short</tt>: effettua un test sul disco di durata inferiore a 10 minuti, pu� essere eseguito durante il normale funzionamento e non impatta le prestazioni. Questo test controlla le performace meccaniche ed elettriche del disco, oltre che le performance in lettura.
 
;<tt>long</tt>: effettua un test di durata da 40 minuti ad un ora (a seconda del disco). Pu� essere effettuato durante il normale funzionamento del disco e non ha impatto sulle prestazioni. Questo test � una versione pi� estesa dello ''short test''.
 
;<tt>conveyance</tt>: effettua un test di alcuni minuti atto a scoprire difetti dovuti ad incurie nel trasporto dell'HD. Pu� essere eseguito durante il normale funzionamento dell'HD.
 
Esistono anche altri tipi di test per i quali si rimanda alla simpatica pagina di manuale: '''<tt>man smartctl</tt>'''.
 
I risultati di questi test vengono riportati nella parte finale dell'output di <code>smartctl -a /dev/hda</code>, come notato in precedenza.
 
=== Controllo automatizzato ===
 
E' possibile attivare il demone '''<tt>smartd</tt>''' fornito dal pacchetto <tt>smartmontools</tt> per monitorare in continuazione lo stato di salute dell'HD e notificare ogni anomalia immediatamente tramite syslog.
 
Normalmente il demone � disabilitato. Per abilitarlo bisogna editare il file <tt>/etc/default/smartmontools</tt> e decommentare la riga:
 
start_smartd=yes
 
Dobbiamo inoltre configurare smartd per deciderne il suo comportamento. A tal scopo editiamo il file <tt>/etc/smartd.conf</tt>. Leggendo i commenti nel file e l'amichevole pagina di manuale (<tt>man smartd.conf</tt>) � possibile scegliere quali parametri <tt>smartd</tt> debba monitorare, programmare dei test automatici, e decidere quali azioni intraprendere in caso di errore.
 
Nel mio caso ho inserito solo la seguente linea:
 
/dev/hda -a -o on -S on
 
che attiva il monitoraggio di tutti (<tt>-a</tt>) i parametri, abilitia l' ''automatic online data collection'' (<tt>-o on</tt>), e abilita il salvataggio degli attributi (<tt>-S on</tt>) in modo che le informazioni di log di SMART vengano memorizzare nella FLASH del disco e siano disponibili anche dopo il riavvio.
 
== Verifica di settori corrotti ==
 
L'utility <tt>'''badblocks'''</tt> permette di fare un controllo di basso livello per vedere se su una partizione sono presenti dei settori danneggiati.
 
I moderni HD IDE fanno un controllo automatico degli errori e sono in grado di segnare dei settori corrotti che di conseguenza non verranno pi� usati. Questo rende in parte inutile <tt>badblocks</tt>, ma se si effettua un controllo e dei settori risultano danneggiati vuol dire che probabilmente la superficie del disco contiene cos� tanti settori danneggiati che la circuiteria di controllo non � pi� in gradio di gestirli.
 
Per effettuare un controllo con <tt>badblocks</tt> smontiamo la partizione ed eseguiamo:
 
# badblocks -b dimensione_blocco /dev/hdaX
 
dove <tt>/dev/hdaX</tt> � la partizione da controllare. Il parametro <tt>dimensione_blocco</tt> � la dimensione del blocco usata dal filesytem espresso in byte. Di solito � 4096 (ovvero 4KB), per controllare potete usare:
 
# disktype /dev/hda
 
Per le ulteriori opzioni di <tt>badblocks</tt> si rimanda all'amichevole pagina di manuale, ma '''attenzione: l'opzione <tt>-w</tt> distrugger� tutti i dati sulla vostra partizione'''. Non usatela se non volete che ci� accada.
 
Se trovate dei settori danneggiati conviene cambiare immediatamente HD. Sebbene ci sia una piccola probabilit� che l'errore sia isolato (dovuto ad esempio ad uno sbalzo di tensione) � molto pi� probabile che l'HD si stia progressivamente danneggiando e presto ci saranno dei nuovi settori danneggiati. Comunque se volete giocare alla roulette russa con i vostri dati siete liberi di farlo :-P.
 
== Backup di emergenza ==
 
Per effettuare un backup di emergenza di una partizione corrotta il tool pi� efficace � '''[http://www.gnu.org/software/ddrescue/ddrescue.html GNU ddrescue]''' (da non confondere con il simile ma meno potente <tt>[http://www.garloff.de/kurt/linux/ddrescue/ dd_rescue]</tt>). Per installare GNU ddrescue in debian basta installare il pacchetto <tt>gddrescue</tt>.
 
GNU ddrescue pu� effettuare backup di singoli file o di intere partizioni, riconoscendo ed aggirando i settori danneggiati. Pu� essere interrotto in qualsiasi momento, riprendere la copia da punto in cui � stato interrrotto e pu� fare il ''merge'' dei file se si hanno pi� copie degli stessi file corrotti.
 
Il suo uso � vagamente simile al classico '''<tt>dd</tt>''':
 
# ddrescue ddrescue [OPTIONS] INFILE OUTFILE [LOGFILE]
 
Per una lista completa delle opzioni si rimanda al manuale: <tt>info ddrescue</tt>.
 
Riporto un semplice esempio di utilizzo:
 
# ddrescue -r3 /dev/hda3 /dev/hdb2 logfile
 
il precedente comando copier� la partizione hda3 in hdb2 (distruggengo gli eventuali dati ivi presenti) provando a leggere tre volte i settori danneggiati e usando <tt>logfile</tt> come file di log.
 
Ora possiamo eseguire sulla copia i normali tool di ripristino del nostro filesystem (<tt>fsck.*</tt>).
 
== Strumenti per il ripristino dei dati ==
''In questa sezione verr� accennato il problema del ripristino dati. Lo scopo � solo quello di dare una panoramica iniziale del problema che possa servire come orientamento per ulteriori approfondimenti''.
 
Prima di ogni operazione di ripristino dati � fortemente consigliato effettuare una copia della partizione (vedi sezione precedednte) e operare sulla copia.
 
La metodologia per il ripristino dei dati pu� variare a seconda del filesytem utilizzato e del modo in cui si sono perduti i dati. Ad esempio se si vogliono recuperare dei file cancellati accidentalmente da una partizione ext2 ci sono delle buone possibilit� di usare il tool <tt>[http://recover.sourceforge.net/linux/recover/ recover]</tt> (presente nell'omonimo pacchetto debian). Il tool <tt>recover</tt> non pu� essere usato su partizione ext3. Purtroppo, oltre a <tt>recover</tt> per ext2, non conosco nessun altro tool free e automatico per il recupero dei file accidentalmente cancellati.
 
In mancanza di strumenti automatici si usa la cos� detta ''Unix Way''. Ovvero si usano i tradizionali strumenti unix per accedere direttamente al device ed estrarre i dati utili. Ad esempio se si devono recuperare file di testo o documenti non binari (per intenderci non foto o musica o programmi compilati) si possono usare <tt>egrep</tt> e <tt>strings</tt>.
 
Se si vogliono recuperare foto jpeg � possibile usare <tt>'''recoverjpeg'''</tt> (presente nell'omonimo pacchetto debian) che cerca di identificare gli header jpeg in una immagine di file system.
 
E' fortemente consigliata la lettura dei documenti elencati di seguito nella sezione ''Links->Articoli'' per degli esempi pratici sul recupero dati da filesystem ext2 e reiserfs (ma le informazioni possono servire da spunto per operare anche su altri file system).
 
== Links ==
=== Articoli ===
* [http://www.linuxquestions.org/linux/answers/Hardware/ReiserFS_Data_Recovery_Tips ReiserFS Data Recovery Tips]
 
* [http://ildp.pluto.it/HOWTO/Ext2fs-Undeletion.html Linux Ext2fs Undeletion mini-HOWTO]
* [http://www.linuxjournal.com/article/8366 How a Corrupted USB Drive Was Saved by GNU/Linux]
 
=== Strumenti Utili ===
* [http://smartmontools.sourceforge.net/ smartmontools Home Page]
* [http://www.gnu.org/software/ddrescue/ddrescue.html GNU ddrescue]
* [http://www.partimage.org/index.en.html Partimage]
* [http://www.cgsecurity.org/index.html?testdisk.html TestDisk]
 


----
== Approfondimenti ==
* [http://www.debian.org/doc/manuals/reference/ch06.it.html#_the_remote_access_server_and_utility_ssh La guida Debian: SSH]


Autore Iniziale: [[Utente:TheNoise|~ The Noise]] 05:31, Feb 4, 2006 (EST)
[[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

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