Accesso remoto al proprio computer in una rete eterogenea

Accesso remoto al proprio computer in una
rete eterogenea

Giacomo Antonino Fazio

1

Indice generale
Accesso remoto al proprio computer in una rete eterogenea.....................................................................1
1. Condivisione dei file.........................................................................................................................3
2. Apertura di una shell sul computer remoto ed (eventualmente) esecuzione di qualche applicazione
grafica....................................................................................................................................................3
2.1 Installazione server SSH.............................................................................................................3
2.2 Uso del client SSH......................................................................................................................5
3. Accesso alla sessione grafica corrente da remoto (VNC).................................................................7
3.1 Configurazione del server VNC.................................................................................................7
3.2 Configurazione del client VNC................................................................................................10
3.3 Rendere sicuro VNC tramite SSH (opzionale).........................................................................13
4. Apertura di una nuova sessione grafica...........................................................................................15
4.1 Apertura di una nuova sessione grafica su server Mac OS X...................................................15
4.2 Apertura di una nuova sessione grafica su server Windows.....................................................16
4.3 Apertura di una nuova sessione grafica su server Linux..........................................................18
5. NX e FreeNX...................................................................................................................................20
5.1 Installare il server NX (max 2 connessioni simultanee)...........................................................21
5.2 Installare il server FreeNX (connessioni simultanee teoricamente illimitate ma niente
collegamento alla sessione corrente)..............................................................................................22
5.3 Uso del client............................................................................................................................25
6. Approfondimento: il reverse port forwarding.................................................................................28
6.1 La tecnica..................................................................................................................................28
6.2 Problemi pratici e soluzioni......................................................................................................29

2

Lo scopo di questo articolo è essere una guida rapida per l'accesso remoto al proprio computer. Lo
scenario di riferimento è quello di una rete eterogenea, composta cioè da computer con diversi sistemi
operativi (Linux, Windows e Mac OS X). Quello che vogliamo ottenere è l'accesso ad un computer
(server) dagli altri. Verranno analizzate le varie possibilità (sistemi operativi Linux, Windows e Mac
OS X sia per la parte server che per la parte client).
Per quanto riguarda la tipologia di accesso remoto, esso può avvenire in modi diversi, in base allo
scopo che si intende raggiungere, si va dalla condivisione di file all'apertura di una shell sul computer
remoto, fino ad arrivare all'interazione con il desktop del computer remoto, che fornisce un accesso
quasi completo ad esso.Vediamo di analizzare uno ad uno i diversi casi.

1. Condivisione dei file
Per accedere ai file condivisi dal server basta utilizzare i protocolli di condivisione file esistenti, come
NFS, SMB e AFP. Per informazioni dettagliate, vi rimando alla mia guida Condividere file con PC
Windows, Linux, MacOS X attraverso i protocolli SMB, NFS e AFP, consultabile all'indirizzo
http://www.intilinux.com/linux/691/condivisione-file-in-una-rete-eterogenea-composta-da-pc-con-
windows-linux-macos-x-attraverso-i-protocolli-smb-nfs-e-afp/
Un'alternativa potrebbe essere l'uso del protocollo FTP, accessibile da qualsiasi macchina con
qualunque sistema operativo, mediante appositi programmi come Filezilla o gFTP, da riga di comando,
da browser o dal gestore delle finestre (es. Nautilus in Gnome), gli ultimi due inserendo l'indirizzo
ftp://username:password@151.97.9.181.

2. Apertura di una shell sul computer remoto ed (eventualmente)
esecuzione di qualche applicazione grafica
Se abbiamo bisogno della riga di comando possiamo utilizzare SSH, che ci fornisce una shell remota
potente e sicura: i comandi forniti verranno quindi eseguiti sul computer remoto ma riceveremo l'output
sul client in uso. Più avanti vedremo come SSH permetta di eseguire anche qualche applicazione
grafica.
La prima cosa da fare è installare un server SSH sul server, in modo da consentire ad altre macchine di
connettersi alla propria.

2.1 Installazione server SSH
Per quanto riguarda Linux, molte distribuzioni contengono OpenSSH nei propri repositories, dunque è
possibile installarlo facilmente. Ad esempio, nelle distribuzioni Ubuntu e Debian (e probabilmente
anche molte altre distribuzioni Debian based) è sufficiente utilizzare i comandi:

sudo apt-get update
sudo apt-get install openssh-server openssh-client

In ogni caso è sempre possibile scaricare OpenSSH dal sito http://www.openssh.com e compilarlo
manualmente.

Per quanto riguarda Mac OS X Leopard, questo sistema operativo contiene di default OpenSSH, basta
solo attivarlo: andare in Apple → System Preferences e selezionare la voce Sharing. Da qui abilitare le

3

due voci Remote Login e Remote Management, selezionando All users alla voce Allow access for, come
mostrato dalla figura seguente:

A questo punto sarà possibile accedere al nostro Mac via SSH.

Diverso il caso di Windows, questo sistema operativo non possiede un server SSH integrato, dunque
bisogna usarne uno di terze parti: un esempio è FreeSSHd, gratuito e semplice da utilizzare; al
momento dell'installazione rispondere affermativamente alla richiesta di creazione delle chiavi e alla
richiesta di installazione come servizio (in questo modo sarà avviato automaticamente insieme a
Windows), subito dopo aprire il programma attraverso l'icona nella tray e, dalla tab Users inserire
l'utente da abilitare all'accesso remoto (nel nostro caso Administrator), così come mostrato in figura:

4

N.B. Qualunque sia il sistema operativo installato sul server, per ottenere l'accesso remoto è
necessario che la porta utilizzata da SSH (solitamente la porta 22) sia aperta, dunque verificare
che lo sia dalle impostazioni del proprio firewall.

2.2 Uso del client SSH
Se il client ha un sistema operativo Linux o Mac OS X, basta usare il seguente comando:

ssh -x username@indirizzo dove username e indirizzo vanno sostituiti con i giusti valori

ed inserire la relativa password. L'opzione -x permette di eseguire qualche applicazione “grafica” sul
computer remoto, redirezionando l'output in locale e può essere omessa se non si intende richiamare
applicazioni grafiche.

Se il client ha invece un sistema operativo Windows, è necessario utilizzare un client SSH di terze
parti, ad esempio l'ottimo Putty, scaricabile gratuitamente dal sito
http://www.chiark.greenend.org.uk/~sgtatham/putty . Il programma è semplicissimo da usare, basta
inserire i parametri del server a cui connettersi, cioè indirizzo IP del server e porta da usare, come
mostrato nella seguente figura:

Se si vuole usufruire della possibilità di eseguire applicazioni grafiche redirezionando l'output in locale,
bisogna aprire dal menu di sinistra la voce Connection → SSH → X11 e selezionare la checkbox
Enable X11 forwarding, come mostrato nella figura seguente:

