Capitolo 202. OpenSSH

Secure Shell, ovvero SSH, è software proprietario. All'inizio della sua storia, la sua licenza era differente, pur restando il problema dei diritti di brevetto su alcuni algoritmi crittografici utilizzati. Dai sorgenti originali di Secure Shell, quando si trattava ancora di un'edizione relativamente «libera», si sono sviluppati diversi lavori alternativi, in cui sono stati eliminati in particolare gli algoritmi crittografici più problematici da un punto di vista legale.

In questo capitolo si vuole descrivere in particolare il funzionamento di OpenSSH, ⁽¹⁾ che ha mantenuto molte affinità con il software originale di Secure Shell.

202.1 Protocolli

OpenSSH può gestire due tipi diversi di protocolli SECSH, identificati come versione 1 e versione 2. In generale si considera più sicura la versione 2, ma esistono ancora molti programmi cliente che sono in grado di comunicare solo con la prima versione.

L'utilizzo di una o dell'altra versione ha delle conseguenze nella configurazione e nel modo di generare le chiavi; pertanto, si cercherà di richiamare l'attenzione a questo proposito.

202.2 Preparazione delle chiavi

La prima cosa da fare per attivare e utilizzare OpenSSH è la creazione della coppia di chiavi pubblica e privata per il servente, cosa che si ottiene con l'ausilio del programma ssh-keygen. Queste chiavi vanno memorizzate normalmente nei file /etc/ssh/ssh_host_key e /etc/ssh/ssh_host_key.pub, dove in particolare la chiave privata (il primo dei due file) non deve essere protetto con una parola d'ordine.

Dal momento che questa coppia di chiavi viene realizzata in modo diverso a seconda del protocollo SECSH usato, può essere conveniente predisporre tre coppie di file: /etc/ssh/ssh_host_key[.pub] per una coppia RSA adatta al protocollo 1; /etc/ssh/ssh_host_rsa_key[.pub] e /etc/ssh/ssh_host_dsa_key[.pub] per una coppia RSA e DSA adatte al protocollo 2.

Eventualmente può essere necessario creare un'altra coppia di file anche nei clienti che intendono sfruttare un'autenticazione RHOST+RSA, anche in questo caso, senza parola d'ordine. Infine, ogni utente che vuole utilizzare un'autenticazione RSA pura e semplice deve generare una propria coppia di chiavi, proteggendo possibilmente la chiave privata con una parola d'ordine.

Quando si creano coppie di chiavi da collocare nell'ambito della propria directory personale, se ne prepara solitamente una coppia sola, decidendo implicitamente la versione del protocollo SECSH che verrà usato per quello scopo.

Il modello sintattico complessivo di ssh-keygen è molto semplice e si può riassumere così:

ssh-keygen [opzioni]

Il suo scopo è quello di generare e modificare una coppia di chiavi in altrettanti file distinti: uno per 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 coppia di chiavi che si genera, sia nel file della parte privata, sia 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.

Segue l'elenco delle opzioni più comuni:

`-b n_bit`	permette di definire la dimensione della chiave in bit, tenendo conto che la dimensione minima è di 512 bit, mentre il valore predefinito è di 1 024, che è ancora ritenuto sufficiente per un livello di sicurezza normale;
`-f file`	permette di definire esplicitamente il nome del file della chiave privata da generare, dove poi il nome della chiave pubblica è ottenuto semplicemente con l'aggiunta dell'estensione `.pub`;
`-p`	consente di modificare la parola d'ordine che protegge una chiave privata già esistente, in modo interattivo;
`-N parola_d'ordine`	permette di indicare la parola d'ordine da usare per proteggere la chiave privata nella riga di comando;
`-t rsa1` `-t rsa` `-t dsa`	permette di specificare il tipo di chiavi da generare, tenendo conto che il tipo `rsa1` è utilizzabile solo per la versione 1 del protocollo SECSH, mentre gli altri due tipi sono adatti alla versione 2.

A seconda del tipo di chiavi che si generano, i file predefiniti hanno un nome differente, allo scopo di consentire la gestione simultanea di tutti i tipi di chiave disponibili:

