Il lavoro di tesi ha come obiettivo la progettazione e la realizzazione di un sistema distribuito per l’accesso remoto sicuro a dispositivi non pubblici. La prima fase di studio dello stato dell’arte in merito di accesso remoto, identificando SSH come il protocollo più robusto e affidabile su cui basare la connessione remota. La seconda fase di progettazione ha prodotto l'architettura proposta, basata su tre componenti. - Candidate, dispositivo che concede accesso remoto; - Applicant, dispositivo richiedente accesso remoto verso un Candidate; - Gateway, centro-stella del sistema, gestisce le connessioni tra gli altri elementi e autorizza gli accessi. La terza fase ha previsto la definizione dei flussi operativi. Il Gateway, sempre attivo e in attesa di nuove connessioni, riceve richieste dai Candidate e dagli Applicant. Un Candidate si connette al Gateway identificandosi. Il Gateway autorizza la connessione, la accetta e richiede l’apertura di una canale di controllo remoto. Un Applicant si connette al Gateway fornendo l’identificativo del Candidate da raggiungere. Il Gateway autorizza la connessione, recupera il riferimento al canale di controllo del Candidate e lo fornisce all’Applicant. Nella pratica, l’Applicant funge da client SSH verso il Candidate che funge da server SSH, mentre il Gateway opera da proxy. Nessuna implementazione esistente prevede che il client accetti richieste di apertura di canali provenienti dal server a cui si sta connettendo. Di conseguenza, è stata necessaria un’implementazione custom del protocollo che fosse comunque in linea con le direttive del protocollo.
Accesso remoto sicuro e federato: un'implementazione del protocollo SSH
CETRONE, FELICE
2021/2022
Abstract
Il lavoro di tesi ha come obiettivo la progettazione e la realizzazione di un sistema distribuito per l’accesso remoto sicuro a dispositivi non pubblici. La prima fase di studio dello stato dell’arte in merito di accesso remoto, identificando SSH come il protocollo più robusto e affidabile su cui basare la connessione remota. La seconda fase di progettazione ha prodotto l'architettura proposta, basata su tre componenti. - Candidate, dispositivo che concede accesso remoto; - Applicant, dispositivo richiedente accesso remoto verso un Candidate; - Gateway, centro-stella del sistema, gestisce le connessioni tra gli altri elementi e autorizza gli accessi. La terza fase ha previsto la definizione dei flussi operativi. Il Gateway, sempre attivo e in attesa di nuove connessioni, riceve richieste dai Candidate e dagli Applicant. Un Candidate si connette al Gateway identificandosi. Il Gateway autorizza la connessione, la accetta e richiede l’apertura di una canale di controllo remoto. Un Applicant si connette al Gateway fornendo l’identificativo del Candidate da raggiungere. Il Gateway autorizza la connessione, recupera il riferimento al canale di controllo del Candidate e lo fornisce all’Applicant. Nella pratica, l’Applicant funge da client SSH verso il Candidate che funge da server SSH, mentre il Gateway opera da proxy. Nessuna implementazione esistente prevede che il client accetti richieste di apertura di canali provenienti dal server a cui si sta connettendo. Di conseguenza, è stata necessaria un’implementazione custom del protocollo che fosse comunque in linea con le direttive del protocollo.File | Dimensione | Formato | |
---|---|---|---|
917506_tesi_felice_cetrone_917506.pdf
non disponibili
Tipologia:
Altro materiale allegato
Dimensione
695.83 kB
Formato
Adobe PDF
|
695.83 kB | Adobe PDF |
I documenti in UNITESI sono protetti da copyright e tutti i diritti sono riservati, salvo diversa indicazione.
https://hdl.handle.net/20.500.14240/139033