5

Tuttavia è necessario installare sul client un server X, ad esempio Xming, scaricabile da
http://sourceforge.net/projects/xming/
Dopo esserci connessi, vogliamo provare subito la funzionalità di X: se ad esempio ci siamo connessi
ad un server Ubuntu e scriviamo il comando gedit, avremo l'output sulla nostra macchina Windows,
come mostra la figura seguente.

6

N.B. Solo le applicazioni grafiche che utilizzano il server X funzioneranno, dunque se avvieremo
notepad dopo esserci connessi ad un server Windows oppure TextEdit dopo esserci connessi ad un
server Mac OS X, non riceveremo nessun output oppure esso sarà visualizzato sulla macchina
remota.

3. Accesso alla sessione grafica corrente da remoto (VNC)
Se si vuole un controllo maggiore sul server che include l'esecuzione di applicazioni grafiche e il
controllo del desktop, bisogna ricorrere a soluzioni più sofisticate. Stiamo parlando del protocollo VNC
(Virtual Network Computing), che permette di controllare il desktop da remoto, inviando input e
ricevendo l'output, dunque consente di accedere alla sessione correntemente aperta. Se invece si
vogliono aprire nuove sessioni (non sempre è possibile), passare al capitolo 4.
VNC è un sistema per la condivisione del desktop che utilizza il protocollo RFB allo scopo di
amministrare il proprio computer a distanza: installando un server VNC sulla propria macchina ed
impostando un'opportuna password si consente ai client VNC di ricevere un'immagine dello schermo e
di inviare input di tastiera e mouse al server; in pratica si può gestire il server da un'altra postazione,
come se fosse il proprio computer fisico. Il protocollo RFB, usato da VNC, è molto semplice, basato su
una primitiva grafica inviata dal server al client (“Disegna un rettangolo di pixel alla posizione X,Y
specificata”), tenendo conto che l'immagine deve essere via via aggiornata. Tuttavia, questo fa sì che
VNC, nella sua forma più semplice, utilizzi spesso molta banda, ecco perché sono stati messi a punto
diversi meccanismi per ridurre l'overhead di comunicazione. Ad esempio è possibile inviare solo i
rettangoli che cambiano tra un frame e il successivo, ma questo meccanismo ovviamente funziona bene
solo se una piccola porzione di schermo è cambiata (ad esempio il puntatore del mouse che si è
spostato o un carattere che è stato scritto), mentre perdiamo quasi tutti i vantaggi se ad esempio
vogliamo vedere un video oppure spostare una finestra. La conseguenza ovvia è che VNC dà il meglio
di sé nel caso in cui si utilizzi una connessione a banda larga (connessione LAN, ADSL, ecc.).
Per quanto riguarda l'aspetto sicurezza, di default VNC non è sicuro, in quanto i dati sono trasmessi in
chiaro. Tuttavia è possibile renderlo sicuro effettuandone il tunneling su una connessione SSH o VPN,
in modo che i dati vengano inviati in un tunnel interamente cifrato (lo vedremo nel paragrafo 3.3).
VNC può essere utilizzato su Linux anche per creare nuove sessioni alle quali accedere, tuttavia in
questo paragrafo parleremo soltanto dell'accesso alla sessione corrente, cioè il cosiddetto “desktop
sharing”.
N.B. Se il server a cui connettersi utilizza Linux, conviene lasciar perdere VNC e passare a NX
(vedi capitolo 5), per completezza l'uso di VNC verrà comunque trattato anche su Linux.

3.1 Configurazione del server VNC
La prima cosa da fare è abilitare un server VNC sul proprio server, in modo da consentire la
connessione dall'esterno.

Per quanto riguarda Linux, un ottimo programma è vino, fornito di default con molte distribuzioni tra
cui Ubuntu, ed installabile sulle distribuzioni Debian like con i comandi

sudo apt-get update
sudo apt-get install vino

7

Dopo aver installato il programma, basta andare nel menu System → Preferences e avviare Remote
Desktop, che permette di configurare facilmente il desktop sharing, come mostrato nella finestra
seguente:

Si consiglia di inserire una password per sicurezza e di lasciare come porta la 5900 (opzione di default).
Un'altro programma che è possibile utilizzare su Linux, soprattutto se si utilizza KDE, è krfb,
installabile mediante il comando

sudo apt-get update
sudo apt-get install krfb

Per quanto riguarda l'attivazione del server VNC in Mac OS X, andare in Apple → System Preferences
e selezionare la voce Sharing. Da qui abilitare le due voci Remote Login e Remote Management,
selezionando All users alla voce Allow access for, come mostrato dalla figura seguente:

8

Fare quindi click sul pulsante Computer Settings indicato dalla freccia, e abilitare le voci mostrate nella
seguente figura:

Inserire una password sicura nell'apposito campo. Abbiamo così attivato il server VNC presente su Mac
OS X. Un'altra possibilità sarebbe affidarsi all'ottimo Apple Remote Desktop 3, che si basa su VNC ma
è una soluzione proprietaria e commerciale di Apple, potente ma non gratuita, quindi non è il caso di

9

utilizzarla se non per esigenze particolari, dato che è facilmente sostituibile per le comuni esigenze.

Per quanto riguarda Windows, anche in questo caso bisogna come al solito sfruttare programmi di terze
parti. La scelta non manca di certo, esistono TightVNC, RealVNC e molti altri, tutti dotati di interfaccia
grafica intuitiva.

N.B. Qualunque sia il sistema operativo installato sul server, è necessario che la porta utilizzata
dal server VNC (ad esempio la porta 5900) sia aperta, dunque verificare che lo sia dalle
impostazioni del proprio firewall.

3.2 Configurazione del client VNC
Dopo aver eseguito correttamente la connessione SSH, è necessario utilizzare un client VNC.
Nel caso di Mac OS X un ottimo client VNC è Chicken of the VNC, se si utilizza Windows è possibile
utilizzare UltraVNC Viewer, mentre se siamo su Unix/Linux la scelta è molto più ampia: tra i numerosi
client VNC che ho provato, uno dei migliori è sicuramente Krdc, ma in caso di problemi è possibile
affiancarlo a Remote Desktop Viewer (Vinagre) o Terminal Server client, installabili tramite i comandi
(se usiamo una distrubuzione Debian/Ubuntu o simili)

sudo apt-get update
sudo apt-get install krdc vinagre tsclient

Consideriamo solamente il caso Linux, dato che i client VNC sono comunque molto semplici da usare
e si differenziano di poco da quello che vedremo.
Avviamo Remote Desktop Viewer (Vinagre) e clicchiamo sul primo pulsante, avremo una schermata
simile a questa:

10