`~/.ssh/identity` `~/.ssh/identity.pub`	per una coppia di chiavi RSA adatta alla versione 1 del protocollo SECSH;
`~/.ssh/id_rsa` `~/.ssh/id_rsa.pub`	per una coppia di chiavi RSA adatta alla versione 2 del protocollo SECSH;
`~/.ssh/id_dsa` `~/.ssh/id_dsa.pub`	per una coppia di chiavi DSA adatta alla versione 2 del protocollo SECSH.

Una volta installato OpenSSH, se si intende far funzionare il servente in modo da accettare tutti i tipi di protocollo, vanno create le varie coppie di chiavi nella directory /etc/ssh/, attraverso i passaggi seguenti. In particolare, si osservi che non si possono proteggere le chiavi private con una parola d'ordine, altrimenti il servente non potrebbe lavorare in modo autonomo.

`#` `ssh-keygen -t rsa1` _<-' ^`->`-f /etc/ssh/ssh_host_key -N ''`	Crea la coppia di chiavi RSA per la versione 1 del protocollo, nei file `/etc/ssh/ssh_host_key` e `/etc/ssh/ssh_host_key.pub`.
`#` `ssh-keygen -t rsa` _<-' ^`->`-f /etc/ssh/ssh_host_rsa_key -N ''`	Crea la coppia di chiavi RSA per la versione 2 del protocollo, nei file `/etc/ssh/ssh_host_rsa_key` e `/etc/ssh/ssh_host_rsa_key.pub`.
`#` `ssh-keygen -t dsa` _<-' ^`->`-f /etc/ssh/ssh_host_dsa_key -N ''`	Crea la coppia di chiavi DSA per la versione 2 del protocollo, nei file `/etc/ssh/ssh_host_dsa_key` e `/etc/ssh/ssh_host_dsa_key.pub`.

Naturalmente, se lo si desidera, si può usare anche l'opzione -b per specificare una lunghezza della chiave diversa dal valore predefinito.

L'utente comune che desidera creare le proprie coppie di chiavi, per utilizzare poi delle forme di autenticazione basate sul riconoscimento delle chiavi stesse, può agire secondo i passaggi seguenti, avendo cura di definire una parola d'ordine per proteggere le chiavi private. Si osservi che non viene indicato il nome dei file, perché si fa riferimento alle collocazioni predefinite. Naturalmente, anche in questo caso l'utente può usare l'opzione -p se intende ottenere una dimensione particolare della chiave.

`#` `ssh-keygen -t rsa1`	Crea la coppia di chiavi RSA per la versione 1 del protocollo, nei file predefiniti `~/.ssh/identity` e `~/.ssh/identity.pub`.
`#` `ssh-keygen -t rsa`	Crea la coppia di chiavi RSA per la versione 2 del protocollo, nei file predefiniti `~/.ssh/id_rsa` e `~/.ssh/id_rsa.pub`.
`#` `ssh-keygen -t dsa`	Crea la coppia di chiavi DSA per la versione 2 del protocollo, nei file predefiniti `~/.ssh/id_dsa` e `~/.ssh/id_dsa.pub`.

202.3 Verifica dell'identità dei serventi

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 OpenSSH, 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.

The authenticity of host 'dinkel.brot.dg (192.168.1.1)' can't be established.
RSA key fingerprint is dc:16:d5:2b:20:c5:2b:7b:69:1c:72:cc:d1:26:99:8b.
Are you sure you want to continue connecting (yes/no)?

yes[Invio]

Host 'dinkel.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: REMOTE 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 RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
dc:16:d5:2b:20:c5:2b:7b:69:1c:72:cc:d1:26:99:8b.
Please contact your system administrator.
Add correct host key in /home/tizio/.ssh/known_hosts to get rid of this message.
Offending key in /home/tizio/.ssh/known_hosts:6
RSA host key for localhost has changed and you have requested strict checking.
Host key verification failed.

In questo caso, come suggerisce il messaggio, è sufficiente modificare il file ~/.ssh/known_hosts alla sesta riga, per fare in modo che questo contenga il riferimento alla nuova chiave pubblica del servente.

Volendo intervenire a mano in questo file (~/.ssh/known_hosts o /etc/ssh/ssh_known_hosts), conviene conoscere come questo è organizzato.

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

Queste righe significative sono composte in uno dei modi seguenti, dove i vari elementi sono separati da uno o più spazi.

