[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]


229. Secure Shell

Secure Shell è un sistema per l'accesso remoto «sicuro», che si sostituisce a quello tradizionale dei programmi come `rlogin' e `telnet'.

Secure Shell consente di utilizzare diversi livelli di sicurezza, in cui il minimo in assoluto è rappresentato dalla cifratura della comunicazione, e si estende a vari metodi di riconoscimento reciproco da parte dei nodi che si mettono in comunicazione.

In questo capitolo vengono mostrate solo le caratteristiche più importanti e l'utilizzo più comune.

229.1 Aspetti legali

Secure Shell non è precisamente «software libero», e il suo utilizzo ha delle ripercussioni legali che variano da paese a paese. All'interno delle FAQ su Secure Shell http://www.cs.hut.fi/ssh/, si legge il brano seguente, intitolato: May I legally run ssh?

The UNIX version of ssh 1.2.20 may be used and distributed freely, but must not be sold commercially as a separate product, as part of a bigger product or project, or otherwise used for financial gain without a separate license.

Earlier versions of ssh had a less restrictive license; see the file COPYING in the accompanying source distributions.

Tatu Ylönen's MS-Windows version of ssh is a commercial product, which requires licensing.

In some countries, particularly France, Russia, Iraq, and Pakistan, it may be illegal to use any encryption at all without a special permit.

If you are in the United States, you should be aware that, while ssh was written outside the United States using information publicly available everywhere, the US Government may consider it a criminal offence to export this software from the US once it has been imported, including putting it on a ftp site. Contact the Office of Defence Trade Controls if you need more information.

The algorithms RSA and IDEA, which are used by ssh, are claimed as patented in different countries, including the US. Linking against the RSAREF library, which is possible, may or may not make it legal to use ssh for non-commercial purposes in the US. You may need to obtain licenses for commercial use of IDEA; ssh can be configured to work without it. Ssh works perfectly fine without IDEA, however.

For more detail, refer to the file COPYING in the ssh source distribution.

For information on software patents in general, see the Leauge for Programming Freedom's homepage at http://lpf.org/.

Per quanto riguarda le versioni commerciali, sempre all'interno delle FAQ, si legge il brano seguente intitolato: What about commercial use of ssh?

Ssh has been freely available in the Unix environment, and almost certainly will remain to be so in future.

Tatu Ylönen, the original author of ssh, has started a company, SSH Communications Security Oy, that will provide commercial support and licenses for ssh. This company is working together with Data Fellows, who are the sole contact for licensing ssh. More information can be found at http://www.europe.datafellows.com/ and http://www.ssh.fi/.

229.2 Principio di funzionamento

Secure Shell può instaurare un collegamento tra due elaboratori utilizzando diverse modalità, come accennato, in cui l'unica costante comune è la cifratura della comunicazione.

Semplificando molto le cose, da una parte si trova il servente che offre l'accesso e mette a disposizione una chiave pubblica, attraverso la quale i clienti dovrebbero poter verificare l'autenticità del servente a cui si connettono. Appena si verifica la connessione, prima ancora che sia stata stabilita l'identità dell'utente, cliente e servente concordano un sistema di cifratura.

229.2.1 Autenticazione RHOST

Secure Shell consente ancora, se lo si desidera, di utilizzare il vecchio meccanismo dell'autenticazione attraverso i file `/etc/hosts.equiv' e `~/.rhosts', che in pratica sono quelli utilizzati da `rlogin' e `rsh'.

Attraverso questi file, o un'altra coppia analoga per non interferire con `rlogin' e `rsh', si può stabilire semplicemente quali clienti e quali utenti possono accedere senza che venga richiesta loro la password.

229.2.2 Autenticazione RHOST+RSA

Per migliorare lo stato di debolezza causato da un sistema che accetta di autenticare i clienti e gli utenti esclusivamente in base alla configurazione di `/etc/hosts.equiv' e `~/.rhosts' (o simili), si può aggiungere la verifica della chiave pubblica del cliente.

In pratica, se il cliente dispone di una sua chiave pubblica può dimostrare al servente la sua identità.

229.2.3 Autenticazione RSA

A fianco dei metodi di autenticazione derivati da `rlogin' si aggiunge il metodo RSA, attraverso cui, ogni utente che intende utilizzarlo deve creare una propria chiave RSA, e nel proprio profilo personale nel servente deve indicare la parte pubblica di questa chiave. Quando l'utente tenta di accedere in questo modo, le chiavi vengono confrontate, e la corrispondenza è sufficiente a concedere l'accesso senza altre formalità.

Quando si utilizza questo tipo di autenticazione, la parte privata della chiave generata dall'utente, viene cifrata generalmente attraverso una password. In questo modo, prima di ottenere l'autenticazione, l'utente deve anche fornire questa password. *1*

229.2.4 Autenticazione attraverso la password tradizionale

Quando tutti gli altri tipi di autenticazione falliscono, Secure Shell verifica l'identità dell'utente attraverso la password relativa all'accesso normale presso quel sistema.

In pratica, questa forma di autenticazione è quella più comune, che permette l'utilizzo di Secure Shell senza alcuna configurazione (a parte la generazione della chiave del nodo). Infatti, Secure Shell garantisce che la password viaggi cifrata, e questo è già un grande risultato per la sicurezza dei sistemi coinvolti.

229.3 Chiave privata e chiave pubblica

Secure Shell richiede la creazione di una o più chiavi attraverso il programma `ssh-keygen'. Per la precisione è necessario creare la coppia `/etc/ssh/ssh_host_key' e `/etc/ssh/ssh_host_key.pub' nel servente, dove in particolare, la chiave privata (il primo dei due file) non deve avere password.

Eventualmente è necessario creare la stessa coppia di file (trattandosi però di una chiave differente) anche nei clienti che intendono sfruttare un'autenticazione RHOST+RSA, anche in questo caso, senza password.

Infine, ogni utente che vuole utilizzare un'autenticazione RSA pura e semplice deve generare la propria chiave creando i file `~/.ssh/identity' e `~/.ssh/identity.pub', questa volta però, possibilmente con password.