Inserire l'indirizzo dell'host e la porta (ad esempio 5901; 5900 se abbiamo usato vino o krfb con le
impostazioni di default). Dovremmo ottenere rispettivamente schermate simili a queste:

11

Se è così ed è possibile interagire con i desktop remoti, tutto funziona a dovere.

12

Alcune considerazioni infine sull'uso di VNC: purtroppo esso non è esente da bug o da caratteristiche
che potrebbero essere meglio implementate.
Ad esempio ci potrebbero essere inizialmente problemi di risoluzione (spesso troppo piccola), che
comunque possono essere corretti semplicemente adattando la risoluzione dall'apposito menu del
sistema operativo che si sta controllando.
Un altro problema è dovuto al fatto che a volte qualche client VNC non riesce a connettersi al server
VNC richiesto, in tal caso basta cambiare client VNC oppure diminuire leggermente la qualità della
connessione utilizzata dalle impostazioni di VNC.
Un altro problema abbastanza fastidioso si presenta nel caso in cui non si utilizza una tastiera
americana e si ottiene una mappatura dei tasti non corrispondente a quella realmente utilizzata (sembra
che chi ha implementato VNC non abbia tenuto conto del fatto che al mondo esistono numerosi layout
di tastiera oltre a quello americano). A niente valgono i tentativi di sistemare il layout sul sistema
operativo controllato. Sembra ci sia tuttavia un workaround, basta selezionare il layout della tastiera
americana sul proprio computer e assicurarsi che sul computer controllato sia selezionato il layout della
tastiera realmente utilizzata (nel nostro caso quella italiana, Italian Pro per Mac OS X). A questo
proposito è molto semplice switchare sul proprio computer tra il proprio layout e quello americano: su
Windows basta utilizzare la barra della lingua e switchare mediante la combinazione Left Alt+Left
Shift, su Mac OS X basta installare dalle preferenze di sistema entrambi i layout e abilitare la presenza
dell'icona di scelta rapida nella barra in alto, quindi switchare direttamente da questa icona, su Linux
basta installare entrambi i layout e aggiungere al pannello di Gnome l'applet Keyboard Indicator.

3.3 Rendere sicuro VNC tramite SSH (opzionale)
Possiamo dire che VNC non offre sicurezza, considerando che le informazioni sono inviate in “plain
text”. Per ovviare a questo problema è possibile incapsulare il traffico di VNC all'interno di un tunnel
SSH, che cifri le informazioni per rendere "sicura" la connessione. L'idea di base è schematizzata nella
figura seguente:

VNC client VNC server

Client Server

SSH client SSH server

Negli esempi finora visti il client VNC si connette direttamente al server VNC, con i problemi di
sicurezza che ne derivano. Adesso invece creeremo una connessione SSH tra il client e il server e
faremo in modo che il client VNC mandi le sue informazioni al client SSH, che le invia tramite una
connessione cifrata al server SSH, che a sua volta le trasferisce al server VNC. Per ottenere tutto ciò
nbisogna effettuare i seguenti passaggi:

1) Configurazione del server VNC
2) Creazione connessione SSH tra client e server: effettuare la connessione SSH al server,
facendo in modo che una porta locale sia redirezionata sulla porta del server su cui ascolta il
server VNC (ad esempio la 5901), in modo che ad esempio una chiamata locale alla porta 5901
abbia l'effetto di chiamare il server alla porta 5901.

13

3) Uso del client VNC: con la connessione SSH effettuata al punto 1) ancora aperta, bisogna
aprire il client VNC che utilizziamo ed inserire come indirizzo localhost, specificando come
porta quella stabilita al punto precedente che redirezionerà i dati sulla porta remota su cui
ascolta il server VNC.

Vediamo adesso più nel dettaglio come effettuare queste operazioni.
La parte server è identica a quanto specificato nel paragrafo 3.1.
Per quanto riguarda il client la prima cosa da fare è creare il tunnel SSH. Dobbiamo in pratica effettuare
la connessione SSH al server, facendo in modo che una porta locale sia redirezionata sulla porta remota
usata dal server VNC. Occorre comunque verificare prima che la porta locale da usare non sia già usata
da qualche altro servizio (ad esempio un server VNC attivo sul nostro client), in tal caso dobbiamo
scegliere un'altra porta locale, ad esempio la 5910.
Se abbiamo un client con sistema operativo Unix/Linux o Mac OS X eseguire il comando
ssh -N -f -L local_port:server_address:VNC_remote_port username@server_address

dove a server_address, username, local_port e remote_port bisogna sostituire i propri dati, ad esempio
ssh -N -f -L 5901:192.168.0.2:5901 pippo@192.168.0.2
(in questo caso abbiamo creato un tunnel SSH al server 192.168.0.2, redirezionando la porta locale
5901 sulla porta remota 5901; i parametri -N e -f fanno sì che il comando SSH appena lanciato venga
usato semplicemente per creare il tunnel e vada poi in background).
Per quanto riguarda l'uso di SSH con Windows, questo sistema operativo, al contrario di Linux e Mac
OS X, non dispone di un client SSH, dunque è necessario installarne uno di terze parti, ad esempio
l'ottimo Putty (scaricabile gratuitamente da http://www.chiark.greenend.org.uk/~sgtatham/putty/). Il
programma è semplicissimo da usare, basta inserire i parametri del server a cui connettersi. Un'unica
nota riguarda come attivare il port forwarding: fare clic nel menu a sinistra sulla voce Connection →
SSH → Tunnels ed inserire ciascuna regola nei due campi Source Port e Destination, come mostrato
nella figura seguente per la porta 5902 e cliccare sul pulsante Add per aggiungere la regola.

14

Alla fine fare clic sul pulsante Open per aprire la connessione. E' anche possibile salvare il profilo
corrente in modo da poterlo caricare facilmente ad ogni avvio di Putty. Per fare questo, dopo aver
impostato tutte le regole e l'indirizzo a cui connettersi, selezionare dal menu a sinistra la voce Session.
Nella sezione Saved sessions presente sulla destra, scrivere il nome da assegnare al profilo corrente, ad
esempio appleserver e premere Save, come mostrato in figura:

Al prossimo avvio sarà possibile caricare il profilo appleserver selezionandolo da questa finestra e
premendo poi Load.

Adesso dobbiamo utilizzare il client VNC. Vale quanto detto nel paragrafo 3.2, con l'eccezione che
questa volta l'indirizzo a cui connettersi è localhost, mentre la porta è quella locale, che redirezionerà i
dati automaticamente alla porta remota su cui ascolta il server VNC. Questo comporta che, non solo
avremo la nostra connessione VNC resa sicura da SSH, ma anche che per il server VNC la connessione
arriverà dall'interno, perciò non sarà più necessario aprire mediante il firewall la porta utilizzata (anzi
verificare che sia chiusa, dato che la sua apertura non ci serve più e potrebbe causare problemi di
sicurezza).

