Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Linuxtopia - Red Hat Enterprise Linux Reference Guide (Italiano) - Sequenza degli eventi di una connessione SSH

20.3. Sequenza degli eventi di una connessione SSH

Una serie di eventi contribuisce a salvaguardare l'integrit� di una comunicazione SSH tra due host.

  • Viene fatta una introduzione criptografica in modo tale che il client possa verificare che stia comunicando con il server corretto.

  • Il livello di trasporto del collegamento tra il client e l'host remoto, viene cifrato usando un codice simmetrico.

  • Il client autentica se stesso al server.

  • il client remoto interagisce con l'host remoto attraverso la connessione cifrata.

20.3.1. Livello di trasporto

Lo scopo primario del livello di trasporto � quello di facilitare una comunicazione sicura tra due host al momento dell'autenticazione e durante una successiva comunicazione. Il livello di trasporto, cerca di raggiungere tale scopo cifrando e decifrando i dati, e fornendo una protezione dell'integrit� dei pacchetti di dati in fase di trasmissione e ricezione. Inoltre, il livello di trasporto pu� fornire la compressione dei dati, aumentando la velocit� di trasferimento delle informazioni.

Quando un client SSH contatta un server, avviene uno scambio di informazioni in modo che i due sistemi possano creare correttamente il livello di trasporto. Durante questo scambio ecco cosa succede:

  • Scambio delle chiavi

  • Algoritmo della chiave pubblica

  • Algoritmo della cifratura simmetrica

  • Algoritmo per l'autenticazione del messaggio

  • L'algoritmo hash � determinato

Durante lo scambio delle chiavi, il server si fa riconoscere dal client tramite una chiave host unica. Se il client non ha mai comunicato con il suddetto server, esso non � in grado di riconoscere la sua chiave e non verr� eseguito il collegamento. OpenSSH aggira questo problema accettando la chiave host del server dopo che l'utente � stato notificato, verificando l'accettazione della chiave host stessa. Nei collegamenti successivi, la chiave host del server viene verificata con una versione salvata sul client, in modo che il client sia sicuro di comunicare con il server corretto. Se in futuro la chiave host non corrisponde pi�, l'utente dovr� rimuovere la versione salvata nel client prima di eseguire un nuovo collegamento.

CautelaAttenzione
 

Un aggressore potrebbe mascherarsi da utente del server SSH durante il contatto iniziale, questo perch� il sistema locale non conosce necessariamente la differenza tra il server corretto e quello falso impostato dall'aggressore. Per evitare che questo accada, dovreste verificare l'integrit� del nuovo server SSH, contattando l'amministratore del server prima di collegarvi per la prima volta o a causa di una non corrispondenza della chiave.

SSH � stato ideato per funzionare con quasi ogni tipo di algoritmo per le chiavi pubbliche o formato di codifica. Dopo lo scambio iniziale delle chiavi che genera un valore hash usato per gli scambi e un valore segreto condiviso, i due sistemi iniziano immediatamente a calcolare nuove chiavi e algoritmi per proteggere l'autenticazione e i dati futuri inviati tramite la connessione.

Dopo la trasmissione di una certa quantit� di dati con l'utilizzo di una chiave e un algoritmo particolari (la quantit� esatta dipende dall'implementazione di SSH), avviene un altro scambio di chiavi, che genera a sua volta una ulteriore serie di valori hash e un nuovo valore segreto condiviso. In questo modo, anche se un aggressore riuscisse a determinare tali valori, essi saranno validi solo per un determinato periodo.

20.3.2. Autenticazione

Dopo aver costruito un tunnel sicuro per inviare le informazioni da un sistema all'altro, il server indica al client i diversi metodi di autenticazione supportati, come per esempio una firma privata codificata o la digitazione di una password. Il client tenta, poi, di autenticarsi al server tramite uno dei metodi supportati.

Poich� i server SSH e i client possono essere configurati per autorizzare diversi tipi di autenticazione, questo metodo offre un ottimo controllo a entrambe le parti. Il server stabilisce i metodi di cifratura supportati in base al proprio modello di sicurezza, e il client pu� scegliere l'ordine dei metodi di autenticazione da utilizzare dalle opzioni disponibili. Grazie alla sicurezza del livello di trasporto SSH, � possibile utilizzare senza problemi perfino metodi di autenticazione apparentemente non sicuri, come l'autenticazione basata sull'host o sull'uso della password.

20.3.3. Canali

Dopo un'autenticazione corretta su un livello di trasporto SSH, vengono aperti dei canali mediante una tecnica chiamata multiplexing[1].Ognuno di questi canali gestisce la comunicazione per una diversa sessione di terminale di informazioni X11 inviate.

Entrambi i client ed i server possono creare un nuovo canale. A ogni canale viene assegnato un numero diverso per ogni estremit� del collegamento. Quando il client tenta di aprire un nuovo canale, viene inviato, insieme alla richiesta, il suo numero. Questa informazione viene archiviata sul server e utilizzata per indirizzare una particolare comunicazione di servizio per il canale in questione. In questo modo le diverse sessioni non si disturbano, ed i canali possono essere chiusi senza interrompere la connessione primaria SSH tra i due sistemi.

I canali supportano inoltre il controllo del flusso, che consente loro di inviare e ricevere i dati ordinatamente. In questo modo i dati non vengono inviati attraverso il canale finch� il client non riceve un messaggio che lo avverte che il canale � in grado di ricevere.

Il client e il server negoziano le caratteristiche di ogni canale automaticamente, a seconda del tipo di servizio che il client richiede e del tipo di connessione di rete che l'utente usa. I diversi tipi di connessione remota possono essere gestiti in modo flessibile senza dover modificare l'infrastruttura di base del protocollo.

Note

[1]

Una connessione multiplexed � costituita da diversi segnali inviati tramite un mezzo comune condiviso. Con SSH, canali differenti vengono inviati tramite una connessione comune sicura.

 
 
  Published under the terms of the GNU General Public License Design by Interspire