host lunghezza_della_chiave esponente modulo

host tipo_di_chiave chiave_pubblica

Tanto per fare un esempio, l'ipotetico elaboratore linux.brot.dg potrebbe richiedere la riga seguente (abbreviata per motivi tipografici) per una chiave RSA adatta al protocollo SECSH versione 1:

roggen.brot.dg 1024 35 136994665376544565821...04907660021407562333675433

Oppure, potrebbe trattarsi di una riga simile a quella seguente per una chiave RSA adatta al protocollo SECSH versione 2:

roggen.brot.dg ssh-rsa AAAAB3NzaC1yc2EAAAAB...IwAAAgEAnhvScnWn3hCXk7W90=

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, i file delle chiavi pubbliche corrispondenti a quanto già mostrato, avrebbero potuto essere composti dalla riga:

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

oppure:

ssh-rsa AAAAB3NzaC1yc2EAAAAB...IwAAAgEAnhvScnWn3hCXk7W90= root@roggen.brot.dg

Comunque, quando si vuole intervenire nel file /etc/ssh/ssh_known_hosts, anche se questa operazione può avvenire solo in modo manuale, rimane sempre la possibilità di ottenere la prima volta l'aggiornamento automatico del file ~/.ssh/known_hosts, dal quale poi si può tagliare e incollare quanto serve nel file /etc/ssh/ssh_known_hosts, senza altre modifiche.

202.4 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, OpenSSH può utilizzare la coppia /etc/ssh/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 OpenSSH. Diversamente, in modo predefinito, l'autenticazione RHOST non viene concessa.

È bene sottolineare che questo tipo di sistema di accesso facilitato è assolutamente sconsigliabile. La disponibilità di questo metodo si giustifica solo per motivazioni storiche collegate all'uso di programmi come Rsh. In ogni caso, occorre considerare che OpenSSH non consente di usare questo sistema di autenticazione se i permessi di accesso a questi file non sono abbastanza ristretti. Pertanto, il più delle volte, quando si tenta di attuare questo tipo di sistema, l'autenticazione fallisce.

L'esempio seguente mostra il contenuto del file /etc/ssh/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 parola d'ordine.

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, ma comunque ciò non è un buon motivo per configurare in questo modo il file /etc/ssh/shosts.equiv o /etc/hosts.equiv.

Indipendentemente dal fatto che il file /etc/ssh/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/ssh/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.⁽²⁾

202.5 Autenticazione RHOST sommata al riconoscimento della chiave pubblica

L'autenticazione RHOST può essere sommata a quella del riconoscimento della chiave pubblica, 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.

In generale, non è necessario questo tipo di autenticazione mista, che di solito è anche disabilitata in modo predefinito. Infatti, è sufficiente che sia disponibile un'autenticazione basata sul controllo della chiave pubblica, senza altre restrizioni.

202.6 Autenticazione basata sul controllo della chiave pubblica

L'autenticazione basata sul controllo della chiave pubblica, pura e semplice, permette di raggiungere un livello di garanzia ulteriore. Per il suo utilizzo, l'utente deve creare una propria coppia di chiavi per ogni tipo di protocollo che intenda usare (i file ~/.ssh/identity e ~/.ssh/identity.pub, oppure ~/.ssh/id_rsa e ~/.ssh/id_rsa.pub, oppure ~/.ssh/id_dsa e ~/.ssh/id_dsa.pub) presso l'elaboratore cliente. Data la situazione, come è già stato descritto, è opportuno che la chiave privata sia protetta con una parola d'ordine.

Per accedere a un servente utilizzando questo tipo di autenticazione, occorre che l'utente aggiunga nel file ~/.ssh/authorized_keys presso il servente, le sue chiavi pubbliche definite nel nodo cliente.

Perché il sistema di autenticazione basato sulla verifica delle chiavi funzioni, è necessario che i permessi dei file coinvolti e delle stesse directory non consentano l'intromissione di estranei. In particolare, può darsi che venga rifiutato questo tipo di autenticazione se la directory personale o anche solo ~/.ssh/ dispongono dei permessi di scrittura per il gruppo proprietario.

L'utente che utilizza questo tipo di sistema di autenticazione, potrebbe usare le stesse chiavi 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 parola d'ordine, si ottiene un messaggio come quello seguente:

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

