[successivo] [precedente] [inizio] [fine] [indice generale] [licenze] [indice analitico] [tomo] [parte]
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. Non si tratta ancora di software libero in senso stretto; infatti, è in corso per questo il lavoro di LSH, descritto in un capitolo apposito.
In questo capitolo si vuole descrivere in particolare il funzionamento di OpenSSH, (1) che ha mantenuto molte affinità con il software originale di Secure Shell.
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 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 avere parola d'ordine.
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 la propria chiave creando i file ~/.ssh/identity e ~/.ssh/identity.pub, questa volta però, possibilmente con una parola d'ordine.
ssh-keygen [ opzioni ]
ssh-keygen permette di generare e modificare una chiave di autenticazione RSA. La chiave in questione si compone di due file: uno contenente la chiave privata, che eventualmente può essere anche cifrata, e uno contenente la chiave pubblica, a cui generalmente viene aggiunta l'estensione .pub.
La cifratura della chiave privata viene fatta generalmente perché questa non possa essere rubata; infatti, se non si utilizza questa precauzione, occorre fare in modo che nessuno possa riuscire a raggiungere il file in lettura. In pratica, una chiave privata di un utente comune, deve essere sempre cifrata, perché l'utente root potrebbe accedere al file corrispondente.
La chiave che si genera, sia nel file della parte privata, che in quello della parte pubblica, può contenere un commento, utile ad annotare lo scopo di quella chiave. Convenzionalmente, viene generato automaticamente un commento corrispondente all'indirizzo di posta elettronica dell'utente che l'ha generata.
In corrispondenza della creazione di una chiave, viene generato anche il file ~/.ssh/random_seed, che serve come supporto alla creazione di chiavi sufficientemente «casuali». Ogni volta che lo stesso utente genera una nuova chiave, il vecchio file ~/.ssh/random_seed viene riutilizzato e aggiornato di conseguenza.
Il file ~/.ssh/random_seed e quelli delle chiavi private, devono essere accessibili solo all'utente proprietario.
-b n_bit
Permette di definire la dimensione della chiave in bit. La dimensione minima è di 512 bit, mentre il valore predefinito è di 1 024, ritenuto più che sufficiente per un ottimo livello di sicurezza.
-f file
Permette di definire esplicitamente il nome del file della chiave privata da generare. Il nome del file della chiave pubblica si ottiene con l'aggiunta dell'estensione .pub.
Se questa opzione non viene indicata, si fa riferimento implicitamente ai file ~/.ssh/identity e ~/.ssh/identity.pub
-c
Permette di modificare il commento della chiave. Il commento verrà richiesto in modo interattivo.
-C commento
Permette di indicare un commento nella riga di comando.
-p
Permette di modificare la parola d'ordine in modo interattivo: viene richiesta prima la parola d'ordine precedente, quindi quella nuova per due volte.
-N parola_d'ordine
Permette di indicare la parola d'ordine 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 parola d'ordine per la chiave privata.
Questo corrisponde al modo normale di creare la chiave del nodo, in cui non si specifica alcuna parola d'ordine, 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 parola d'ordine, 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 elaboratore determinato per identificare se stesso.
La parte privata non deve essere cifrata; così è molto importante che il file /etc/ssh/ssh_host_key non sia leggibile (tranne che al proprietario, l'utente root). La parte pubblica, cioè il file /etc/ssh/ssh_host_key.pub, deve essere leggibile a tutti. Generalmente, la chiave del nodo si crea con il comando seguente:
# ssh-keygen -f /etc/ssh/ssh_host_key -N ''
È indispensabile creare questa coppia di file nell'elaboratore che funge da servente per consentire gli accessi. È attraverso questa chiave (la parte pubblica) che i clienti sono in grado di verificare che si tratta sempre dello stesso servente.
Nello stesso modo, può essere conveniente predisporre una chiave analoga anche nei clienti, per consentire l'autenticazione RHOST+RSA.
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 utente determinato, in un elaboratore determinato, per identificare se stesso.
La creazione di questa chiave personale, presso il nodo cliente, è necessaria 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 OpenSSH, 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.
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.
Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)?
yes[Invio]
Host 'linux.brot.dg' added to the list of known hosts.
In un secondo momento, se per qualche motivo la chiave di un servente, già conosciuta in precedenza da un cliente (attraverso il file /etc/ssh/ssh_known_hosts, oppure attraverso i file ~/.ssh/known_hosts), dovesse essere cambiata, tale cliente non riconoscerebbe più il servente e avviserebbe l'utente:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the host key has just been changed. Please contact your system administrator. Add correct host key in /home/tizio/.ssh/known_hosts to get rid of this message. Agent forwarding is disabled to avoid attacks by corrupted servers. X11 forwarding is disabled to avoid attacks by corrupted servers. Are you sure you want to continue connecting (yes/no)?
Come suggerisce il messaggio, è sufficiente modificare il file ~/.ssh/known_hosts, oppure quello generale, /etc/ssh/ssh_known_hosts, per fare in modo che questo contenga il riferimento alla nuova chiave pubblica del servente.
Il file /etc/ssh/ssh_known_hosts permette di annotare l'elenco dei serventi OpenSSH e delle loro chiavi pubbliche, in modo da garantirne l'autenticità.
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 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 serventi.
Questo file si compone nello stesso modo di /etc/ssh/ssh_known_hosts, con la differenza che il programma ssh, cioè il cliente di OpenSSH, vi aggiunge automaticamente le chiavi pubbliche dei serventi 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, OpenSSH 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 OpenSSH. 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 OpenSSH, senza la richiesta di parole d'ordine.
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 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, e comunque ciò non è un buon motivo per configurare in questo modo il file |
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 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.
L'autenticazione RSA, pura e semplice, permette di raggiungere un livello di garanzia ulteriore. Per il suo utilizzo, l'utente deve creare una propria chiave, composta dalla coppia di file ~/.ssh/identity e ~/.ssh/identity.pub, presso l'elaboratore cliente. Data la situazione, come è già stato descritto, è opportuno che la chiave privata sia protetta con una 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, la sua chiave pubblica definita nel cliente.
L'utente che utilizza questo tipo di sistema di autenticazione, potrebbe usare la stessa chiave da tutti i clienti da cui intende accedere al servente, oppure potrebbe usare chiavi differenti, aggiungendole tutte al file ~/.ssh/authorized_keys del servente.
Quando si stabilisce una connessione con questo tipo di autenticazione, se la chiave privata dell'utente è cifrata attraverso una parola d'ordine, si ottiene un messaggio come quello seguente:
Enter passphrase for RSA key 'daniele@roggen.brot.dg':
Il file ~/.ssh/authorized_keys viene usato nel servente per conservare le chiavi pubbliche degli utenti autorizzati ad accedere attraverso un cliente, senza bisogno di altre forme di riconoscimento.
In pratica, per concedere l'accesso attraverso l'autenticazione RSA, è sufficiente aggiungere nel file ~/.ssh/authorized_keys le chiavi pubbliche di tali utenti, cioè quello che questi conservano nei file ~/.ssh/identity.pub dei clienti rispettivi.
L'esempio seguente mostra un ipotetico file ~/.ssh/authorized_keys contenente il riferimento a due chiavi. La parte finale, quella alfabetica, è la descrizione della chiave, il cui 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 vuote 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; 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 attraverso l'autenticazione RSA. Con un elenco di modelli, eventualmente composto con caratteri jolly (*, ?), si possono indicare i nomi dei nodi a cui è concesso oppure è negato l'accesso. Per la precisione, i modelli che iniziano con un punto esclamativo si riferiscono a nomi cui l'accesso viene vietato espressamente.
command=" comando "
Permette di abbinare una chiave RSA a un comando. In pratica, chi accede utilizzando questa chiave, invece di ottenere una shell, ottiene l'esecuzione del comando indicato e subito dopo la connessione ha termine. Di solito, si abbina questa opzione a no-pty e a no-port-forwarding.
no-port-forwarding
Vieta espressamente l'inoltro del TCP/IP.
no-X11-forwarding
Vieta espressamente l'inoltro del protocollo X11.
no-pty
Impedisce l'allocazione di uno pseudo terminale (pseudo TTY).
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; inoltre, per sicurezza viene impedito l'inoltro del TCP/IP e l'allocazione di uno pseudo TTY.
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.
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 Inet.
Generalmente si preferisce avviare sshd in modo indipendente dal supervisore Inet, 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 OpenSSH, ovvero il programma che resta in ascolto, in attesa di richieste di connessione da parte dei clienti.
sshd, una volta avviato e dopo aver letto la sua configurazione, genera una chiave RSA aggiuntiva che si affianca a quella già definita dalla coppia di file /etc/ssh/ssh_host_key e ssh_host_key.pub. Nella documentazione di sshd, la chiave memorizzata nei file è la chiave del nodo, mentre quella generata a ogni avvio, è la chiave del servente.
La chiave aggiuntiva viene rigenerata periodicamente, di solito ogni ora, senza essere memorizzata in alcun file.
Quando un cliente si connette, sshd avvia una copia di se stesso per la nuova connessione, quindi:
il demone invia al cliente le sue chiavi pubbliche, quella del nodo e quella aggiuntiva;
il cliente verifica che la chiave pubblica fornita dal servente non sia cambiata, come garanzia che il servente è sempre lo stesso;
il cliente genera un numero casuale di 256 bit e lo cifra utilizzando le due chiavi pubbliche ottenute dal servente, inviando poi il risultato al servente stesso;
le due parti iniziano una connessione cifrata, ottenuta utilizzando il numero generato dal cliente, secondo una tecnica accordata tra le due parti (il servente offre i metodi di cifratura disponibili, il cliente 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 cliente richiede l'avvio di una shell o di un altro comando.
|
OpenSSH ignora il file |
-f file_di_configurazione
Permette di fare utilizzare a sshd un file di configurazione differente da quello standard, ovvero /etc/ssh/sshd_config.
-h file_della_chiave_dell'host
Permette di fare utilizzare a sshd una chiave del nodo diversa da quella contenuta nel file standard, ovvero /etc/ssh/ssh_host_key (e poi anche /etc/ssh/ssh_host_key.pub). Si deve indicare solo il nome della chiave privata, intendendo che il nome del file contenente la chiave pubblica si ottiene con l'aggiunta dell'estensione .pub.
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 clienti a cui si intende concedere l'accesso. Se questa direttiva non viene usata, si concede a qualunque cliente di accedere.
DenyHosts modello ...
Permette di definire uno o più modelli (attraverso l'uso dei caratteri jolly * e ?) riferiti a nomi di clienti a cui si intende impedire l'accesso.
AllowUsers modello ...
Permette di definire uno o più modelli (attraverso l'uso dei caratteri jolly * e ?) riferiti a nomi di utenti a cui si intende concedere l'accesso. Se questa direttiva non viene usata, si concede a qualunque utente di accedere.
DenyUsers modello ...
Permette di definire uno o più modelli (attraverso l'uso dei caratteri jolly * e ?) riferiti a nomi di utenti a cui si intende impedire l'accesso.
FascistLogging {yes|no}
Permette di attivare una registrazione dettagliata di eventi. Ciò viola la riservatezza dovuta agli utenti, pertanto è 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 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|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 una parola d'ordine.
RhostsAuthentication {yes|no}
Permette di abilitare o meno l'autenticazione RHOST, cioè quella basata esclusivamente sui file /etc/hosts.equiv (o /etc/shosts.equiv) e ~/.rhosts (o ~/.shosts). Per motivi di sicurezza, il valore predefinito è no, per non autorizzare questa forma di autenticazione.
RhostsRSAAuthentication {yes|no}
Permette di abilitare o meno l'autenticazione RHOST+RSA, cioè quella basata sui file /etc/hosts.equiv (o /etc/shosts.equiv), ~/.rhosts (o ~/.shosts) e sulla chiave RSA dei clienti. Il valore predefinito è yes, per autorizzare questa forma di autenticazione.
RSAAuthentication {yes|no}
Permette di abilitare o meno l'autenticazione RSA, cioè quella basata sulle chiavi di ogni singolo utente. Il valore predefinito è yes, per autorizzare questa forma di autenticazione.
StrictModes {yes|no}
Se attivato, fa in modo che sshd verifichi la proprietà dei file di configurazione nelle directory personali degli utenti, rifiutando di considerare i file appartenenti a utenti «sbagliati». Ciò permette di ridurre i rischi di intrusione e alterazione della configurazione da parte di terzi che potrebbero sfruttare le dimenticanze degli utenti inesperti per sostituirsi a loro. Il valore predefinito è yes.
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.
ssh [ opzioni ] host [ comando ]
ssh è in grado di instaurare una connessione per l'accesso presso un servente in cui sia in funzione il demone sshd.
L'utente può essere riconosciuto nel sistema remoto attraverso uno tra diversi tipi di autenticazione, a seconda delle reciproche configurazioni.
Al termine dell'autenticazione, l'utente ottiene una shell oppure l'esecuzione del comando fornito come ultimo argomento (come si vede dalla sintassi).
-l utente
Permette di richiedere l'accesso utilizzando il nominativo-utente indicato nell'argomento. Diversamente, si intende accedere con lo stesso nominativo usato nel cliente dal quale si utilizza ssh.
-i file_di_identificazione
Permette di fare utilizzare a ssh una chiave di identificazione personale diversa da quella contenuta nel file standard, ovvero ~/.ssh/identity (e poi anche ~/.ssh/identity.pub). Si deve indicare solo il nome della chiave privata, intendendo che il nome del file contenente la chiave pubblica si ottiene con l'aggiunta dell'estensione .pub.
$ ssh -l tizio linux.brot.dg
Accede all'elaboratore linux.brot.dg, utilizzando lì il nominativo-utente tizio.
$ ssh -l tizio linux.brot.dg ls -l /tmp
Esegue il comando ls -l /tmp nell'elaboratore linux.brot.dg, utilizzando lì il nominativo-utente tizio.
$ ssh -l tizio linux.brot.dg tar czf - /home/tizio > backup.tar.gz
Esegue la copia di sicurezza, con l'ausilio di tar e gzip (tar con l'opzione z), della directory personale dell'utente tizio nell'elaboratore remoto. L'operazione genera il file backup.tar.gz nella directory corrente dell'elaboratore locale.
|
Il file generato, contiene dei caratteri aggiuntivi oltre la fine del file. Questo può causare delle segnalazioni di errore quando si estrae il file compresso, ma il contenuto dell'archivio dovrebbe risultare intatto. |
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.
# 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 servente. Se si specifica il tipo none si intende di non volere alcun tipo di cifratura, cosa utile solo a scopo di analisi diagnostica.
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 parola d'ordine è consentita oppure no. Il valore predefinito è yes, cosa che permette questo tipo di autenticazione, almeno dal lato cliente.
RhostsAuthentication {yes|no}
Permette di abilitare o meno l'autenticazione RHOST. Il valore predefinito è yes.
RhostsRSAAuthentication {yes|no}
Permette di abilitare o meno l'autenticazione RHOST+RSA. Il valore predefinito è yes.
RSAAuthentication {yes|no}
Permette di abilitare o meno l'autenticazione RSA, cioè quella basata sulle chiavi di ogni singolo utente. Il valore predefinito è yes.
StrictHostKeyChecking {yes|no}
Se attivato, fa in modo 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 è 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 cliente, mantenendo commentate le altre indicazioni in modo da lasciarle al loro valore predefinito.
Host *
# ForwardAgent yes
# ForwardX11 yes
# RhostsAuthentication yes
# RhostsRSAAuthentication yes
# RSAAuthentication yes
# TISAuthentication no
# PasswordAuthentication yes
# FallBackToRsh yes
# UseRsh no
# BatchMode no
# StrictHostKeyChecking no
# IdentityFile ~/.ssh/identity
# Port 22
Cipher 3des
# EscapeChar ~
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.
-p
Fa in modo che gli attributi originali dei file vengano rispettati il più possibile nella copia.
-r
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.
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.
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, utilizzando il proprio canale privilegiato. Se dopo la connessione si prova a visualizzare il contenuto della variabile DISPLAY, si dovrebbe osservare che viene indicato uno schermo speciale nel sistema remoto. Si osservi l'esempio:
tizio@dinkel.brot.dg:~$ ssh -l caio roggen.brot.dg[Invio]
caios's password: *****[Invio]
In questo modo, l'utente tizio che si trova presso il nodo dinkel.brot.dg, cerca di accedere a roggen.brot.dg, utilizzando lì il nominativo-utente caio.
La prima volta che lo fa ottiene la creazione del file ~/.Xauthority nel sistema remoto, come mostrato qui sotto.
/usr/X11/bin/xauth: creating new authority file /home/caio/.Xauthority
caio@roggen.brot.dg:~$ echo $DISPLAY
roggen.brot.dg:10.0
Contrariamente al solito, lo schermo sembra essere collocato presso il sistema remoto, 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.
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, attraverso il file ~/.ssh/config con la direttiva ForwardX11.
ForwardX11 no
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).
OpenSSH
Pagine di riferimenti a lavori attorno al protocollo SECSH:
SSH Secure Shell
Replay Associates, L.L.P.
Ulrich Flegel, The Interaction between SSH and X11, Thoughts on the Security of the Secure Shell
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
[successivo] [precedente] [inizio] [fine] [indice generale] [licenze] [indice analitico] [tomo] [parte]