4. Apertura di una nuova sessione grafica
Tramite questa modalità è possibile aprire una nuova sessione sulla macchina remota che verrà
visualizzata in locale. Tuttavia questo non è sempre possibile, in ogni caso le tecnologie utilizzate
cambiano in base al sistema operativo usato dal server, quindi in questo capitolo la distinzione verrà
fatta in base a questo parametro.

4.1 Apertura di una nuova sessione grafica su server Mac OS X
Per quanto riguarda Mac OS X, per il momento non mi sembra sia possibile aprire una nuova sessione
remota, quindi l'unica possibilità rimane l'uso di VNC per connetterci alla sessione corrente.

15

4.2 Apertura di una nuova sessione grafica su server Windows
Su piattaforma Windows possiamo utilizzare il protocollo RDP (Remote Desktop Protocol), sviluppato
da Microsoft per connettersi a computer che implementano Microsoft Terminal Services. Quest'ultimo
è il componente che si occupa di permettere il controllo del desktop da remoto e, nelle versioni Server
di Windows, consente l'apertura di sessioni remote concorrenti.
Questa soluzione sembra funzionare egregiamente, tuttavia si tratta di una soluzione proprietaria e
chiusa e, come ci si aspetterebbe, non gratuita, o almeno non completamente, anche se la politica
seguita spesso varia in base alle versioni di Windows. Ad esempio, per la versione 2003 Server, oltre
alla licenza del server è infatti necessario munirsi di una Client Access License (CAL), che va
acquistata e legata all'utente che si connette (Per user) o al dispositivo utilizzato per connettersi (Per
device). Senza una licenza CAL, è possibile avere solo tre connessioni remote simultanee, che a
seconda dei casi, potrebbero essere sufficienti ma potrebbero anche non bastare. Vediamo come attivare
sul nostro server Windows il supporto a Remote Desktop, prendendo come esempio un server Windows
2003 Server (la procedura dovrebbe essere pressochè identica in Windows XP). Andare in Pannello di
controllo → Sistema e selezionare la tab Remote, abilitando in essa la checkbox Enable Remote
Desktop on this computer, come mostrato nella figura seguente.

Fare clic sul pulsante Select Remote Users..., poi sul pulsante Add e scivere nella textbox indicata dal
riquadro il nome dell'utente da abilitare alla connessione remota (in questo caso Administrator):

16

Dare OK un paio di volte per salvare il tutto. A questo punto l'utente Administrator è abilitato alla
connessione da remoto.

Tenendo conto delle limitazioni di cui abbiamo già parlato sul massimo numero di connessioni
simultanee, a questo punto ci serve un client per aprire una nuova sessione sul server Windows.
Se il client è una macchina Windows o Mac OS X, è possibile sfruttare il programma Remote Desktop
Connection Client fornito gratuitamente da Microsoft, mentre se il client è Linux un ottimo programma
è Remote Desktop Client, installabile su distribuzioni Debian/Ubuntu o simili tramite i seguenti
comandi:

sudo apt-get update
sudo apt-get install rdesktop

Per testare il corretto funzionamento, prendiamo come esempio il caso Linux, utilizzando quindi il
software Remote Desktop Client. Otterremo una schermata simile a questa:

17

Inserire l'indirizzo del server, lo username dell'utente abilitato e la relativa password, selezionare
dall'elenco Windows XP/2003 ed eventualmente modificare i parametri presenti nelle altre tab del
programma. Subito dopo premere il pulsante Execute. Dovremmo ottenere una schermata simile a
questa:

Se è così ed è possibile interagire con il desktop di Windows, allora tutto funziona correttamente.

4.3 Apertura di una nuova sessione grafica su server Linux
Per quanto riguarda Linux, grazie all'architettura client-server di X abbiamo a disposizione più di una
soluzione per aprire nuove sessioni da remoto.
La soluzione più semplice è utilizzare lo stesso VNC, ma non è certo la soluzione migliore, in quanto
esiste il protocollo NX, superiore a VNC sotto ogni punto di vista, quindi conviene saltare questo
paragrafo e passare direttamente al capitolo 5. Tuttavia per completezza vedremo di seguito l'uso di
VNC su server Linux.
Il programma da installare sul server si chiama TightVNC, ed è possibile installarlo facilmente nelle
distribuzioni Debian/Ubuntu o simili mediante i comandi

18

sudo apt-get update
sudo apt-get install tightvncserver

TightVNC utilizza di default le porte TCP a partire dalla 5901, ognuna delle porte usate corrisponde a
un desktop separato (:2 ad esempio corrisponde alla porta 5902), tuttavia è possibile configurarlo anche
in altri modi.
tightvncserver funziona solo da riga di comando, quando viene lanciato si occupa di creare un
desktop virtuale a cui è possibile collegarsi.
Nella creazione del desktop virtuale, viene seguito quanto specificato nel file ~/.vnc/xstartup , dove
~ indica la propria home. Spesso tale file è configurato in modo tale che il desktop virtuale creato non
utilizzi Gnome o KDE, ma un DE più leggero, tuttavia se si sostituisce il contenuto di tale file con le
seguenti due righe, dovremmo poter accedere a Gnome:

unset SESSION_MANAGER
exec /usr/bin/dbus-launch --exit-with-session gnome-session

In maniera simile dovrebbe essere possibile accedere a KDE.
Da poco tempo è possibile utilizzare TightVNC mediante una comoda interfaccia grafica, Py-
TightVNC, creata da due studenti dell'Università di Catania, Giuseppe Moscato e Giovanni Altamore,
sotto la mia supervisione. Il programma è tuttora in via di sviluppo, quindi è possibile trovare ancora
qualche bug, ma sicuramente raggiunge l'obiettivo che si prefigge. Il programma è scaricabile alla
homepage http://py-tightvnc.sourceforge.net/, trovate una recensione con una guida rapida all'uso nel
sito http://www.intilinux.com/programmazione/791/py-tightvnc-gui-per-tightvnc-su-linux/ , mentre il
manuale d'uso è presente al link http://repo.intilinux.com/doc/py-tightvnc_relazione.pdf . In questa
sede mostreremo solo qualche schermata per spiegare come funziona:

19

Il pulsante New Desktop crea appunto un nuovo desktop virtuale, mostrato nella finestra seguente:

Il pulsante Kill che si trova accanto al numero del desktop permette di eliminarlo. Cliccando più volte
su New Desktop vengono creati di seguito desktop successivi. Infine il pulsante Kill all uccide tutti i
desktop attivi.
Per quanto riguarda il client, vale quanto esattamente quanto detto nel paragrafo 3.2, basta specificare
nel client l'indirizzo del server a cui connettersi e la porta (es. 5901 per il desktop :1, 5902 per il
desktop :2 e così via).