Diversamente, se le chiave privata coinvolta non è cifrata, per l'accesso non è richiesto altro.

In pratica, per concedere l'accesso attraverso questa forma di autenticazione, è sufficiente aggiungere nel file ~/.ssh/authorized_keys le chiavi pubbliche delle utenze che interessano, prelevandole dai file ~/.ssh/id*.pub contenuti nei nodi clienti rispettivi.

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

1024 33 12042598236...2812113669326781175018394671 tizio@roggen.brot.dg
ssh-rsa AAAAB3NzaC1...erMIqmsserVBqIuP1JHUivfY7VU= tizio@dinkel.brot.dg
ssh-dss AAAAB3NzaC1...kc3MgA83UkVTtCLsS42GBGR3wA== tizio@dinkel.brot.dg
1024 33 13485193076...7811672325283614604572016919 caio@dinkel.brot.dg
ssh-rsa AAAAB3NzaC1...erGTRDbMIqmssIuP1JHUivfY7VU= caio@dinkel.brot.dg
ssh-dss AAAAB3NzaC1...kc3MgA8HYjGrDCLsS42GBGR3wA== 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. Queste 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; inoltre, 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. 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 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).

Vengono mostrati alcuni esempi nell'elenco seguente.

from=".brot.dg,!schwarz.brot.dg" (segue)* 1024 35 234...56556 tizio@dinkel.brot.dg	Concede l'accesso con la chiave indicata, solo al dominio `brot.dg`, escludendo espressamente il nome `schwarz.brot.dg`.
command="ls" 1024 35 2346543...8757465456556 *(segue)* 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 *(segue)* /home/tizio/backup/lettere.tar.gz *(segue)* /home/tizio/lettere" *(segue)* 1024 35 234...56556 tizio@dinkel.brot.dg	Chi tenta di accedere utilizzando questa chiave, ottiene semplicemente l'archiviazione della directory `/home/tizio/lettere/`.
command="ls",no-port-forwarding,no-pty *(segue)* 1024 35 2346543...8757465456556 *(segue)* tizio@dinkel.brot.dg	Chi tenta di accedere utilizzando questa chiave, ottiene semplicemente l'esecuzione del comando `ls`; inoltre, per sicurezza viene impedito l'inoltro del TCP/IP e l'allocazione di uno pseudo TTY.

202.7 Autenticazione normale

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

Ciò rappresenta anche l'utilizzo normale di OpenSSH, 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 OpenSSH.

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, permettendo 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.

202.8 Servente OpenSSH

Il servizio di OpenSSH 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 del supervisore dei servizi di rete.

Generalmente si preferisce avviare sshd in modo indipendente dal supervisore dei servizi di rete, perché a ogni avvio richiede un po' di tempo per la generazione di chiavi aggiuntive utilizzate per la cifratura.

La sintassi per l'utilizzo di questo demone si può riassumere semplicemente nel modello seguente:

sshd [opzioni]

sshd, una volta avviato e dopo aver letto la sua configurazione, si comporta in maniera un po' diversa, a seconda che sia stato abilitato l'uso della versione 1 o 2 del protocollo SECSH.

In generale, quando un cliente si connette, sshd avvia una copia di se stesso per la nuova connessione, quindi, attraverso la chiave pubblica del servente inizia una sorta di negoziazione che porta alla definizione di un algoritmo crittografico da usare e di una chiave simmetrica che viene scambiata tra le parti, sempre in modo cifrato. 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.

OpenSSH 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.

Vengono descritte alcune opzioni di sshd:

`-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. 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`.
`-d`	Fa sì che `sshd` funzioni in primo piano, allo scopo di seguire una sola connessione per verificarne il funzionamento.
`-e`	Si usa in abbinamento con `-d`, per ottenere le informazioni diagnostiche attraverso lo standard error.

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 file /etc/ssh/sshd_config tipico, adatto per le due versioni del protocollo SSH, in modo simultaneo:

# La porta usata per ricevere le richieste di comunicazione
Port 22

# Direttive per restringere l'accessibilità del servizio
#ListenAddress ::
#ListenAddress 0.0.0.0

# Definizione delle versioni del protocollo utilizzabili
Protocol 2,1

