Abbiamo parlato negli articoli precedenti del protocollo VNC e del suo utilizzo, ma non è certo la soluzione migliore, in quanto esiste il protocollo NX, superiore a VNC sotto ogni punto di vista

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 a questa pagina.

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.

Nell’articolo precedente avevamo visto come Accedere alla sessione grafica corrente da remoto attraverso il protoccollo VNC. e come Rendere sicuro VNC tramite SSH. Adesso vedremo come aprire una nuova sessione grafica su Server 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 passare direttamente al prossimo articolo dove parleremo di NX e FreeNX. 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:

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/ (guida e recensione a questo articolo: 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 .

Autore : Giacomo Antonino Fazio aka l3golas

Vogliamo adesso vedere come rendere “sicuro” VNC.

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ò bisogna effettuare i seguenti passaggi:

• Configurazione del server VNC
• 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.
• 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 nell‘articolo precedente.
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 -X -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 -X -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).
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.

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

Autore : Giacomo Antonino Fazio aka l3golas

N.B. Se il server a cui connettersi utilizza Linux, conviene lasciar perdere VNC e passare a NX (trattato nell’articolo successivo), per completezza l’uso di VNC verrà comunque trattato anche su Linux.

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

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:

Fare quindi click sul pulsante Computer Settings, 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 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.

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:

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:

Se è così ed è possibile interagire con i desktop remoti, tutto funziona a dovere. 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.

Autore : Giacomo Antonino Fazio aka l3golas

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 precedentemente pubblicata: Condividere file con PC Windows, Linux, MacOS X attraverso i protocolli SMB, NFS e AFP, consultabile a questo indirizzo.

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

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.

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 ufficiale 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 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:

FreeSSHD Setting Windows

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

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

Tuttavia è necessario installare sul client un server X, ad esempio Xming, scaricabile a questo indirizzo. 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.

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.

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 che sono state trattare in questo articolo.

Autore : Giacomo Antonino Fazio aka l3golas