5. NX e FreeNX
NX è un protocollo sviluppato dall'azienda italiana NoMachine, che permette di eseguire sessioni
remote di X attraverso un client prodotto dalla stessa NoMachine che gira su sistemi operativi Linux,
Windows, Mac OS X e Solaris. Inoltre vengono attuate delle sapienti politiche di compressione del
traffico X e di gestione della cache, evitando gli scambi di dati inutili ed attuando un controllo di flusso
che permette una gestione delle sessioni remote che funziona ottimamente anche su computer collegati
con reti lente. Ma le caratteristiche che fanno di NX un protocollo veramente appetibile sono:
possibilità di connessione ad una sessione già aperta (session shadowing), possibilità di aprire una
nuova sessione, possibilità di disconnettersi da una sessione senza terminarla (session persistence), in
modo che i programmi lanciati continuino a girare e che sia possibile riconnettersi a quella sessione in
futuro anche da un'altra macchina, file sharing e printing support, possibilità di incapsulare connessioni
VNC e RDP, sicurezza grazie all'uso di SSH per cifrare le connessioni. Una descrizione più
approfondita esula dagli scopi di questo articolo, tuttavia è possibile avere un'idea abbastanza
dettagliata del funzionamento di NX dando un'occhiata al sito di NoMachine e in particolare alla
pagina http://www.nomachine.com/documents/getting-started.php

20

Come abbiamo già detto, i client sono disponibili gratuitamente per tutte le piattaforme, mentre il
server è per il momento presente solo per Linux. In particolare, il server si può trovare nella versione
free (gratuita, ma limitata, in quanto consente la connessione simultanea di massimo due utenti),
oppure in altre versioni via via meno limitate ma sempre più costose. Le impressioni derivate
dall'utilizzo della versione free sono ottime, il sistema è reattivo e sembra quasi di lavorare in locale,
inoltre la funzione di “session persistence” funziona benissimo (se ci si disconnette dalla sessione in
corso senza terminarla e si lascia qualche processo in esecuzione, esso continuerà ad essere eseguito e
ad una successiva riconnessione sarà possibile vederne i progressi).
Ma c'è di più. NoMachine ha infatti abbracciato il concetto di open-source, mettendo a disposizione
sotto licenza GPL il codice sorgente dei tools e delle librerie (components) della propria tecnologia.
Questo ha favorito il miglioramento di tali tecnologie, e ha anche permesso la creazione di FreeNX,
ossia un server open-source per NX e completamente free, quindi senza le limitazioni riguardanti il
numero massimo di utenti presenti nella versione free del server originale di NoMachine. FreeNX
funziona egregiamente, anche se non ai livelli del server originale, soprattutto perchè qualche
funzionalità non funziona ancora correttamente, come la connessione ad una sessione già aperta, che
deve ancora essere implementata; è inoltre compatibilissimo con i client ufficiali forniti da NoMachine
gratuitamente per tutte le piattaforme.
Tenuto conto di questi fattori, la scelta tra NX e FreeNX dipende dall'uso che si intende fare di questa
tecnologia: per un uso domestico sicuramente è consigliabile usare la versione free del server di
NoMachine (2 connessioni remote simultanee dovrebbero essere sufficienti), ma se invece è necessario
avere a disposizione molte connessioni remote simultanee conviene orientarsi verso FreeNX, dato che
non ha limitazioni sul numero di utenti che possono connettersi e funziona comunque egregiamente,
rinunciando tuttavia alla possibilità di connettersi alla sessione corrente (per quello si può sempre
utilizzare un server VNC come vino). Analizziamo i due casi uno alla volta.

5.1 Installare il server NX (max 2 connessioni simultanee)
È necessario scaricare ed installare i programmi NXClient, NXNode e NXServer dal sito di NoMachine,
dalla sezione NX Free Edition for Linux ed installarli seguendo questo ordine. E' presente sia la
versione a 32 che a 64 bit, inoltre oltre ai sorgenti è possibile scaricare direttamente i file .rpm e .deb in
base alla distribuzione utilizzata (nel caso di Debian/Ubuntu e simili scaricare i .deb).
Tenere presente che è necessario avere installato un server SSH: molte distribuzioni contengono
OpenSSH nei propri repositories, dunque è possibile installarlo facilmente. Ad esempio, nelle
distribuzioni Ubuntu e Debian (e probabilmente anche molte altre distribuzioni Debian based) è
sufficiente utilizzare i comandi:

sudo apt-get update
sudo apt-get install openssh-server openssh-client

In ogni caso è sempre possibile scaricare OpenSSH dal sito http://www.openssh.com e compilarlo
manualmente.
Dopo l'installazione, è possibile avviare il server mediante il comando

sudo /usr/NX/bin/nxserver --install

e se tutto va per il verso giusto, il comando

21

sudo /usr/NX/bin/nxserver --status

dovrebbe darci il seguente output:

NX> 900 Connecting to server ...
NX> 110 NX Server is running.
NX> 999 Bye.

5.2 Installare il server FreeNX (connessioni simultanee teoricamente
illimitate ma niente collegamento alla sessione corrente)
La sua installazione richiede download e installazione di NXClient, NXNode e dei components open-
source messi a disposizione da NoMachine, tuttavia è necessario installare una versione più vecchia di
essi, in quanto lo sviluppo di FreeNX procede un po' più a rilento rispetto a quello dei componenti di
NoMachine e non sembra funzionare con le ultime versioni di essi.
Le istruzioni per installare FreeNX sulla macchina virtuale Ubuntu sono state prese dal sito
http://www.felipe-alfaro.org/blog/2007/11/24/installing-freenx-071-on-ubuntu/ , riadattate alla nostra
situazione e aggiornate e vengono qui riportate:

Installazione dei componenti binari di base di NoMachine
Diventare root mediante il comando
sudo -s

spostarsi in /usr
Lanciare i seguenti comandi:
wget e poi tar zxvf repo/nxserver-3.0.0-79.x86_64.tar.gz
wget e poi tar zxvf repo/nxclient-3.0.0-84.x86_64.tar.gz
wget e poi tar zxvf repo/nxnode-3.0.0-93.x86_64.tar.gz

Compilazione delle librerie di compressione NX
Estrarre nxcomp mediante il comando:
wget e poi tar zxvf repo/nxcomp-3.0.0-48.tar.gz

Installare alcuni pacchetti (propedeutici per il ./configure di nxcomp) mediante il comando:
apt-get install zlib1g-dev libX11-dev libjpeg-dev libpng12-dev x11proto-xext-dev libxdamage-
dev libxrandr-dev libxtst-dev libaudiofile-dev

Eseguire i seguenti comandi:
cd nxcomp
./configure --prefix=/usr/NX
make
cp -P libXcomp.so* /usr/NX/lib

22