229.3.1 $ ssh-keygen

ssh-keygen [<opzioni>]

`ssh-keygen' permette di generare e modificare una chiave di autenticazione RSA per l'uso con Secure Shell. La chiave in questione si compone di due file: uno contenente la chiave privata, che eventualmente può essere anche cifrata, e uno contenente la chiave pubblica, a cui generalmente viene aggiunta l'estensione `.pub'.

La cifratura della chiave privata viene fatta generalmente perché questa non possa essere rubata; infatti, se non si utilizza questa precauzione, occorre fare in modo che nessuno possa riuscire a raggiungere il file in lettura. In pratica, una chiave privata di un utente comune, deve essere sempre cifrata, perché l'utente `root' potrebbe accedere al file corrispondente.

La chiave che si genera, sia nel file della parte privata, che in quello della parte pubblica, può contenere un commento, utile ad annotare lo scopo di quella chiave. Convenzionalmente, viene generato automaticamente un commento corrispondente all'indirizzo di posta elettronica dell'utente che l'ha generata.

In corrispondenza della creazione di una chiave, viene generato anche il file `~/.ssh/random_seed', che serve come supporto alla creazione di chiavi sufficientemente «casuali». Ogni volta che lo stesso utente genera una nuova chiave, il vecchio file `~/.ssh/random_seed' viene riutilizzato e aggiornato di conseguenza.

Il file `~/.ssh/random_seed' e quelli delle chiavi private, devono essere accessibili solo all'utente proprietario.

Alcune opzioni

-b <n-bit>

Permette di definire la dimensione della chiave in bit. La dimensione minima è di 512 bit, mentre il valore predefinito è di 1024, ritenuto più che sufficiente per un ottimo livello di sicurezza.

-f <file>

Permette di definire esplicitamente il nome del file della chiave privata da generare. Il nome del file della chiave pubblica si ottiene con l'aggiunta dell'estensione `.pub'.

Se questa opzione non viene indicata, si fa riferimento implicitamente ai file `~/.ssh/identity' e `~/.ssh/identity.pub'

-c

Permette di modificare il commento della chiave. Il commento verrà richiesto in modo interattivo.

-C <commento>

Permette di indicare un commento nella riga di comando.

-p

Permette di modificare la password in modo interattivo: viene richiesta prima la password precedente, e quindi quella nuova, per due volte.

-N <password>

Permette di indicare la password nella riga di comando.

Esempi

ssh-keygen -f /etc/ssh/ssh_host_key -N ''

Genera la coppia di file `/etc/ssh/ssh_host_key' e `/etc/ssh/ssh_host_key.pub', senza specificare alcuna password per la chiave privata.

Questo corrisponde al modo normale di creare la chiave del nodo, in cui non si specifica alcuna password, anche in considerazione del fatto che il file della chiave privata dovrebbe risultare sufficientemente protetto, essendo di proprietà dell'utente `root' e risultando leggibile solo a lui.

ssh-keygen

Genera, in modo predefinito, la coppia di file `~/.ssh/identity' e `~/.ssh/identity.pub'. Il programma richiede l'inserimento della password, che è bene specificare, trattandosi di una chiave di un utente comune.

229.3.2 /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_key.pub

La coppia di file `/etc/ssh/ssh_host_key' e `/etc/ssh/ssh_host_key.pub' rappresenta la chiave del nodo, cioè la chiave utilizzata da un determinato elaboratore per identificare se stesso.

La parte privata non deve essere cifrata; così è molto importante che il file `/etc/ssh/ssh_host_key' non sia leggibile (tranne che al proprietario, l'utente `root'). La parte pubblica, cioè il file `/etc/ssh/ssh_host_key.pub', deve essere leggibile a tutti. Generalmente, la chiave del nodo si crea con il comando seguente:

ssh-keygen -f /etc/ssh/ssh_host_key -N ''

È indispensabile creare questa coppia di file nell'elaboratore che funge da servente per gli accessi con Secure Shell. È attraverso questa chiave (la parte pubblica) che i clienti sono in grado di verificare che si tratta sempre dello stesso servente.

Nello stesso modo, può essere conveniente predisporre una chiave analoga anche nei clienti, per consentire l'autenticazione RHOST+RSA.

229.3.3 ~/.ssh/identity, ~/.ssh/identity.pub

La coppia di file `~/.ssh/identity' e `~/.ssh/identity.pub' rappresenta la chiave dell'utente in un nodo particolare, cioè la chiave utilizzata da un determinato utente di un determinato elaboratore per identificare se stesso.

La creazione di questa chiave personale è necessaria, presso il cliente, solo quando l'utente vuole utilizzare un'autenticazione RSA pura e semplice.

229.3.4 ~/.ssh/random_seed, /etc/ssh/ssh_random_seed

I file `~/.ssh/random_seed' e `/etc/ssh/ssh_random_seed' sono creati e gestiti automaticamente da Secure Shell, con lo scopo di generare chiavi sufficientemente varie. Quello che conta è che questi file siano accessibili solo all'utente proprietario. In linea di massima, la loro cancellazione accidentale non dovrebbe creare inconvenienti.

229.4 Verifica dell'identità dei serventi

Un elemento importante per la garanzia della sicurezza nelle comunicazioni è la verifica dell'identità del servente. Attraverso Secure Shell, ogni servente definisce una propria chiave, e di questa, la parte pubblica serve ai clienti per controllare che il servente sia sempre lo stesso.

Nei clienti è possibile predisporre il file `/etc/ssh/ssh_known_hosts' con l'elenco delle chiavi pubbliche dei serventi a cui ci si collega frequentemente. In aggiunta, ogni utente dei clienti può avere il proprio file `~/.ssh/known_hosts', per le chiavi pubbliche che non siano già presenti nel file `/etc/ssh/ssh_known_hosts'.