# Collocazione della coppia di chiavi per il protocollo 1
HostKey /etc/ssh/ssh_host_key

# Collocazione delle coppie di chiavi per il protocollo 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key

# Durata di validità per la chiave generata automaticamente per la versione 1
KeyRegenerationInterval 3600
ServerKeyBits 768

# Livello di informazioni nel registro
SyslogFacility AUTH
LogLevel INFO

# Autenticazione
LoginGraceTime 600
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Disabilita l'autenticazione RHOSTS e la sua combinazione con
# il sistema della chiave pubblica
RhostsAuthentication no
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts yes

# Non consente l'uso di parole d'ordine vuote
PermitEmptyPasswords no

# Uncomment to disable s/key passwords 
#ChallengeResponseAuthentication no

# Consente l'autenticazione basata sul riconoscimento della parola d'ordine
PasswordAuthentication yes

# Use PAM authentication via keyboard-interactive so PAM modules can
# properly interface with the user
PAMAuthenticationViaKbdInt yes

# To change Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#AFSTokenPassing no
#KerberosTicketCleanup no

# Kerberos TGT Passing does only work with the AFS kaserver
#KerberosTgtPassing yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
#PrintLastLog no
KeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net
#ReverseMappingCheck yes

Subsystem       sftp    /usr/lib/sftp-server

Si osservi che i nomi usati nelle direttive sono sensibili alla differenza tra maiuscole e minuscole. Segue la descrizione di alcune direttive di configurazione.

`Protocol n[,m]...`	Consente di indicare quali versioni del protocollo SECSH utilizzare.
`AllowUsers modello...` `Deny modello...`	Queste due direttive permettono di definire uno o più modelli (attraverso l'uso dei caratteri jolly `*` e `?`) riferiti a nomi di utenti a cui si intende concedere, oppure vietare l'accesso. Se queste direttive non vengono usate, si concede a qualunque utente di accedere.
`HostKey file`	Questa direttiva può essere usata anche più volte, per indicare i file contenenti le chiavi private del nodo. L'utilizzo multiplo della direttiva serve proprio per indicare chiavi diverse, adatte ai diversi protocolli.
`LoginGraceTime durata`	Permette di stabilire il tempo massimo concesso per completare la procedura di accesso. Il valore predefinito è di 600 s, pari a 10 minuti.
`PasswordAuthentication` _<-' ^`->`{yes\|no}`	Stabilisce se l'autenticazione attraverso la parola d'ordine è consentita oppure no. Il valore predefinito è `yes`, cosa che permette questo tipo di autenticazione.
`PermitEmptyPasswords` _<-' ^`->`{yes\|no}`	Se l'autenticazione attraverso una parola d'ordine è consentita, permette di stabilire se sono ammesse le parole d'ordine nulle. Il valore predefinito è `yes`.
`PermitRootLogin {yes`_<-' ^`->`\|without-password`_<-' ^`->`\|forced-commands-only\|no}`	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 `without-password` esclude solo la forma di autenticazione attraverso una parola d'ordine e `forced-commands-only` consente di eseguire solo dei comandi remoti, sempre escludendo l'autenticazione basata sulla parola d'ordine.
`IgnoreRhosts {yes\|no}`	Permette di ignorare i file `~/.rhosts` e `~/.shosts`, mentre, per quanto riguarda questa direttiva, i file `/etc/hosts.equiv` e `/etc/shosts.equiv` continuano a essere presi in considerazione. Il valore predefinito è `no`.
`RhostsAuthentication` _<-' ^`->`{yes\|no}`	Permette di abilitare o meno l'autenticazione RHOST, cioè quella basata esclusivamente sui file `/etc/hosts.equiv` (o `/etc/shosts.equiv`) ed eventualmente `~/.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 sommata al riconoscimento della chiave pubblica, per il protocollo della versione 1. Il valore predefinito è `no`, per non autorizzare questa forma di autenticazione.
`HostbasedAuthentication` _<-' ^`->`{yes\|no}`	Permette di abilitare o meno l'autenticazione RHOST sommata al riconoscimento della chiave pubblica, per il protocollo della versione 2. Il valore predefinito è `no`, per non autorizzare questa forma di autenticazione.
`IgnoreUserKnownHosts` _<-' ^`->`{yes\|no}`	Permette di ignorare i file `~/.ssh/known_hosts` degli utenti, durante l'autenticazione basata su RHOST sommata al riconoscimento della chiave pubblica. Il valore predefinito è `no`, con il quale i file in questione vengono letti regolarmente.
`RSAAuthentication {yes\|no}`	Permette di abilitare o meno l'autenticazione basata sulle chiavi di ogni singolo utente, per quanto riguarda la versione 1 del protocollo. Il valore predefinito è `no`, che esclude questa forma di autenticazione.
`PubkeyAuthentication` _<-' ^`->`{yes\|no}`	Permette di abilitare o meno l'autenticazione basata sulle chiavi di ogni singolo utente, per quanto riguarda la versione 2 del protocollo. Il valore predefinito è `yes`, che consente 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» o con permessi non appropriati. 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`.

202.9 Cliente OpenSSH

Il programma usato come cliente per le connessioni con OpenSSH è 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.

Il modello sintattico per l'utilizzo di ssh, si esprime semplicemente nel modo seguente:

ssh [opzioni] host [comando]

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

Segue l'elenco di alcune opzioni di uso più frequente.

`-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/id` (e poi anche `~/.ssh/id.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`.
`-1`	Richiede espressamente l'uso del protocollo nella versione 1.
`-2`	Richiede espressamente l'uso del protocollo nella versione 2.
`-4`	Utilizza indirizzi IPv4.
`-6`	Utilizza indirizzi IPv6.

Seguono alcuni esempi di utilizzo di ssh.

`$` `ssh -l tizio roggen.brot.dg`	Accede all'elaboratore `roggen.brot.dg`, utilizzando lì il nominativo-utente `tizio`.
`$` `ssh -l tizio roggen.brot.dg ls -l /tmp`	Esegue il comando `ls -l /tmp` nell'elaboratore `roggen.brot.dg`, utilizzando lì il nominativo-utente `tizio`.
`$` `ssh -l tizio roggen.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.

