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.
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/.
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 server che offre l'accesso e mette a disposizione una chiave pubblica, attraverso la quale i client dovrebbero poter verificare l'autenticità del server a cui si connettono. Appena si verifica la connessione, prima ancora che sia stata stabilita l'identità dell'utente, client e server concordano un sistema di cifratura.
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 client e quali utenti possono accedere senza che venga richiesta loro la password.
Per migliorare lo stato di debolezza causato da un sistema che accetta di autenticare i client 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 client.
In pratica, se il client dispone di una sua chiave pubblica può dimostrare al server la sua identità.
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 server 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*
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.
Secure Shell richiede la creazione di una o più chiavi attraverso il programma ssh. Per la precisione è necessario creare la coppia -keygen/etc/ssh/ssh_host_key e /etc/ssh/ssh_host_key.pub nel server, 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 client 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.
ssh
|
ssh 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 -keygen.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.
|
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.
|
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
|
Permette di modificare il commento della chiave. Il commento verrà richiesto in modo interattivo.
|
Permette di indicare un commento nella riga di comando.
|
Permette di modificare la password in modo interattivo: viene richiesta prima la password precedente, e quindi quella nuova, per due volte.
|
Permette di indicare la password nella riga di comando.
# 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.
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 server per gli accessi con Secure Shell. È attraverso questa chiave (la parte pubblica) che i client sono in grado di verificare che si tratta sempre dello stesso server.
Nello stesso modo, può essere conveniente predisporre una chiave analoga anche nei client, per consentire l'autenticazione RHOST+RSA.
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 client, solo quando l'utente vuole utilizzare un'autenticazione RSA pura e semplice.
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.
Un elemento importante per la garanzia della sicurezza nelle comunicazioni è la verifica dell'identità del server. Attraverso Secure Shell, ogni server definisce una propria chiave, e di questa, la parte pubblica serve ai client per controllare che il server sia sempre lo stesso.
Nei client è possibile predisporre il file /etc/ssh/ssh_known_hosts con l'elenco delle chiavi pubbliche dei server a cui ci si collega frequentemente. In aggiunta, ogni utente dei client 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 client si collega la prima volta a un server 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 server, già conosciuta in precedenza da un client (attraverso il file /etc/ssh/ssh_known_hosts, oppure attraverso i file ~/.ssh/known_hosts), dovesse essere cambiata, tale client non riconoscerebbe più il server 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 server.
Il file /etc/ssh/ssh_known_hosts permette di annotare l'elenco dei server 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 server 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 |
Il file ~/.ssh/known_hosts è l'equivalente personale del file /etc/ssh/ssh_known_hosts, permettendo agli utenti di aggiungere i loro server.
Questo file si compone nello stesso modo di /etc/ssh/ssh_known_hosts, con la differenza che il programma ssh, cioè il client di Secure Shell, vi aggiunge automaticamente le chiavi pubbliche dei server che vengono contattati per la prima volta.
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.
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 |
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*
L'autenticazione RHOST+RSA, utilizza gli stessi file già visti nell'autenticazione RHOST normale, ma in più richiede che il client sia riconosciuto. Perché ciò avvenga, occorre che il client 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 server, oppure nel file ~/.ssh/known_hosts riferito all'utente che dal client vuole accedere.
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 client. Data la situazione, come è già stato descritto, è opportuno che la chiave privata sia protetta con una password.
Per accedere a un server utilizzando questo tipo di autenticazione, occorre che l'utente aggiunga nel file ~/.ssh/authorized_keys presso il server, la sua chiave pubblica definita nel client.
L'utente che utilizza questo tipo di sistema di autenticazione, potrebbe usare la stessa chiave da tutti i client da cui intende accedere al server, oppure potrebbe usare chiavi differenti, aggiungendole tutte al file ~/.ssh/authorized_keys del server.
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': |
Il file ~/.ssh/authorized_keys viene usato nel server per conservare le chiavi pubbliche degli utenti autorizzati ad accedere attraverso un client, 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 client 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 (\").
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 e a -ptyno.
-port-forwarding
no |
Vieta espressamente l'inoltro del TCP/IP.
no |
Vieta espressamente l'inoltro del protocollo X11.
no
|
Impedisce l'allocazione di uno pseudo terminale (pseudo TTY).
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.
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 server. Infatti, per ottenere questo livello di funzionamento, è sufficiente che nel server venga definita la chiave, attraverso i file /etc/ssh/ssh_host_key e /etc/ssh/ssh_host_key.pub, mentre nei client non serve nulla, a parte l'installazione di Secure Shell.
Quando un utente si connette per la prima volta a un server determinato, da un client particolare, la chiave pubblica di quel server viene annotata automaticamente nel file ~/.ssh/known_hosts, e questo permetterà il controllo successivo su quel server.
Quindi, attraverso l'autenticazione normale, tutti i problemi legati alla registrazione delle varie chiavi pubbliche vengono risolti in modo automatico e quasi trasparente.
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.
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 client.
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 server.
La chiave aggiuntiva viene rigenerata periodicamente, di solito ogni ora, e non viene memorizzata in alcun file.
Quando un client si connette, sshd avvia una copia di se stesso per la nuova connessione, quindi:
il demone invia al client le sue chiavi pubbliche, quella del nodo e quella aggiuntiva;
il client verifica che la chiave pubblica fornita dal server non sia cambiata, come garanzia che il server è sempre lo stesso;
il client genera un numero casuale di 256 bit e lo cifra utilizzando le due chiavi pubbliche ottenute dal server, inviando poi il risultato al server stesso;
le due parti iniziano una connessione cifrata, ottenuta utilizzando il numero generato dal client, secondo una tecnica accordata tra le due parti (il server offre i metodi di cifratura disponibili, il client sceglie).
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 client richiede l'avvio di una shell o di un altro comando.
|
Secure Shell ignora il file |
|
Permette di fare utilizzare a sshd un file di configurazione differente da quello standard, ovvero /etc/ssh/sshd_config.
|
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.
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. |
AllowHosts <modello>... |
Permette di definire uno o più modelli (attraverso l'uso dei caratteri jolly * e ?) riferiti a nomi di client a cui si intende concedere l'accesso. Se questa direttiva non viene usata, si concede a qualunque client di accedere.
DenyHosts <modello>... |
Permette di definire uno o più modelli (attraverso l'uso dei caratteri jolly * e ?) riferiti a nomi di client 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 client. 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.
Il programma usato come client 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.
ssh [<opzioni>] <host> [<comando>] |
ssh è in grado di instaurare una connessione per l'accesso presso un server 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).
|
Permette di richiedere l'accesso utilizzando il nominativo-utente indicato nell'argomento. Diversamente, si intende accedere con lo stesso nominativo usato nel client dal quale si utilizza ssh.
|
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.
$ 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 nell'elaboratore -l /tmplinux.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. |
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. |
Cipher {idea|des|3des|blowfish|arcfour|tss|none}
|
Permette di indicare il tipo di cifratura preferita, se ammissibile anche per il server. 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 client.
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 server 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.
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 client, 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 client intende utilizzare, si impone una scelta precisa, senza possibilità di adattamento ulteriore. Il demone |
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.
|
Fa in modo che gli attributi originali dei file vengano rispettati il più possibile nella copia.
|
Permette la copia ricorsiva delle directory.
$ 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.
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 server grafico locale: basta avviarlo e tutto funzionerà, semplicemente, all'interno di un tunnel cifrato di Secure Shell.
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 server 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 [Invio]-l caio roggen.brot.dg
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.
La connessione instaurata attraverso Secure Shell garantisce che la comunicazione riferita alla gestione del server 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 |
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 |
Ssh (Secure Shell) Home Page
SSH Communication Security Ltd., Welcome to the ISPEC Company
Data Fellows
Replay Associates, L.L.P.
Ulrich Flegel, The Interaction between SSH and X11, Thoughts on the Security of the Secure Shell
---------------------------
Appunti Linux 1999.09.21 --- Copyright © 1997-1999 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.