Adesso è il turno di nxcompext, nx-X11 e la patch Nxlib-xgetioerror.patch. Estrarre i file mediante i
seguenti comandi:

wget e poi tar zxvf /home/ubuntu/Downloads/Linux/FreeNX/nxcompext-3.0.0-18.tar.gz
wget e poi tar zxvf /home/ubuntu/Downloads/Linux/FreeNX/nx-X11-3.0.0-37.tar.gz

Applicare la patch mediante il comando:
cd nxcompext
wget e poi patch -p0 < /home/ubuntu/Downloads/Linux/FreeNX/Nxlib-xgetioerror.patch

Eseguire i seguenti comandi:

./configure --x-includes="/usr/include/xorg -I/usr/include/X11" --prefix=/usr/NX
make
cp -P libXcompext.so* /usr/NX/lib

Adesso decomprimere nxcompshad, mediante il comando

wget e poi tar zxvf /home/ubuntu/Downloads/Linux/FreeNX/nxcompshad-3.0.0-19.tar.gz

ed eseguire i seguenti comandi:
cd nxcompshad
make
cp -P libXcompshad.so* /usr/NX/lib

L'ultimo componente è nxesd, estrarlo mediante il comando

wget e poi tar zxvf /home/ubuntu/Downloads/Linux/FreeNX/nxesd-3.0.0-4.tar.gz

ed eseguire i seguenti comandi:

cd nxesd
make
make install

Adesso è arrivato il momento di installare FreeNX 0.7.2, estrarlo mediante il comando

wget e poi tar zxvf /home/ubuntu/Downloads/Linux/FreeNX/freenx-server-0.7.2.tar.gz

ed applicare la patch gentoo-nomachine.diff mediante i comandi

cd freenx-server-0.7.2
patch -p0 < gentoo-nomachine.diff

Adesso bisogna sostituire i file di FreeNX a quelli di NoMachine presenti in /usr/NX/bin:
cp -f nxkeygen /usr/NX/bin/

23

cp -f nxloadconfig /usr/NX/bin/
cp -f nxnode /usr/NX/bin/
cp -f nxnode-login /usr/NX/bin/
cp -f nxserver /usr/NX/bin/
cp -f nxsetup /usr/NX/bin/
cp -f nxcups-gethost /usr/NX/bin/

Compilare adesso nxserver-helper, mediante i comandi
cd nxserver-helper
make
cp -f nxserver-helper /usr/NX/bin/

Adesso dobbiamo installare alcuni pacchetti:
apt-get install expect smbfs openssh-server

Adesso bisogna creare dei link simbolici:
ln -sf /usr/NX/bin/nxserver /usr/bin/nxserver
ln -sf /usr/NX/bin/nxsetup /usr/sbin/nxsetup
ln -sf /usr/NX/bin/nxloadconfig /usr/sbin/nxloadconfig
ln -sf /usr/NX/lib/libXrender.so.1.2.2 /usr/NX/lib/libXrender.so.1.2
ln -sf /usr/NX/bin/nxagent /usr/NX/bin/nxdesktop
ln -sf /usr/NX/bin/nxagent /usr/NX/bin/nxviewer
ln -sf /usr/bin/foomatic-ppdfile /usr/lib/cups/driver/foomatic-ppdfile
ln -sf /etc/X11/xinit /etc/X11/xdm
ln -sf /sbin/mount.cifs /sbin/smbmount
ln -sf /sbin/umount.cifs /sbin/smbumount

A questo punto installare FreeNX, mediante il comando
nxsetup --install

Tale comando si occuperà di effettuare l'installazione e la creazione dell'utente nx. Alla richiesta se
usare o meno le chiavi di NoMachine si può tranquillamente rispondere di sì (scelta di default), in
quanto già così il sistema è abbastanza sicuro, tuttavia si può anche usare una chiave appositamente
generata e in questo caso ogni client che vuole connettersi al server FreeNX deve possedere questa
chiave. Prima di poter usare FreeNX è comunque necessario creare il file node.conf che contiene la
configurazione di FreeNX, conviene crearlo dal file di default:
cd freenx-server-0.7.2
cp node.conf.sample /usr/NX/etc/node.conf

Editare il file node.conf appena creato sistemando eventualmente i settaggi. Le parti che si potrebbero
modificare sono le seguenti:
SESSION_LIMIT=200

SESSION_USER_LIMIT=200

DISPLAY_LIMIT=200

ENABLE_CLIPBOARD="both"

24

NX_LOG_LEVEL=3

NX_LOG_SECURE=1

NX_LOGFILE=/var/log/nxserver.log

L'installazione di FreeNX è terminata e a questo punto sarà possibile connettersi.

5.3 Uso del client
A questo punto occorre procurarsi un client, come già detto vanno benissimo i client offerti
gratuitamente da NoMachine, presenti praticamente per ogni piattaforma e scaricabili dal loro sito (per
le distribuzioni Debian/Ubuntu utilizzare il file .deb, per le altre compilare il file sorgente). Adesso
spiegherò come utilizzare il client su Linux, tuttavia le seguenti informazioni valgono per tutte le
piattaforme supportate, dato che i client sono identici.
Dopo aver scaricato ed installato il file .deb, avviare NX Connection Wizard (nella mia Ubuntu si trova
nel menu Applications → Internet → NX Client for Linux). Dopo la pagina di benvenuto, avremo una
schermata dove inserire alcune informazioni, cioè un nome da dare alla sessione, l'indirizzo dell'host e
della porta, nonché il tipo di connessione, come mostrato nella figura seguente:

Premere Next. Nella schermata successiva occorre selezionare i parametri giusti in base alla
configurazione del server, ad esempio:

25

In questo modo creeremo una nuova sessione.
Se invece di Unix selezioniamo Shadow nella finestra precedente, sarà possibile connettersi ad una
sessione già presente (questa funzione non funzionerà se il server è FreeNX).
La schermata successiva permette di scegliere se avere o meno un'icona sul desktop che punti
direttamente alla connessione (è possibile evitarlo, in tal caso per richiamare il client bisognerà
scegliere dal menu la voce “NX Client” e selezionare da un elenco la sessione richiesta) e se si vuole
aprire la finestra delle impostazioni avanzate (richiamabile eventualmente anche in un secondo
momento).

Le impostazioni di default nella finestra delle impostazioni avanzate vanno già bene, al più abilitare
SMB printing e Multimedia support dalla tab Services.
Proviamo adesso la connessione, richiamabile dall'icona sul desktop (se l'avete creata) oppure da NX
Client for Linux, selezionabile dal menu Applications → Internet → NX Client for Linux.

26

Inserire nome utente e password dell'utente presente sul server, cambiare eventualmente le
impostazioni dalla voce Configure e infine premere Login.
Nel giro di alcuni secondi dovremmo vedere sul nostro schermo la nuova sessione creata sul server e
poter interagire con essa in modo fluido e quasi naturale:

