Internet permette di realizzare un gran numero di operazioni da remoto, soprattutto l'amministrazione di server oppure il trasferimento di file. Il protocollo Telnet e gli r-comandi BSD (rsh , rlogin e rexec) che permettono di effettuare queste azioni da remoto hanno l'inconveniente più grande nel far circolare in chiaro sulla rete le informazioni scambiate, soprattutto l'identificativo (login) e la password per l'accesso al terminale distante. Inoltre, un pirata posto su una rete tra l'utente e il terminale remoto ha la possibilità di ascoltare il traffico, cioè di utilizzare uno strumento detto sniffercapace di catturare le trame circolanti sulla rete nonché di ottenere l'identificativo e la password d'accesso al terminale remoto.

Anche se le informazioni scambiate non hanno un elevato livello di sicurezza, il pirata ottiene un accesso ad un account su un terminale da remoto e può eventualmente estendere i suoi privilegi sul terminale per ottenere un accesso amministratore (root).

Dato che è impossibile di gestire l'insieme delle infrastrutture fisiche situate tra l'utente e il terminale da remoto (visto che internet è per definizione una rete aperta), la sola soluzione è di ricorrere ad una sicurezza a livello logico (a livello dei dati).

Il protocollo SSH (Secure Shell) risponde a questa problematica permettendo agli utenti (oppure dei servizi TCP/IP) di accedere ad un terminale attraverso una comunicazione codificata (detta tunnel).

Il protocollo SSH

Il protocollo SSH (Secure Shell) è stato messo a punto nel 1995 dal finlandese Tatu Ylönen.

Si tratta di un protocollo che permette ad un client (un utente oppure un terminale) di aprire una sessione interattiva su un terminale da remoto (server) per inviare dei comandi o dei file in modalità sicura :

• I dati circolanti tra il client e il server sono codificati, cosa che garantisce la loro confidenzialità (nessuno oltre al server o al client può leggere le informazioni in transito sulla rete). Non è quindi possibile ascoltare la rete attraverso un analizzatore di trame.
• Il client e il server si autentificano reciprocamente per assicurarsi che i due terminali in comunicazione sono effettivamente quelli che ogni parte crede che siano. Non è quindi più possibile per un pirata usurpare l'identità del client e del server (spoofing).

La versione 1 del protocollo (SSH1) proposta dal 1995 aveva come scopo di servire d'alternativa alle sessioni interattive (shells) comeTelnet, rsh , rlogin e rexec. Questo protocollo possedeva tuttavia una falla che permetteva ad un pirata di inserire dei dati nel flusso cifrato. Questa è la ragione per cui nel 1997 la versione 2 del protocollo (SSH2) è stata proposta come documento di lavoro (draft) all' IETF. I documenti che definiscono il protocollo sono accessibili in linea ahttp://www.ietf.org/html.charters/secsh-charter.html.

Secure Shell Version 2 propone anche una soluzione di trasferimento di file in modo sicuro (SFTP, Secure File Transfer Protocol).

SSH è un protocollo, cioè un metodo standard che permette a dei terminali di stabilire una comunicazione sicura. Esistono in questo senso numerose implementazioni di client e di server SSH. Alcune sono a pagamento, altre gratuite o open source : troverete un certo numero di client SSH nella sezione scaricamento di Kioskea.

Funzionamento dell'SSH

Lo stabilimento di una connessione SSh si effettua in più tappe :

• In un primo tempo il server e il client s'identificano reciprocamente per realizzare un canale sicuro (livello di trasporto sicuro).
• In un secondo tempo il client si autentifica presso il server per ottenere una sessione.

Realizzazione di un canale sicuro

La creazione di un livello di trasporto sicuro inizia con una fase di negoziazione tra il client e il server per accordarsi sui metodi di codificazione da usare. In effetti il protocollo SSH è previsto per funzionare con un gran numero di algoritmi di codificazione, ed è per questo che il client e il server devono innanzitutto scambiare gli algoritmi che supportano.

In seguito, per stabilire una connessione sicura, il server invia la propria chiave pubblica d'host (host key) al client. Il client genera una chiave di sessione di 256 bits che codifica grazie alla chiave pubblica del server, e invia al server la chiave di sessione codificata nonché l'algoritmo usato. Il server decifra la chiave di sessione con la sua chiave privata e invia un messaggio di conferma cifrato attraverso la chiave di sessione. Partendo da questo punto il resto delle comunicazioni è cifrato con un algoritmo di codificazione simmetrico usando la chiave di sessione condivisa tra il client e il server.

Tutta la sicurezza della transazione si basa sull'assicurazione che il client e il server hanno rispetto alla validità delle chiavi dell'host della controparte. Così, alla prima connessione ad un server, il client visualizza generalmente un messaggio che richiede di accettare la connessione (e presenta eventualmente un condensato della chiave d'host del server) :

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

Per ottenere una sessione davvero sicura, si consiglia di chiedere verbalmente all'amministratore del server di validare la chiave pubblica presentata. Se l'utente valida la connessione, il client registra al chiave dell'host del server per evitare la ripetizione di questa fase.

Al contrario, secondo la sua configurazione, il server può talvolta verificare che il client sia effettivamente quello che pretende di essere. Così, se il server possiede una lista di host autorizzati a connettersi, codificherà un messaggio attraverso la chiave pubblica del client (che ha nel suo database di chiavi d'host) per verificare se il client sia capace di decifrarlo con la sua chiave privata (si parla di challenge).

L'autentificazione

Una volta realizzata la connessione sicura tra il client e il server, il client deve identificarsi sul server per ottenere un diritto d'accesso. Esistono diversi metodi :

• il metodo più conosciuto è la tradizionale password. Il client invia un nome utente e una password al server attraverso la comunicazione sicura e il server verifica se l'utente interessato ha accesso al terminale e se la password fornita è valida
• un metodo meno conosciuto ma più flessibile è l'uso delle chiavi pubbliche. Se l'autentificazione per chiave è scelta dal client, il server crea un challenge e da un accesso al client si quest'ultimo arriva a decifrare il challenge con la sua chiave privata

Ultime modificazione ilvenerdì 6 febbraio 2009 alle 16:52:03.Questo documento intitolato «  » da Kioskea (it.kioskea.net) è reso disponibile sotto la licenza Creative Commons. È possibile copiare, modificare le copie di questa pagina, alle condizioni previste dalla licenza, come questa nota appare chiaramente.