Accesso remoto al proprio computer in una rete eterogenea

Giacomo Antonino Fazio

1

Indice generaleAccesso remoto al proprio computer in una rete eterogenea.....................................................................1

1. Condivisione dei file.........................................................................................................................32. Apertura di una shell sul computer remoto ed (eventualmente) esecuzione di qualche applicazione grafica....................................................................................................................................................3

2.1 Installazione server SSH.............................................................................................................32.2 Uso del client SSH......................................................................................................................5

3. Accesso alla sessione grafica corrente da remoto (VNC).................................................................73.1 Configurazione del server VNC.................................................................................................73.2 Configurazione del client VNC................................................................................................103.3 Rendere sicuro VNC tramite SSH (opzionale).........................................................................13

4. Apertura di una nuova sessione grafica...........................................................................................154.1 Apertura di una nuova sessione grafica su server Mac OS X...................................................154.2 Apertura di una nuova sessione grafica su server Windows.....................................................164.3 Apertura di una nuova sessione grafica su server Linux..........................................................18

5. NX e FreeNX...................................................................................................................................205.1 Installare il server NX (max 2 connessioni simultanee)...........................................................215.2 Installare il server FreeNX (connessioni simultanee teoricamente illimitate ma niente collegamento alla sessione corrente)..............................................................................................225.3 Uso del client............................................................................................................................25

6. Approfondimento: il reverse port forwarding.................................................................................286.1 La tecnica..................................................................................................................................286.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 filePer 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 graficaSe 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 updatesudo 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 updatesudo 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 updatesudo 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 updatesudo 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:

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 VNC2) 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

Client Server

VNC client

SSH client

VNC server

SSH server

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 graficaTramite 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 updatesudo 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 updatesudo 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_MANAGERexec /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 FreeNXNX è 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 updatesudo 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 NoMachineDiventare 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.gzwget e poi tar zxvf repo/nxclient-3.0.0-84.x86_64.tar.gzwget e poi tar zxvf repo/nxnode-3.0.0-93.x86_64.tar.gz

Compilazione delle librerie di compressione NXEstrarre 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/NXmakecp -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.gzwget e poi tar zxvf /home/ubuntu/Downloads/Linux/FreeNX/nx-X11-3.0.0-37.tar.gz

Applicare la patch mediante il comando:

cd nxcompextwget 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/NXmakecp -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./configure --prefix=/usr/NXmakecp -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./configure --prefix=/usr/NXmakemake 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.2patch -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-helpermakecp -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/nxserverln -sf /usr/NX/bin/nxsetup /usr/sbin/nxsetupln -sf /usr/NX/bin/nxloadconfig /usr/sbin/nxloadconfigln -sf /usr/NX/lib/libXrender.so.1.2.2 /usr/NX/lib/libXrender.so.1.2ln -sf /usr/NX/bin/nxagent /usr/NX/bin/nxdesktopln -sf /usr/NX/bin/nxagent /usr/NX/bin/nxviewerln -sf /usr/bin/foomatic-ppdfile /usr/lib/cups/driver/foomatic-ppdfileln -sf /etc/X11/xinit /etc/X11/xdmln -sf /sbin/mount.cifs /sbin/smbmountln -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.2cp 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 forwardingTutte 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.orgexpect "*(yes/no)?"send "yes\r"expect "*assword:"send "password_scelta\r"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 computer2) 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>&nbsp;</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.orgexpect "*(yes/no)?"send "yes\r"expect "*assword:"send "$password\r"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.expsudo chmod og-x test.expsudo 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/sshd6537 ? 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