A proposito dell'esempio con cui si esegue una copia di sicurezza attraverso la rete, è bene sottolineare che il file generato, contiene dei caratteri aggiuntivi oltre la fine del file. Ciò 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 file /etc/ssh/ssh_config tipico, tutto commentato, ma utile ugualmente per comprenderne il funzionamento.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsAuthentication no
#   RhostsRSAAuthentication yes
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   FallBackToRsh no
#   UseRsh no
#   BatchMode no
#   CheckHostIP yes
#   StrictHostKeyChecking yes
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_rsa
#   Port 22
#   Protocol 2,1
#   Cipher blowfish
#   EscapeChar ~

Anche in questo caso, si deve ricordare che i nomi usati nelle direttive sono sensibili alla differenza tra maiuscole e minuscole.

Segue la descrizione di alcune direttive.

`Cipher {des\|3des`_<-' ^`->`\|blowfish\|none}`	Permette di indicare il tipo di cifratura preferita per il protocollo della versione 1. Se si specifica il tipo `none` si intende di non volere alcun tipo di cifratura, cosa utile solo a scopo di analisi diagnostica.
`Ciphers tipo_cifratura`_<-' ^`->`[,tipo_cifratura]...`	Consente di indicare un elenco di cifrature utilizzabili per il protocollo della versione 2.
`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. Questa direttiva si può usare anche più volte, per fare riferimento a coppie di chiavi distinte per i vari tipi di protocolli.
`Protocol n[,m]...` `RhostsAuthentication` _<-' ^`->`{yes\|no}` `RhostsRSAAuthentication` _<-' ^`->`{yes\|no}` `RSAAuthentication {yes\|no}` `PubkeyAuthentication` _<-' ^`->`{yes\|no}` `PasswordAuthentication` _<-' ^`->`{yes\|no}`	Queste direttive hanno lo stesso significato e utilizzo di quelle corrispondenti alla configurazione del servente.
`StrictHostKeyChecking` _<-' ^`->`{yes\|no\|ask}`	Se attivato, fa in modo che le chiavi pubbliche dei serventi contattati non possano essere aggiunte automaticamente nell'elenco personale, il file `~/.ssh/known_hosts`, impedendo la connessione a nodi sconosciuti o irriconoscibili. Il valore predefinito è `ask`, con cui si chiede all'utente come comportarsi.
`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.

Per copiare dei file in modo cifrato, si può usare scp, che ovviamente si avvale di ssh in modo trasparente:

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

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. Vengono descritte 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;
`-1`	richiede espressamente l'uso del protocollo nella versione 1;
`-2`	richiede espressamente l'uso del protocollo nella versione 2;
`-4`	utilizza indirizzi IPv4;
`-6`	utilizza indirizzi IPv6.

Seguono alcuni esempi.

`$` `scp` _<-' ^`->`tizio@roggen.brot.dg:/etc/profile` _<-' ^`->`.`	Copia il file `/etc/profile` dall'elaboratore `roggen.brot.dg` utilizzando il nominativo-utente `tizio`, nella directory corrente dell'elaboratore locale.
`$` `scp -r` _<-' ^`->`tizio@roggen.brot.dg:/home/tizio/` _<-' ^`->`.`	Copia tutta la directory `/home/tizio/` dall'elaboratore `roggen.brot.dg` utilizzando il nominativo-utente `tizio`, nella directory corrente dell'elaboratore locale.

202.10 Verifica del funzionamento di un servente OpenSSH

In condizioni normali, la configurazione tipica di OpenSSH consente delle connessioni dove il riconoscimento degli utenti avviene attraverso l'inserimento della parola d'ordine. Per ragioni di sicurezza, le forme di autenticazione «RHOST», ovvero quelle basate sull'uso dei file /etc/hosts.equiv, /etc/shosts.equiv, ~/.rhosts e ~/.shosts, sono disabilitate.

Di solito, l'autenticazione basata sulla verifica della chiave pubblica è abilitata, ma si richiede che i permessi e la proprietà dei file relativi siano coerenti per il contesto a cui si riferiscono.

In generale, è bene evitare le forme di autenticazione RHOST, anche quando sono mediate dal riconoscimento concorrente della chiave pubblica; pertanto, se è necessario accedere senza l'indicazione di una parola d'ordine, il modo più corretto rimane quello del riconoscimento della chiave, senza altre interferenze.

Spesso, quando si cerca di realizzare una connessione senza bisogno di inserire la parola d'ordine, si incappa in qualche problema che impedisce di ottenere il risultato. Per scoprire dove sia il problema, è necessario avviare il demone sshd in modalità diagnostica, per seguire una connessione singola e vedere cosa succede veramente:

# sshd -e -d 2>&1 | less

All'avvio, ciò che si ottiene sono i messaggi relativi allo stato della configurazione. Per esempio:

debug1: Seeding random number generator
debug1: sshd version OpenSSH_3.0.2p1 Debian 1:3.0.2p1-9
debug1: private host key: #0 type 0 RSA1
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #2 type 2 DSA
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
Generating 768 bit RSA key.
RSA key generation complete.

Se dal nodo dinkel.brot.dg l'utente tizio tenta di collegarsi, si può leggere, in particolare, l'estratto seguente:

Connection from 192.168.1.1 port 32773
...
debug1: trying public key file /home/tizio/.ssh/authorized_keys
debug1: matching key found: file /home/tizio/.ssh/authorized_keys, line 3
...
debug1: ssh_rsa_verify: signature correct
Accepted publickey for tizio from 192.168.1.1 port 32773 ssh2
debug1: Entering interactive session for SSH2.

In questo caso si evidenzia un'autenticazione basata sul riconoscimento della chiave pubblica. Ecco cosa potrebbe succedere invece se i permessi non vengono ritenuti adeguati:

debug1: trying public key file /home/tizio/.ssh/authorized_keys
Authentication refused: bad ownership or modes for directory /home/tizio

In questo caso, l'autenticazione basata sul riconoscimento della chiave pubblica, non funziona perché la directory personale dell'utente consente la scrittura al gruppo, pertanto si ricade nella solita autenticazione per mezzo della parola d'ordine.

202.11 X in un tunnel OpenSSH

OpenSSH è configurato 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 OpenSSH.

202.11.1 Attività svolta da OpenSSH

Il meccanismo attuato da OpenSSH per arrivare a questo risultato è molto complesso, garantendo 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, 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]

caio'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, proprio perché è OpenSSH 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 SECSH, non valgono più eventuali restrizioni poste nei router per impedire l'utilizzo di tale protocollo.

202.11.2 Risvolti sulla sicurezza

La connessione instaurata attraverso OpenSSH garantisce che la comunicazione riferita alla gestione del servente grafico sia protetta, risolvendo 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 OpenSSH, 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 OpenSSH scavalca i sistemi tradizionali, occorre configurare proprio OpenSSH 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 OpenSSH, intervenendo nel file ~/.ssh/config con la direttiva ForwardX11.

ForwardX11 no

202.12 Creazione di un tunnel cifrato generico con OpenSSH

Il cliente OpenSSH è in grado di realizzare un tunnel cifrato tra due elaboratori, attraverso una tecnica chiamata port forwarding. In pratica, con questa tecnica, si apre una connessione SECSH normale, con o senza l'attivazione di una shell remota, nella quale si inserisce una comunicazione aggiuntiva che collega una porta remota con una porta locale. L'esempio seguente dovrebbe servire per comprendere la tecnica:

tizio@roggen.brot.dg:~$ ssh -N -L 9090:dinkel.brot.dg:80 caio@dinkel.brot.dg[Invio]

l'utente tizio presso l'elaboratore roggen.brot.dg si collega all'elaboratore dinkel.brot.dg, con l'utenza caio, per aprire un tunnel tra dinkel.brot.dg:80 e roggen.brot.dg:9090;
[Ctrl+z]

tizio@roggen.brot.dg:~$ bg[Invio]

dopo essersi identificato presso l'elaboratore remoto, sospende l'esecuzione del programma e quindi lo riattiva sullo sfondo;
tizio@roggen.brot.dg:~$ links http://localhost:9090[Invio]

A questo punto si può visitare il sito http://dinkel.brot.dg:80 utilizzando invece l'indirizzo http://localhost:9090, garantendo che la comunicazione tra l'elaboratore locale (roggen.brot.dg) e dinkel.brot.dg avvenga in modo cifrato.

Tabella 202.14. Opzioni di ssh specifiche per la realizzazione di un tunnel tra l'elaboratore locale e un nodo remoto, che disponga anche di un servente OpenSSH attivo.

Opzione	Descrizione
`-N`	Non esegue un comando presso l'elaboratore remoto.
`-L porta_locale:nodo_remoto:porta_remota` `-L porta_locale/nodo_remoto/porta_remota`	Apre la porta locale indicata e ritrasmette le comunicazioni con questa porta alla porta remota dell'elaboratore remoto indicato. Se si apre localmente una porta privilegiata, occorre agire in qualità di utente `root` nell'elaboratore locale. La prima notazione riguarda IPv4, mentre la seconda riguarda IPv6.
`-R porta_remota:nodo_locale:porta_locale` `-R porta_remota/nodo_locale/porta_locale`	Apre la porta remota indicata e ritrasmette le comunicazioni con questa porta alla porta locale dell'elaboratore locale indicato. Se si apre una porta privilegiata remota, occorre agire in qualità di utente `root` nell'elaboratore remoto. La prima notazione riguarda IPv4, mentre la seconda riguarda IPv6.

202.13 Installazione

OpenSSH non è inclusa in tutte le distribuzioni GNU/Linux, a causa delle norme sulle limitazioni all'esportazione dei sistemi di cifratura diffuse in vari paesi, in particolare negli Stati Uniti.

In ogni caso, l'installazione di OpenSSH è semplice: si deve predisporre la chiave del nodo, come già descritto più volte; quindi, se si vogliono accettare connessioni, basta avviare il demone sshd, possibilmente attraverso uno script della procedura di inizializzazione del sistema.

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 OpenSSH 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/.

202.14 Riferimenti

OpenSSH

<http://www.openssh.com/>
Pagine di riferimenti a lavori attorno al protocollo SECSH:

<http://www.openssh.org/>

<http://www.freessh.org/>
SSH Secure Shell

<http://www.ssh.org/>
Replay Associates, L.L.P.

<http://www.replay.com/>
Ulrich Flegel, The interaction between SSH and X11, thoughts on the security of the Secure Shell, 1997

<ftp://ftp.cert.dfn.de/pub/docs/crypt/ssh-x11.ps.gz>

1) OpenSSH licenza speciale

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

Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome openssh.html