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.
|