[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico] [volume] [parte]
Secure Shell, ovvero SSH, è software proprietario. All'inizio della sua storia, la sua licenza è stata differente, pur restando il problema dei diritti di brevetto su alcuni algoritmi crittografici utilizzati. Dai sorgenti originali di Secure Shell, delle edizioni relativamente «libere», 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, (1) che ha mantenuto molte affinità con il software originale di Secure Shell.
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 clienti 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, negli esempi si cerca di richiamare l'attenzione a questo proposito.
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: |
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.
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 |
Segue l'elenco delle opzioni più comuni:
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:
|
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.
|
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.
|
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.
nodo lunghezza_della_chiave esponente modulo |
nodo 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:
|
Oppure, potrebbe trattarsi di una riga simile a quella seguente per una chiave RSA adatta al protocollo SECSH versione 2:
|
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:
|
oppure:
|
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.
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.
|
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:
|
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, comunque ciò non è un buon motivo per configurare in questo modo il file |
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.
|
L'esempio mostra l'indicazione precisa di ogni nominativo-utente dei nodi che possono accedere senza richiesta di identificazione.(2)
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. |
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.
|
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:
|
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.
|
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 (\").
|
Vengono mostrati alcuni esempi nell'elenco seguente.
|
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 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 |
Vengono descritte alcune opzioni di sshd:
|
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:
|
Si osservi che i nomi usati nelle direttive sono sensibili alla differenza tra maiuscole e minuscole. Segue la descrizione di alcune direttive di configurazione.
|
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 ci sono anche scp e sftp 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] nodo [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).
|
Tabella 279.22. Alcune opzioni di uso più frequente.
|
Seguono alcuni esempi di utilizzo di ssh.
$ ssh -l tizio roggen.brot.dg[Invio]
Accede all'elaboratore roggen.brot.dg, utilizzando lì il nominativo-utente tizio.
$ ssh -l tizio roggen.brot.dg ls -l /tmp[Invio]
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[Invio]
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.
|
Anche in questo caso, si deve ricordare che i nomi usati nelle direttive sono sensibili alla differenza tra maiuscole e minuscole.
|
Tabella 279.24. Alcune direttive.
|
Per copiare dei file in modo cifrato, si può usare scp, che ovviamente si avvale di ssh in modo trasparente:
scp [opzioni] [[utente@]nodo:]origine... [[utente@]nodo:]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:
|
Tabella 279.25. Alcune opzioni.
|
Seguono alcuni esempi.
$ scp \
\tizio@roggen.brot.dg:/etc/profile \
\.[Invio]
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/ \
\.[Invio]
Copia tutta la directory /home/tizio/ dall'elaboratore roggen.brot.dg utilizzando il nominativo-utente tizio, nella directory corrente dell'elaboratore locale.
Quando si richiede un trasferimento di file più complesso e scp si mostra scomodo per i propri fini, si può optare per sftp, che si comporta in modo simile a un programma cliente per il protocollo FTP, ma si avvale invece di un servente SSH compatibile con questa estensione.
|
Il servente OpenSSH può accettare connessioni attraverso sftp solo se nella sua configurazione è prevista tale gestione. Precisamente, nel file
In pratica, per la gestione di questa funzionalità particolare, il demone sshd si avvale di un programma di appoggio, corrispondente a sftp-server. |
La sintassi per l'utilizzo di sftp si articola in diverse forme differenti:
sftp [opzioni] nodo |
sftp [utente]@nodo |
sftp [utente]@nodo:file... |
sftp [utente]@nodo:directory |
In pratica, si può avviare sftp con l'indicazione di un nodo, assieme a delle opzioni eventuali; oppure si saltano le opzioni e si indicano dei file che si vogliono prelevare; infine si può indicare una directory di partenza che si vuole aprire immediatamente presso il nodo remoto, per i comandi da impartire successivamente in modo interattivo.
In generale, il comportamento di sftp è molto simile a quello di un cliente FTP tradizionale, con la differenza che la comunicazione avviene in modo cifrato (si veda eventualmente il capitolo 222). La tabella 279.27 elenca alcuni comandi che vengono utilizzati durante il funzionamento interattivo di sftp. Per altre informazioni, si può consultare la pagina di manuale sftp(1).
|
Tabella 279.27. Alcuni comandi interattivi di sftp.
|
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[Invio]
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.
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 funziona, 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 sono 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.
|
caio@roggen.brot.dg:~$ echo $DISPLAY[Invio]
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.
|
Eventualmente, lo stesso utente può impedirsi di usare X attraverso OpenSSH, intervenendo nel file ~/.ssh/config con la direttiva ForwardX11.
|
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 279.35. 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.
|
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 |
OpenSSH
Pagine di riferimenti a lavori attorno al protocollo SECSH:
SSH Secure Shell
Ulrich Flegel, The interaction between SSH and X11, thoughts on the security of the Secure Shell, 1997
Appunti di informatica libera 2006.07.01 --- Copyright © 2000-2006 Daniele Giacomini -- <daniele (ad) swlibero·org>
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.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico]