Al momento di terminare il nostro lavoro con questa sessione, se clicchiamo sulla X di chiusura della
finestra potremo scegliere se terminare la sessione o disconnetterci semplicemente: in quest'ultimo caso
la sessione continuerà ad essere attiva e i lavori lanciati continueranno ad essere eseguiti, con
possibilità di riconnessione futura.
Se invece dalle impostazioni di connessione abbiamo scelto Shadow, otterremo una finestra che elenca
le sessioni attive, da cui bisogna scegliere quella a cui collegarsi (questa funzione non funzionerà se il
server è FreeNX, inoltre non otterremo la stessa qualità di una nuova sessione).
Un'ultima funzione che risulta interessante è l'incapsulamento di RDP e VNC in NX. NX supporta RDP

27

e VNC richiamando il client giusto (rdesktop o il client VNC) direttamente dalla sessione X. Questo
permette una maggiore efficienza, in quanto le stesse tecniche di compressione e di sicurezza utilizzate
da NX possono essere applicate anche a questi casi, sebbene non si abbia lo stesso livello di efficienza.
Praticamente per effettuare questo si utilizza il normale client NX che deve connettersi ad un server NX
che poi andrà a richiamare il client RDP o VNC. Per approfondire il funzionamento di questo aspetto,
si rimanda al sito di NoMachine.

6. Approfondimento: il reverse port forwarding
Tutte le operazioni viste finora presuppongono che le porte del server relative ai servizi descritti siano
aperte per i client che vogliono utilizzare tali servizi.
Supponiamo invece di trovarci nel caso in cui tali porte siano aperte solo per un gruppo di client: siamo
ad esempio sul posto di lavoro e possiamo accedere al server solo da qui, vorremmo poterlo fare anche
da casa (ovviamente abbiamo il permesso ;-)). Se avessimo un IP fisso il problema non si porrebbe,
perchè basterebbe aprire le porte dal firewall del server anche per tale IP. Ma con un indirizzo IP
dinamico come si fa? Potremmo utilizzare un servizio come DynDNS o no-IP, che ci danno un nome di
host fisso collegato volta dopo volta all'IP che stiamo utilizzando (basta aggiornarne il collegamento
dal sito del servizio oppure utilizzare uno dei programmi che fa questo automaticamente), ma non
sempre il firewall permette di specificare un hostname e richiede invece un indirizzo IP, in tal caso non
avremmo risolto nulla. Potremmo ancora utilizzare un proxy che si trova sul posto di lavoro e quindi
può accedere al server e che nello stesso tempo sia accessibile anche da casa nostra, ma non sempre
questo è fattibile.
Come risolviamo dunque? Attraverso il reverse port forwarding, ovvero se non possiamo entrare noi
direttamente nel server, facciamoci chiamare da lui :-)

6.1 La tecnica
L'idea è questa: creiamo una connessione SSH tra il server e il nostro client, redirezionando alcune
porte del nostro client sul server. Questo è il comando da lanciare sul server:
ssh -N -f -R remote_port:local_address:local_port remote_username@remote_address

dove a remote_port, local_address, local_port, remote_username e remote_address bisogna sostituire i
propri dati, ad esempio
ssh -N -f -R 5555:192.168.0.1:22 -R 5910:192.168.0.1:5901 pippo@192.168.0.33

In questo caso abbiamo creato una connessione SSH tra il server (con indirizzo 192.168.0.1) e il nostro
client (che ha indirizzo 192.168.0.33 e username pippo), redirezionando le porte remote (quindi del
nostro client) 5555 e 5910 rispettivamente sulle porte locali (quindi sul server) 22 e 5901 (porte su cui
abbiamo in ascolto rispettivamente un server SSH e un server VNC); volendo si possono aggiungere
anche altre porte; i parametri -N e -f fanno sì che il comando SSH appena lanciato venga usato
semplicemente per fare il redirecting e vada poi in background.
Instaurata la connessione (dopo aver inserito la password e tutte le informazioni necessarie), a questo
punto potremo lanciare sul nostro client un comando del genere

28

ssh -p 5555 server_username@localhost

(server_username e la password richiesta al lancio del comando sono ovviamente quelli del server) e
avremo una shell SSH sul server controllabile dal nostro client dovunque ci troviamo, anche da casa,
bypassando così il firewall del server. Inutile dire che se sul server c'è Linux e FreeNX, possiamo
utilizzare la connessione SSH per aprire una nuova sessione grafica sul server! Allo stesso modo, sul
nostro client possiamo aprire un client VNC ed inserire come hostname localhost e come porta la 5910,
per poter controllare lo schermo del server a distanza.
Da notare la somiglianza con gli altri comandi SSH visti nel corso di questo tutorial, solo che lì si
usava l'opzione -L (per redirezionare le porte locali su quelle remote), qui al contrario si usa l'opzione -
R (per redirezionare le porte remote su quelle locali).
Questa è la spiegazione della tecnica, adesso bisogna risolvere alcuni problemini pratici.

6.2 Problemi pratici e soluzioni
Il primo problema che viene fuori è il fatto che la connessione SSH si interrompe per mille motivi (ad
esempio se spegnamo il client), una volta che siamo a casa dovremmo chiamare un amico sul posto di
lavoro e chiedergli di lanciare il comando di SSH, passandogli ovviamente il nostro indirizzo IP
dinamico del momento, nome utente e password: scomodo, non sempre possibile e decisamente troppo
macchinoso.
Alternativa: creiamo uno script che contiene i nostri parametri e lancia il comando per la connessione
SSH al nostro client e facciamolo eseguire sul server a intervalli regolari, in modo da assicurarci una
connessione SSH pressochè perpetua. I problemi con questo approccio sono due:

1. Non possiamo più usare l'indirizzo IP dinamico, ma ci vuole qualcosa di fisso: fortunatamente SSH
permette di specificare gli hostname, quindi possiamo utilizzare uno dei servizi come DynDNS o
no-IP di cui parlavo prima, dopo aver verificato che il nostro hostname (che chiameremo per
esemplificare pippo.dyndns.org) sia collegato al nostro IP attuale.
2. Il comando ssh è interattivo e ci chiederà password ed eventuali altre informazioni e non mi risulta
ci sia modo per mettere la password direttamente nel comando: ci viene in aiuto Expect, un
programma che ci permette di pianificare, sotto forma di script, una serie di “a domanda X rispondi
Y e proseguiamo con la prossima”; se non è già installato sulla distribuzione che usate,
generalmente si trova nei repositories (con Debian, Ubuntu e derivate basta un apt-get install
expect)

Dunque sembra che ce l'abbiamo fatta: ecco il nostro script, chiamato test.exp e reso eseguibile con un
bel sudo chmod +x test.exp, molto grezzo per il momento:

