Home page

www.gelpi.it

Clusit image

home

area tecnica

articoli

eventi


Esempio di configurazione di un tunnel in SSH

24 aprile 2002 - Rivisto e integrato 7 agosto 2003

L'SSH oltre ad instaurare una connessione sicura fra due host permette anche di configurare delle funzionalità di TCP tunneling. Queste possono essere molto comode per eseguire lavori specifici fra due reti connesse solo da Internet.

Detto in altre parole è possibile partire da un PC (PC1) aprire una sessione ssh verso un altro PC (PC2) e avendo abilitato le funzioni di TCP tunneling avere a disposizione un canale per raggiungere un terzo PC (PC3), che sta ad esempio in una lan dietro PC2, direttamente da PC1.

Diventa quindi importante che l'utente che si connette via SSH possa solo utilizzare le funzioni di tunneling previste e non ad esempio connettersi al PC intermedio, cioè PC2, con una console o cose del genere.

Un modo di realizzare ciò può essere il seguente:

Creare sul PC intermedio (PC2) un utente ad hoc con:

useradd utente1

Non avendo messo password nel file /etc/shadow si vedono solo "!!". Quindi questo utente non dovrebbe riuscire a fare logon locale in quanto non ha una password definita.

Nella directory home dell'utente appena creato va creata la direcotry .ssh e dentro quest'ultima va messo il file authenticated_keys2 in cui deve essere inserita la chiave pubblica per l'utente appena creato.

La coppia di chiavi va creata sul PC da cui ci cercherà di connettersi (PC1)ad esempio con il comando ssh-keygen.

In questo modo è possibile ottenere una sessione ssh autenticandosi tramite le chiavi.

Per impedire all'utente che così si connette di avere l'accesso alla console e di poter lanciare comandi remoti durante il login vanno aggiunte nel file authenticated_keys2 creato precedentemente prima della chiave le due opzioni:

no-pty,command="/bin/bash"

In questo modo l'utente può connettersi, ma non può fare nulla sul PC intermedio. Il comando da mettere può essere uno qualsiasi, ma il richiamo di una shell, senza terminale è una buona idea. Infatti alla sua sessione non viene assegnato un teminale e l'eventuale comando inviato dal client viene sostituito con quello indicato sopra.

Per aumentare ancora la sicurezza è possibile utilizzare altre due opzioni nel file authenticated_keys2: permitopen e from. La prima opzione permette di limitare la destinazione del forward TCP ad host e porte ben determinati. Se l'utente con l'opzione ssh -L chiede un forward TCP ad un server e/o una porta non previste nel file authenticated_keys2, la chiave non verrà utilizzata e l'utente non riuscirà ad autenticarsi (gli viene infatti chiesta la password che non esiste). La seconda opzione (from) permette di indicare una lista di PC da cui è possibile accettare l'utente in questione. Cioè è possibile permettere solo ad alcuni IP (quelli messi nell'elenco) la connessione mediante la chiave.

L'uso di queste 4 opzioni nel file authenticated_keys2 permette di restringere le libertà dell'utente che si connettee di elevare la sicurezza. Ovviamente è possibile restringere e regolare l'accesso ssh anche lato server dove ad esempio è consigliabile disabilitare la possibilità di collegarsi mediante il protocollo versione 1 (a causa di una nota vulnerabilità, spesso cercata da script e pirati informatici in genere) e lasciare solo la versione 2. Altre opzioni lato server ssh sono interessanti ai fini della sicurezza della sessione ssh, ma esulano dallo scopo di questa breve nota.

Ringrazio Diaolin del LinuxTrent per il prezioso aiuto fornitomi.



copyfree/privacy

contatto

curriculum


Ultimo aggiornamento il 14 August 2018 20:18:31.