Quando un cliente si collega la prima volta a un servente Secure Shell, se la sua chiave pubblica non è già stata inserita nel file `/etc/ssh/ssh_known_hosts', viene proposto all'utente di aggiungere quella chiave pubblica nel file `~/.ssh/known_hosts'.

Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)?

yes[Invio]

Host 'linux.brot.dg' added to the list of known hosts.

In un secondo momento, se per qualche motivo la chiave di un servente, già conosciuta in precedenza da un cliente (attraverso il file `/etc/ssh/ssh_known_hosts', oppure attraverso i file `~/.ssh/known_hosts'), dovesse essere cambiata, tale cliente non riconoscerebbe più il servente e avviserebbe l'utente:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: HOST IDENTIFICATION HAS CHANGED!         @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the host key has just been changed.
Please contact your system administrator.
Add correct host key in /home/tizio/.ssh/known_hosts
to get rid of this message.
Agent forwarding is disabled to avoid attacks by corrupted servers.
X11 forwarding is disabled to avoid attacks by corrupted servers.
Are you sure you want to continue connecting (yes/no)?

Come suggerisce il messaggio, è sufficiente modificare il file `~/.ssh/known_hosts', oppure quello generale, `/etc/ssh/ssh_known_hosts', per fare in modo che questo contenga il riferimento alla nuova chiave pubblica del servente.

229.4.1 /etc/ssh/ssh_known_hosts

Il file `/etc/ssh/ssh_known_hosts' permette di annotare l'elenco dei serventi Secure Shell e delle loro chiavi pubbliche, in modo da garantirne l'autenticità.

Il file può contenere commenti, rappresentati dalle righe che iniziano con il simbolo `#', da righe vuote, che vengono ignorate ugualmente, e da righe contenenti ognuna l'informazione sulla chiave pubblica di un servente particolare.

Queste righe significative sono composte nel modo seguente, dove i vari elementi sono separati da uno o più spazi.

<host> <lunghezza-della-chiave> <esponente> <modulo>

Tanto per fare un esempio, l'ipotetico elaboratore `linux.brot.dg' potrebbe richiedere la riga seguente (abbreviata per motivi tipografici).

linux.brot.dg 1024 35 136994665376544565821...04907660021407562333675433

Evidentemente, data la dimensione delle chiavi, è improbabile che queste vengano ricopiate attraverso la digitazione diretta. Questi dati vengono ritagliati normalmente dal file della chiave pubblica a cui si riferiscono. A titolo di esempio, il file della chiave pubblica corrispondente a quanto già mostrato, avrebbe potuto essere composto dalla riga seguente:

1024 35 136994665376544565821...04907660021407562333675433 root@linux.brot.dg 

229.4.2 ~/.ssh/known_hosts

Il file `~/.ssh/known_hosts' è l'equivalente personale del file `/etc/ssh/ssh_known_hosts', permettendo agli utenti di aggiungere i loro serventi.

Questo file si compone nello stesso modo di `/etc/ssh/ssh_known_hosts', con la differenza che il programma `ssh', cioè il cliente di Secure Shell, vi aggiunge automaticamente le chiavi pubbliche dei serventi che vengono contattati per la prima volta.

229.5 Autenticazione RHOST

L'autenticazione RHOST, come già accennato, è un metodo semplice e insicuro di autenticare l'accesso attraverso la tecnica dei file `/etc/hosts.equiv' e `~/.rhosts' già utilizzata da `rlogin'.

In alternativa a questi file, Secure Shell può utilizzare la coppia `/etc/shosts.equiv' e `~/.shosts', in modo da poter essere configurato indipendentemente da `rlogin' e `rsh'.

Perché questa tecnica di autenticazione possa essere utilizzata, è necessario configurare `sshd', ovvero il demone di Secure Shell. Diversamente, in modo predefinito, l'autenticazione RHOST non viene concessa.

229.5.1 /etc/ssh/shosts.equiv, /etc/hosts.equiv

Il file `/etc/shosts.equiv', oppure `/etc/hosts.equiv', permette di definire un elenco di elaboratori che deve essere trattato come equivalente a quello locale, in modo tale che gli utenti di questi elaboratori possano accedere attraverso l'uso dei comandi di Secure Shell, e senza la richiesta di password.

L'esempio seguente mostra il contenuto del file `/etc/shosts.equiv', oppure di `/etc/hosts.equiv', di un elaboratore per il quale si vuole consentire l'accesso da parte di `dinkel.brot.dg' e di `roggen.brot.dg'.

dinkel.brot.dg
roggen.brot.dg

In questo modo, gli utenti dei nodi `dinkel.brot.dg' e `roggen.brot.dg' possono accedere al sistema locale senza la richiesta formale di alcuna identificazione, purché esista per loro un utente con lo stesso nome.

L'elenco di nodi equivalenti può contenere anche l'indicazione di utenti particolari, per la precisione, ogni riga può contenere il nome di un nodo seguito eventualmente da uno spazio e dal nome di un utente. Si osservi l'esempio seguente:

dinkel.brot.dg
roggen.brot.dg
dinkel.brot.dg tizio
dinkel.brot.dg caio

Come nell'esempio precedente, viene concesso agli utenti dei nodi `dinkel.brot.dg' e `roggen.brot.dg' di accedere localmente attraverso lo stesso nominativo utilizzato nei sistemi remoti. In aggiunta a questo, però, viene concesso agli utenti `tizio' e `caio' del nodo `dinkel.brot.dg', di accedere identificandosi con il nome di qualunque utente, senza la richiesta di alcuna password.

Si può intuire che fare una cosa del genere significa concedere a tali utenti privilegi simili a quelli che ha l'utente `root'. In generale, tali utenti non dovrebbero essere in grado di utilizzare UID molto bassi, e comunque ciò non è un buon motivo per configurare in questo modo il file `/etc/shosts.equiv' o `/etc/hosts.equiv'.

229.5.2 ~/.shosts, ~/.rhosts

Indipendentemente dal fatto che il file `/etc/shosts.equiv', oppure `/etc/hosts.equiv', sia presente o meno, ogni utente può predisporre il proprio file `~/.shosts', oppure `~/.rhosts'. La sintassi di questo file è la stessa di `/etc/shosts.equiv' (e di `/etc/hosts.equiv'), ma si riferisce esclusivamente all'utente che predispone tale file nella propria directory personale.

In questo file, l'indicazione di utenti precisi è utile e opportuna, perché quell'utente potrebbe disporre di nominativi-utente differenti sui nodi da cui vuole accedere.

dinkel.brot.dg tizi
roggen.brot.dg tizio

L'esempio mostra l'indicazione precisa di ogni nominativo-utente dei nodi che possono accedere senza richiesta di identificazione. *2*

229.6 Autenticazione RHOST+RSA

L'autenticazione RHOST+RSA, utilizza gli stessi file già visti nell'autenticazione RHOST normale, ma in più richiede che il cliente sia riconosciuto. Perché ciò avvenga, occorre che il cliente abbia una propria chiave, cioè abbia definito la coppia di file `/etc/ssh/ssh_host_key' e `/etc/ssh/ssh_host_key.pub', e che la sua parte pubblica sia annotata nel file `/etc/ssh/ssh_known_hosts' del servente, oppure nel file `~/.ssh/known_hosts' riferito all'utente che dal cliente vuole accedere.

229.7 Autenticazione RSA

L'autenticazione RSA, pura e semplice, permette di raggiungere un livello di garanzia ulteriore. Per il suo utilizzo, l'utente deve creare una propria chiave, composta dalla coppia di file `~/.ssh/identity' e `~/.ssh/identity.pub', presso l'elaboratore cliente. Data la situazione, come è già stato descritto, è opportuno che la chiave privata sia protetta con una password.

Per accedere a un servente utilizzando questo tipo di autenticazione, occorre che l'utente aggiunga nel file `~/.ssh/authorized_keys' presso il servente, la sua chiave pubblica definita nel cliente.

L'utente che utilizza questo tipo di sistema di autenticazione, potrebbe usare la stessa chiave da tutti i clienti da cui intende accedere al servente, oppure potrebbe usare chiavi differenti, aggiungendole tutte al file `~/.ssh/authorized_keys' del servente.

Quando si stabilisce una connessione con questo tipo di autenticazione, se la chiave privata dell'utente è cifrata attraverso una password, si ottiene un messaggio come quello seguente:

Enter passphrase for RSA key 'daniele@roggen.brot.dg': 

229.7.1 ~/.ssh/authorized_keys

Il file `~/.ssh/authorized_keys' viene usato nel servente per conservare le chiavi pubbliche degli utenti autorizzati ad accedere attraverso un cliente, senza bisogno di altre forme di riconoscimento.

In pratica, per concedere l'accesso attraverso l'autenticazione RSA, è sufficiente aggiungere nel file `~/.ssh/authorized_keys' le chiavi pubbliche di tali utenti, cioè quello che questi conservano nei file `~/.ssh/identity.pub' dei clienti rispettivi.

L'esempio seguente mostra un ipotetico file `~/.ssh/authorized_keys' contenente il riferimento a due chiavi. La parte finale, quella alfabetica, è la descrizione della chiave, e il suo unico scopo è quello di permetterne il riconoscimento a livello umano.

1024 33 12042598236...2812113669326781175018394671 tizio@roggen.brot.dg
1024 33 13485193076...7811672325283614604572016919 caio@dinkel.brot.dg

In realtà, le righe di questo file potrebbero essere più complesse, con l'aggiunta di un campo iniziale, contenente delle opzioni. La sintassi completa delle righe riferite a chiavi pubbliche è quindi la seguente:

[<opzioni>] <lunghezza-della-chiave> <esponente> <modulo> [<commento>]

Come al solito, le righe vote, e quelle che iniziano con il simbolo `#', vengono ignorate.

Le opzioni, facoltative, sono una serie di direttive separate da una virgola e senza spazi aggiunti. Eventualmente, le stringhe contenenti spazi devono essere racchiuse tra coppie di apici doppi, e se queste stringhe devono contenere un apice doppio, questo può essere indicato proteggendolo con la barra obliqua inversa (`\"').

Alcune opzioni

from="<elenco-modelli>"

Permette di limitare l'accesso attraverso l'autenticazione RSA. Con un elenco di modelli, eventualmente composto con caratteri jolly (`*', `?'), si possono indicare i nomi dei nodi a cui è concesso oppure è negato l'accesso. Per la precisione, i modelli che iniziano con un punto esclamativo si riferiscono a nomi cui l'accesso viene vietato espressamente.

command="<comando>"

Permette di abbinare una chiave RSA a un comando. In pratica, chi accede utilizzando questa chiave, invece di ottenere una shell, ottiene l'esecuzione del comando indicato, e subito dopo la connessione ha termine. Di solito, si abbina questa opzione a `no-pty' e a `no-port-forwarding'.

no-port-forwarding

Vieta espressamente l'inoltro del TCP/IP.

no-X11-forwarding

Vieta espressamente l'inoltro del protocollo X11.

no-pty

Impedisce l'allocazione di uno pseudo terminale (pseudo TTY).

Esempi

from="*.brot.dg,!schwarz.brot.dg" 1024 35 234...56556 tizio@dinkel.brot.dg

Concede l'utilizzo dell'accesso RSA, con la chiave indicata, solo al dominio `brot.dg', escludendo espressamente il nome `schwarz.brot.dg'.

command="ls" 1024 35 2346543...8757465456556 tizio@dinkel.brot.dg

Chi tenta di accedere utilizzando questa chiave, ottiene semplicemente l'esecuzione del comando `ls' nella directory corrente, cioè la directory personale dell'utente corrispondente.

command="tar czpf /home/tizio/backup/lettere.tar.gz /home/tizio/lettere"
 1024 35 234...56556 tizio@dinkel.brot.dg

L'esempio appare spezzato su due righe per motivi tipografici. Chi tenta di accedere utilizzando questa chiave, ottiene semplicemente l'archiviazione della directory `/home/tizio/lettere/'.

command="ls",no-port-forwarding,no-pty
 1024 35 2346543...8757465456556 tizio@dinkel.brot.dg

L'esempio appare spezzato su due righe per motivi tipografici. Chi tenta di accedere utilizzando questa chiave, ottiene semplicemente l'esecuzione del comando `ls', e per sicurezza viene impedito l'inoltro del TCP/IP e l'allocazione di uno pseudo TTY.

229.8 Autenticazione normale

Quando Secure Shell non è in grado di eseguire alcun altro tipo di autenticazione, ripiega nell'uso del sistema tradizionale, in cui viene richiesta la password abbinata al nominativo-utente con cui si vuole accedere.

Ciò rappresenta anche l'utilizzo normale di Secure Shell, il cui scopo principale è quello di garantire la sicurezza della connessione attraverso la cifratura e il riconoscimento del servente. Infatti, per ottenere questo livello di funzionamento, è sufficiente che nel servente venga definita la chiave, attraverso i file `/etc/ssh/ssh_host_key' e `/etc/ssh/ssh_host_key.pub', mentre nei clienti non serve nulla, a parte l'installazione di Secure Shell.

Quando un utente si connette per la prima volta a un servente determinato, da un cliente particolare, la chiave pubblica di quel servente viene annotata automaticamente nel file `~/.ssh/known_hosts', e questo permetterà il controllo successivo su quel servente.

Quindi, attraverso l'autenticazione normale, tutti i problemi legati alla registrazione delle varie chiavi pubbliche vengono risolti in modo automatico e quasi trasparente.

229.9 Servente Secure Shell

Il servizio di Secure Shell viene offerto tramite un demone, il programma `sshd', che deve essere avviato durante l'inizializzazione del sistema, oppure, se compilato con le opzioni necessarie, può essere messo sotto il controllo di `inetd'.

Generalmente si preferisce avviare `sshd' in modo indipendente da `inetd', perché a ogni avvio richiede un po' di tempo per la generazione di chiavi aggiuntive utilizzate per la cifratura.

La configurazione di `sshd' viene definita nel file `/etc/ssh/sshd_config'.

229.9.1 # sshd

sshd [<opzioni>]

`sshd' è il demone del servizio Secure Shell, ovvero il programma che resta in ascolto, in attesa di richieste di connessione da parte dei clienti.

`sshd', una volta avviato e dopo aver letto la sua configurazione, genera una chiave RSA aggiuntiva che si affianca a quella già definita dalla coppia di file `/etc/ssh/ssh_host_key' e `ssh_host_key.pub'. Nella documentazione di `sshd', la chiave memorizzata nei file è la chiave del nodo, mentre quella generata a ogni avvio, è la chiave del servente.

La chiave aggiuntiva viene rigenerata periodicamente, di solito ogni ora, e non viene memorizzata in alcun file.

Quando un cliente si connette, `sshd' avvia una copia di se stesso per la nuova connessione, quindi:

Successivamente, si passa alla fase di autenticazione dell'utente, secondo uno dei vari metodi già descritti, in base a quanto stabilito nella configurazione di `sshd'. Infine, il cliente richiede l'avvio di una shell o di un altro comando.

Secure Shell ignora il file `/etc/securetty', per cui gli accessi dell'utente `root' possono essere regolati solo attraverso la configurazione del file `/etc/ssh/sshd_config'.

Alcune opzioni

-f <file-di-configurazione>

Permette di fare utilizzare a `sshd' un file di configurazione differente da quello standard, ovvero `/etc/ssh/sshd_config'.

-h <file-della-chiave-dell'host>

Permette di fare utilizzare a `sshd' una chiave del nodo diversa da quella contenuta nel file standard, ovvero `/etc/ssh/ssh_host_key' (e poi anche `/etc/ssh/ssh_host_key.pub'). Si deve indicare solo il nome della chiave privata, intendendo che il nome del file contenente la chiave pubblica si ottiene con l'aggiunta dell'estensione `.pub'.

229.9.2 /etc/ssh/sshd_config

Il file di configurazione `/etc/ssh/sshd_config' permette di definire il comportamento di `sshd'. Il file può contenere righe di commento, evidenziate dal simbolo `#' iniziale, righe vuote (che vengono ignorate) e righe contenenti direttive, composte da coppie <nome> <valore>, spaziate, senza alcun simbolo di assegnamento.

Quello che segue è un tipico file `/etc/ssh/sshd_config'.

# This is ssh server systemwide configuration file.

Port 22
ListenAddress 0.0.0.0
HostKey /etc/ssh/ssh_host_key
RandomSeed /etc/ssh/ssh_random_seed
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 3600
PermitRootLogin yes
IgnoreRhosts no
StrictModes yes
QuietMode no
X11Forwarding yes
X11DisplayOffset 10
FascistLogging no
PrintMotd yes
KeepAlive yes
SyslogFacility AUTH
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
PermitEmptyPasswords yes
UseLogin no
# PidFile /var/run/sshd.pid
# AllowHosts *.our.com friend.other.com
# DenyHosts lowsecurity.theirs.com *.evil.org evil.org
# Umask 022
# SilentDeny on

I nomi usati nelle direttive sono sensibili alla differenza tra maiuscole e minuscole.

Alcune direttive

AllowHosts <modello>...

Permette di definire uno o più modelli (attraverso l'uso dei caratteri jolly `*' e `?') riferiti a nomi di clienti a cui si intende concedere l'accesso. Se questa direttiva non viene usata, si concede a qualunque cliente di accedere.

DenyHosts <modello>...

Permette di definire uno o più modelli (attraverso l'uso dei caratteri jolly `*' e `?') riferiti a nomi di clienti a cui si intende impedire l'accesso.

AllowUsers <modello>...

Permette di definire uno o più modelli (attraverso l'uso dei caratteri jolly `*' e `?') riferiti a nomi di utenti a cui si intende concedere l'accesso. Se questa direttiva non viene usata, si concede a qualunque utente di accedere.

DenyUsers <modello>...

Permette di definire uno o più modelli (attraverso l'uso dei caratteri jolly `*' e `?') riferiti a nomi di utenti a cui si intende impedire l'accesso.

FascistLogging {yes|no}

Permette di attivare una registrazione dettagliata di eventi (log). Ciò viola la riservatezza dovuta agli utenti, e in questo senso è un'opzione disattivata in modo predefinito.

HostKey <file>

Permette di indicare il file contenente la chiave privata del nodo, in alternativa a quello standard (`/etc/ssh/ssh_host_key').

IdleTimeout <durata>

Permette di definire la durata massima di una pausa nella comunicazione. Se viene superato tale tempo, il processo creato per quella connessione viene interrotto con un segnale `SIGHUP'. La durata può essere espressa in secondi se appare il numero da solo o se è seguito dalla lettera `s'; mentre la lettera `m' rappresenta minuti, `h' ore, `d' giorni e `w' settimane.

IgnoreRhosts {yes|no}

Permette di ignorare i file `~/.rhosts' e `~/.shosts', mentre `/etc/hosts.equiv' e `/etc/shosts.equiv' continuano a essere presi in considerazione. Il valore predefinito è `no'.

LoginGraceTime <durata>

Permette di stabilire il tempo massimo concesso per completare la procedura di accesso. Il valore predefinito è di 600 secondi, pari a 10 minuti.

PasswordAuthentication {yes|no}

Stabilisce se l'autenticazione attraverso la password è consentita oppure no. Il valore predefinito è `yes', cosa che permette questo tipo di autenticazione.

PermitEmptyPasswords {yes|no}

Se l'autenticazione attraverso password è consentita, permette di stabilire se sono ammesse le password nulle. Il valore predefinito è `yes'.

PermitRootLogin {yes|no|nopwd}

Permette di abilitare o meno l'accesso da parte dell'utente `root'. Il valore predefinito è `yes' che consente questo accesso in qualunque forma di autenticazione, `no' lo esclude in ogni caso, mentre `nopwd' esclude solo la forma di autenticazione attraverso password.

RhostsAuthentication {yes|no}

Permette di abilitare o meno l'autenticazione RHOST, cioè quella basata esclusivamente sui file `/etc/hosts.equiv' (o `/etc/shosts.equiv') e `~/.rhosts' (o `~/.shosts'). Per motivi di sicurezza, il valore predefinito è `no', per non autorizzare questa forma di autenticazione.

RhostsRSAAuthentication {yes|no}

Permette di abilitare o meno l'autenticazione RHOST+RSA, cioè quella basata sui file `/etc/hosts.equiv' (o `/etc/shosts.equiv'), `~/.rhosts' (o `~/.shosts') e sulla chiave RSA dei clienti. Il valore predefinito è `yes', per autorizzare questa forma di autenticazione.

RSAAuthentication {yes|no}

Permette di abilitare o meno l'autenticazione RSA, cioè quella basata sulle chiavi di ogni singolo utente. Il valore predefinito è `yes', per autorizzare questa forma di autenticazione.

StrictModes {yes|no}

Se attivato, fa in modo che `sshd' verifichi la proprietà dei file di configurazione nelle directory personali degli utenti, rifiutando di considerare i file appartenenti a utenti «sbagliati». Ciò permette di ridurre i rischi di intrusione e alterazione della configurazione da parte di terzi che potrebbero sfruttare le dimenticanze degli utenti inesperti per sostituirsi a loro. Il valore predefinito è `yes'.

229.10 Cliente Secure Shell

Il programma usato come cliente per le connessioni con Secure Shell è `ssh', il quale emula il comportamento del suo predecessore, `rsh', almeno per ciò che riguarda la sintassi fondamentale.

A fianco di `ssh' c'è anche `scp', che comunque si avvale del primo, per facilitare le operazioni di copia tra elaboratori.

`ssh' richiede una configurazione che può essere fornita in modo globale a tutto il sistema, attraverso il file `/etc/ssh/ssh_config', e in modo particolare per ogni utente, attraverso il file `~/.ssh/config'.

229.10.1 $ ssh

ssh [<opzioni>] <host> [<comando>]

`ssh' è in grado di instaurare una connessione per l'accesso presso un servente in cui sia in funzione il demone `sshd'.

L'utente può essere riconosciuto nel sistema remoto attraverso uno tra diversi tipi di autenticazione, a seconda delle reciproche configurazioni.

Al termine dell'autenticazione, l'utente ottiene una shell oppure l'esecuzione del comando fornito come ultimo argomento (come si vede dalla sintassi).

Alcune opzioni

-l <utente>

Permette di richiedere l'accesso utilizzando il nominativo-utente indicato nell'argomento. Diversamente, si intende accedere con lo stesso nominativo usato nel cliente dal quale si utilizza `ssh'.

-i <file-di-identificazione>

Permette di fare utilizzare a `ssh' una chiave di identificazione personale diversa da quella contenuta nel file standard, ovvero `~/.ssh/identity' (e poi anche `~/.ssh/identity.pub'). Si deve indicare solo il nome della chiave privata, intendendo che il nome del file contenente la chiave pubblica si ottiene con l'aggiunta dell'estensione `.pub'.

Esempi

ssh -l tizio linux.brot.dg

Accede all'elaboratore `linux.brot.dg', utilizzando lì il nominativo-utente `tizio'.

ssh -l tizio linux.brot.dg ls -l /tmp

Esegue il comando `ls -l /tmp' nell'elaboratore `linux.brot.dg', utilizzando lì il nominativo-utente `tizio'.

ssh -l tizio linux.brot.dg tar czf - /home/tizio > backup.tar.gz

Esegue la copia di sicurezza, con l'ausilio di `tar' e `gzip' (`tar' con l'opzione `z'), della directory personale dell'utente `tizio' nell'elaboratore remoto. L'operazione genera il file `backup.tar.gz' nella directory corrente dell'elaboratore locale.

Il file generato, contiene dei caratteri aggiuntivi oltre la fine del file. Questo può causare delle segnalazioni di errore quando si estrae il file compresso, ma il contenuto dell'archivio dovrebbe risultare intatto.

229.10.2 /etc/ssh/ssh_config, ~/.ssh/config

La configurazione di `ssh' può essere gestita globalmente attraverso il file `/etc/ssh/ssh_config', e singolarmente attraverso `~/.ssh/config'.

Il file può contenere righe di commento, evidenziate dal simbolo `#' iniziale, righe vuote (che vengono ignorate) e righe contenenti direttive, composte da coppie <nome> <valore>, oppure <nome>=<valore>.

In questi file di configurazione possono essere distinte diverse sezioni, riferite a gruppi di nodi. Ciò si ottiene attraverso la direttiva `Host <modelli>', in cui, anche attraverso i caratteri jolly `*' e `?', si indicano i nodi a cui sono riferite le direttive successive, fino alla prossima direttiva `Host'.

Quello che segue è il tipico file `/etc/ssh/ssh_config' (tutto commentato, ma utile ugualmente per comprenderne il funzionamento).

# This is ssh client systemwide configuration file.  This file provides 
# defaults for users, and the values can be changed in per-user configuration
# files or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for various options

# Host *
#   ForwardAgent yes
#   ForwardX11 yes
#   RhostsAuthentication yes
#   RhostsRSAAuthentication yes
#   RSAAuthentication yes
#   TISAuthentication no
#   PasswordAuthentication yes
#   FallBackToRsh yes
#   UseRsh no
#   BatchMode no
#   StrictHostKeyChecking no
#   IdentityFile ~/.ssh/identity
#   Port 22
#   Cipher idea
#   EscapeChar ~

I nomi usati nelle direttive sono sensibili alla differenza tra maiuscole e minuscole.

Alcune direttive

Cipher {idea|des|3des|blowfish|arcfour|tss|none}

Permette di indicare il tipo di cifratura preferita, se ammissibile anche per il servente. La cifratura predefinita è `idea', ritenuta la più sicura; in alternativa viene usata `3des'. Se si specifica il tipo `none' si intende di non volere alcun tipo di cifratura, cosa utile solo a scopo di analisi diagnostica.

L'utilizzo della cifratura IDEA è consentito per uso «non-commerciale», ma in un ambito più restrittivo rispetto a Secure Shell. In tal senso, potrebbe essere opportuno modificare questa impostazione predefinita, intervenendo nel file di configurazione.

Compression {yes|no}

Se attivato, permette di utilizzare una comunicazione di dati compressa, in modo da migliorare il rendimento di una connessione lenta. Il valore predefinito è `no'.

IdentityFile <file>

Permette di indicare il file contenente la chiave privata dell'utente, in alternativa a quello standard (`~/.ssh/identity').

PasswordAuthentication {yes|no}

Stabilisce se l'autenticazione attraverso la password è consentita oppure no. Il valore predefinito è `yes', cosa che permette questo tipo di autenticazione, almeno dal lato cliente.

RhostsAuthentication {yes|no}

Permette di abilitare o meno l'autenticazione RHOST. Il valore predefinito è `yes'.

RhostsRSAAuthentication {yes|no}

Permette di abilitare o meno l'autenticazione RHOST+RSA. Il valore predefinito è `yes'.

RSAAuthentication {yes|no}

Permette di abilitare o meno l'autenticazione RSA, cioè quella basata sulle chiavi di ogni singolo utente. Il valore predefinito è `yes'.

StrictHostKeyChecking {yes|no}

Se attivato, fa in modo le chiavi pubbliche dei serventi contattati non possano essere aggiunte automaticamente nell'elenco personale, il file `~/.ssh/known_hosts', e la connessione a nodi sconosciuti o irriconoscibili venga impedita. Il valore predefinito è `no'.

User <utente>

Permette di indicare l'utente da utilizzare nella connessione remota. Ciò è particolarmente utile nella configurazione personalizzata, in cui si potrebbe specificare l'utente giusto per ogni nodo presso cui si ha accesso.

Esempi

Se si accettano le impostazioni predefinite, non occorre fare nulla nel file di configurazione standard, che in pratica non contiene alcuna direttiva. Tuttavia ci potrebbe essere bisogno di cambiare qualcosa, come la cifratura. In tal caso, basta togliere i commenti dalle direttive mostrate a titolo di esempio in quel file, modificando ciò che serve.

Nell'esempio seguente viene modificata esclusivamente la tecnica di cifratura richiesta dal cliente, mantenendo commentate le altre indicazioni in modo da lasciarle al loro valore predefinito.

Host *
#   ForwardAgent yes
#   ForwardX11 yes
#   RhostsAuthentication yes
#   RhostsRSAAuthentication yes
#   RSAAuthentication yes
#   TISAuthentication no
#   PasswordAuthentication yes
#   FallBackToRsh yes
#   UseRsh no
#   BatchMode no
#   StrictHostKeyChecking no
#   IdentityFile ~/.ssh/identity
#   Port 22
    Cipher 3des
#   EscapeChar ~

Quando si decide di intervenire nell'indicazione esplicita del tipo di cifratura che il cliente intende utilizzare, si impone una scelta precisa, senza possibilità di adattamento ulteriore. Il demone `sshd' potrebbe essere stato compilato senza la gestione di uno o alcuni tipi di cifratura (per esempio potrebbe mancare proprio IDEA). In tal caso occorre verificare, provando una connessione, che la cifratura scelta sia compatibile con il servente a cui ci si vuole connettere.

229.10.3 $ scp

scp [<opzioni>] [[<utente>@]<host>:]<origine>... [[<utente>@]<host>:]<destinazione>

`scp' permette di utilizzare `ssh' per la copia di file tra elaboratori differenti. Il principio di funzionamento è lo stesso della copia normale, con la differenza che i percorsi per identificare i file e le directory, sono composti con l'indicazione dell'utente e del nodo.

Alcune opzioni

-p

Fa in modo che gli attributi originali dei file vengano rispettati il più possibile nella copia.

-r

Permette la copia ricorsiva delle directory.

Esempi

scp tizio@linux.brot.dg:/etc/profile .

Copia il file `/etc/profile' dall'elaboratore `linux.brot.dg' utilizzando il nominativo-utente `tizio', nella directory corrente dell'elaboratore locale.

scp -r tizio@linux.brot.dg:/home/tizio/ .

Copia tutta la directory `/home/tizio/' dall'elaboratore `linux.brot.dg' utilizzando il nominativo-utente `tizio', nella directory corrente dell'elaboratore locale.

229.11 X11 attraverso ssh

Secure Shell è configurata in modo predefinito per gestire automaticamente le connessioni di X. Per comprenderlo è meglio fare subito un esempio pratico. Si immagini di avere avviato X sul proprio elaboratore locale, e di avere aperto una finestra di terminale con la quale si effettua una connessione presso un sistema remoto, attraverso `ssh'. Dopo avere stabilito la connessione, si vuole avviare su quel sistema un programma che utilizza il servente grafico locale: basta avviarlo e tutto funzionerà, semplicemente, all'interno di un tunnel cifrato di Secure Shell.

229.11.1 Attività svolta da ssh

Il meccanismo attuato da Secure Shell per arrivare a questo risultato è molto complesso, e garantisce il funzionamento della connessione anche se le autorizzazioni per l'accesso al servente grafico locale non erano state concesse al sistema remoto.

Nel momento in cui si accede al sistema remoto attraverso `ssh' da una finestra di terminale di X, la controparte nel sistema remoto, cioè `sshd', genera o aggiorna il file `~/.Xauthority', nel profilo personale dell'utente utilizzato per accedere, e questo lo fa attraverso il proprio canale privilegiato. Se dopo la connessione si prova a visualizzare il contenuto della variabile `DISPLAY', si dovrebbe osservare che viene indicato uno schermo speciale nel sistema remoto. Si osservi l'esempio:

tizio@dinkel.brot.dg:~$ ssh -l caio roggen.brot.dg[Invio]

caios's password: *****[Invio]

In questo modo, l'utente `tizio' che si trova presso il nodo `dinkel.brot.dg', cerca di accedere a `roggen.brot.dg', utilizzando lì il nominativo-utente `caio'.

La prima volta che lo fa ottiene la creazione del file `~/.Xauthority' nel sistema remoto, come mostrato qui sotto.

/usr/X11/bin/xauth: creating new authority file /home/caio/.Xauthority

caio@roggen.brot.dg:~$ echo $DISPLAY

roggen.brot.dg:10.0

Contrariamente al solito, lo schermo sembra essere collocato presso il sistema remoto, e questo proprio perché è Secure Shell a gestire tutto. In questo modo però, non contano più le autorizzazioni o i divieti fatti attraverso la gestione normale di X. inoltre, dal momento che la connessione di X è incapsulata nel protocollo di Secure Shell, non valgono più eventuali restrizioni poste nei router per impedire l'utilizzo di tale protocollo.

229.11.2 Risvolti sulla sicurezza

La connessione instaurata attraverso Secure Shell garantisce che la comunicazione riferita alla gestione del servente grafico sia protetta, e risolve la maggior parte dei problemi di sicurezza derivati dall'uso di X attraverso la rete.

Tuttavia, questo non garantisce che il sistema sia completamente sicuro, dal momento che un aggressore potrebbe collocarsi nel nodo remoto e da lì sfruttare il tunnel predisposto proprio da Secure Shell, come documentato in The Interaction between SSH and X11.

A questo punto, si potrebbe ritenere conveniente di vietare in ogni caso l'utilizzo delle applicazioni per X attraverso la rete, ma dal momento che Secure Shell scavalca i sistemi tradizionali, occorre configurare la stessa Secure Shell per questo.

In generale, se è questa l'intenzione, si agisce nel file `/etc/ssh/sshd_config', con la direttiva `X11Forwarding', in modo che `sshd' non si presti alla gestione di X nel modo descritto.

X11Forwarding no

Eventualmente, lo stesso utente può impedirsi di usare X attraverso Secure Shell, e questo lo ottiene attraverso il file `~/.ssh/config', con la direttiva `ForwardX11'.

ForwardX11 no

229.12 Installazione

Secure Shell non è inclusa in tutte le distribuzioni GNU/Linux, e ciò probabilmente a causa delle norme sulle limitazioni all'esportazione dei sistemi di cifratura diffuse in vari paesi, in particolare negli Stati Uniti. Tanto per citare un caso tra tutti, la distribuzione Red Hat non distribuisce Secure Shell, nemmeno attraverso l'area dei contributi esterni.

In ogni caso, l'installazione di Secure Shell è semplice: si deve predisporre la chiave del nodo, come già descritto più volte, e se si vogliono accettare connessioni, basta avviare il demone `sshd', possibilmente attraverso uno script della procedura di inizializzazione del sistema, come `/etc/rc.d/rc.local', o simili.

La configurazione è facoltativa, e deve essere fatta solo se si desiderano inserire forme particolari di limitazioni (come nel caso del divieto dell'inoltro di X), oppure se si vuole concedere l'autenticazione RHOST (cosa che è meglio non fare).

Alcune versioni precompilate di Secure Shell sono organizzate in modo da utilizzare la directory `/etc/ssh/' per il file di configurazione del sistema (come è stato mostrato qui); altre mettono direttamente tali file nella directory `/etc/'.

229.13 Riferimenti

---------------------------

Appunti Linux 2000.04.12 --- Copyright © 1997-2000 Daniele Giacomini --  daniele @ pluto.linux.it


1.) Nella documentazione di Secure Shell si usa il termine passphrase che comunque esprime lo stesso concetto.

2.) Si deve fare attenzione al fatto che tra il nome del nodo e il nome dell'utente ci deve essere uno spazio.


[inizio] [indice generale] [precedente] [successivo] [indice analitico] [contributi]