#!/usr/bin/expect

spawn ssh -N -f -R 5555:192.168.0.1:22 -R 5910:192.168.0.1:5900 pippo@pippo.dyndns.org
expect "*(yes/no)?"
send "yesr"
expect "*assword:"
send "password_sceltar"
send -- "r"
expect eof

Ovviamente a password_scelta bisogna sostituire la propria password. Facendo sì che tale script venga

29

eseguito ad intervalli regolari e non troppo lunghi ci si assicurerà di essere raggiungibili ovunque e di
poter avere infine le nostre due porte locali collegate a quelle del server che ci interessano.
La soluzione appena vista funziona, ma non è sicuramente il massimo per almeno due motivi:

1) il server avrà un processo che si attiva costantemente tentando di connettersi al nostro computer
2) i nostri dati sono proprio in bella vista.

Come ovviare a questo?
Un modo è probabile che ci sia e passa attraverso le porte che generalmente il firewall tiene aperte in
ingresso, come la porta 80 (destinata al server HTTP). Oltre ad avere sul server tale porta aperta per le
connessioni in ingresso (spesso è così, se no apritela), è necessario avere un webserver (es. Apache, ma
qualunque altro va bene) che ascolta su di essa e che supporti PHP. Non sto qui a raccontarvi come si
installano Apache e PHP, trovate centinaia di guide su Internet (se volete una soluzione veloce, all-in-
one e multipiattaforma provate XAMPP, scaricabile dal sito www.xampp.org).
Comunque è fondamentale che dal client, ovunque ci troviamo, inserendo nel browser l'indirizzo del
server, compaia la pagina del webserver. Se è così possiamo andare avanti.
L'idea è quella di utilizzare un semplice form HTML per inserire nome utente e password, questi
verranno sottomessi ad un file PHP che si occuperà di richiamare lo script precedente modificato per
accettare nome utente e password dall'esterno. In questo modo risolveremo il problema 1), in quanto
non avremo più bisogno del processo che si attiva costantemente per provare a connettersi al nostro
computer, ma lo richiameremo quando ne avremo bisogno dalla barra indirizzi del browser;
risolveremo anche il problema 2), perchè passeremo i nostri dati attraverso il form, quindi non saranno
salvati sul server e visibili a terzi.
Creiamo una sottocartella chiamata “test” nella cartella dove vanno i file di Apache accessibili
dall'esterno (di solito /var/www o /opt/lampp/htdocs) e posizioniamoci in essa.
Creiamo in essa un file test.htm che mostri un semplice form per l'inserimento di username e password,
il suo contenuto potrebbe essere questo:
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.76 [en] (X11; U; Linux 2.2.16-22 i686) [Netscape]">
<title>Login page</title>
</head>
<center>
<font size="+3" face="Verdana, Arial, Helvetica, sans-serif"><strong>Login page</strong></font>
</center>

<p><form action="test.php" method="post" name="form" target="_blank">
<center>
<table border="1">

<tr>
<td><b>Username</b></td>
<td>
<input name="username" type="text" size="40" />
</td>
</tr>

<tr>
<td><b>Password</b></td>
<td>
<input name="password" type="password" size="40" />
</td>
</tr>

30

<tr>
<td ALIGN=RIGHT> </td>
<td ALIGN=center><b><input type="submit" value="Login"> <input type="reset" value="Reset"></b></td>
</tr>
</table>
</center>
</form>
</body>
</html>

Esso passerà i dati inseriti ad un file test.php, che creeremo nella stessa cartella con il seguente
contenuto:
<?php
$username=$_POST["username"];
$password=$_POST["password"];
$comando="./test.exp $username $password";
$res=exec($comando);
?>

Questo file andrà a chiamare il nostro script test.exp, che copieremo in questa cartella e che
modificheremo in modo che il suo contenuto sia il seguente:

#!/usr/bin/expect

set username [lrange $argv 0 0]
set password [lrange $argv 1 1]
spawn ssh -N -f -R 5555:192.168.0.1:22 -R 5910:192.168.0.1:5900 pippo@pippo.dyndns.org
expect "*(yes/no)?"
send "yesr"
expect "*assword:"
send "$passwordr"
send -- "r"
expect eof

(ovviamente sostituiamo nello script gli indirizzi corretti).
Modifichiamo i permessi di test.exp mediante i comandi

sudo chown nobody:nogroup test.exp
sudo chmod og-x test.exp
sudo chmod u+x test.exp

In questo modo avremo fatto sì che il file sia scrivibile ed eseguibile solo da web (oltre che da root
ovviamente).
Per richiamare il tutto scriviamo nella barra degli indirizzi del browser

http://server_address/test/test.htm

(sostituiamo a server_address l'indirizzo del server).
Avremo davanti una pagina simile alla seguente:

31

Qui inseriremo username e password, che verranno inviati al file test.php, che si occuperà di richiamare
test.exp passandoli ad esso come argomenti. Così avremo la nostra connessione.

Unica raccomandazione, ma fondamentale: qualcuno potrebbe pensare che oltre a username e
password dal form HTML potremmo passare anche il nostro indirizzo IP attuale, evitando così di usare
DynDNS o no-IP, ma sarebbe un gravissimo errore, in quanto chiunque sapesse dello script potrebbe
usarlo per usare la nostra tecnica a proprio piacimento sul proprio PC, assicurandosi una via di accesso
al server; per evitare ci accontenteremo di passare solo username e password e lasciare l'hostname nello
script, così continueremo a usare DynDNS o no-IP, ma in questo modo solo noi (e nessun altro)
potremo connetterci.

Nota bene: se il nostro client non è connesso direttamente ad Internet ma è dietro un router, l'IP con il
quale saremo su Internet è quello del router (anche DynDNS e no-IP connetteranno l'hostname a questo
indirizzo), dunque è necessario aprire la porta 22 (SSH) in ingresso sul router ed effettuare il port
forwarding di tale porta sul nostro client.

Per terminare la connessione, basta lanciare dalla console del nostro client il comando

ps -ax | grep ssh

Il risultato sarà simile al seguente:

4926 ? Ss 0:00 /usr/sbin/sshd
6537 ? Ss 0:00 sshd: l3golas [priv]
6544 ? S 0:00 sshd: l3golas
6579 pts/1 R+ 0:00 grep ssh

32

Basta uccidere il processo che termina con [priv], che nel nostro caso ha PID 6537, quindi tramite il
comando

sudo kill 6537

33

Accesso remoto al proprio computer in una rete eterogenea

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Accesso remoto al proprio computer in una rete eterogenea

Ähnlich wie Accesso remoto al proprio computer in una rete eterogenea (20)

Mehr von Giacomo Antonino Fazio

Mehr von Giacomo Antonino Fazio (6)

Accesso remoto al proprio computer in una rete eterogenea