0. Premessa.
0.1) Cosa è questo documento?
0.2) A chi si rivolge?
0.3) Mi debbo fidare ciecamente di quello che leggo in questo testo?
0.4) Dove posso trovare l'ultima versione di questo testo?
0.5) Cosa c'è di nuovo in queste FAQ?
1. VNC.
1.1) VNC: Cosa è? A cosa serve?
1.2) Che vantaggi ha VNC rispetto ad altri programmi analoghi?
1.3) Io uso Unix/Linux/BSD/ecc. VNC non mi serve, tanto posso usare una sessione X remota. Giusto?
1.4) A leggere qui VNC sembra fenomenale! Ma avrà anche qualche difetto, no?
1.5) Quanti VNC esistono? Quale devo usare?
1.6) Come posso installare VNC sotto Windows?
1.7) Come posso installare VNC sotto Unix?
1.8) Come posso impostare VNC per avere la massima velocità di connessione possibile per il mio sistema?
1.9) Quanto è sicuro VNC? Se lo installo qualche malintenzionato potrebbe usare il mio computer a mia insaputa?
1.10) Ma installare VNC non minaccia la mia privacy?
2. SSH.
2.1) Cosa è SSH?
2.2) Dove posso trovare SSH per il mio PC? Quale versione debbo installare?
2.3) Come faccio a installare SSH sulla mia macchina?
3. Usare SSH per rendere più sicuro VNC.
3.1) Come configurare il server SSH.
3.2) Come configurare il server VNC.
3.3) Come configurare il client SSH.
3.4) Come configurare il client VNC ed effettuare la connessione.
4. Riferimenti.
4.1) Su VNC.
4.2) Su SSH.
Questo documento vuole essere un semplice elenco di risposte alle domande più comuni su VNC e sul suo uso tramite SSH che periodicamente appaiono sui newsgroup it.comp.sicurezza.varie e it.comp.sicurezza.windows. Non ha assolutamente la pretesa di essere una guida completa all'installazione e all'uso di VNC, per cui si rimanda ai link forniti.
Per usare in maniera "proficua" e, soprattutto, "sicura" la coppia VNC & SSH è necessario un minimo di conoscenza sia del funzionamento di una rete TCP/IP che dell'amministrazione del sistema operativo su cui si vogliono installare. Pertanto queste conoscenze saranno date per scontate nel prosieguo.
Assolutamente no! Il contenuto di questo testo è frutto della mia personalissima esperienza e non è assolutamente detto che su un altro computer le cose funzionino nello stesso e identico modo. In particolare sconsiglio caldamente di installare VNC & SSH direttamente su una macchina collegata ad una rete pubblica e che magari contiene anche dati importanti. È altamente consigliabile effettuare prima una esauriente serie di prove su una macchina "sacrificabile" collegata ad una rete privata e poi, solo quando si è sicuri di essere in grado di mettere tutto a punto correttamente, installare i programmi sulla macchina su cui verranno effettivamente usati. In altre parole, tutto quello che posso dire su quanto ho scritto è: "A me così ha funzionato. A voi non so."
All'indirizzo: http://clbianco.altervista.org/vnc/vncfaq.html
Versione 0.1.4 beta2... ovvero: "Dicesi HTML..." ;-)
a) Completamente riscritte le pagine di tutto il sito
usando HTML 4.01 e CSS e in modo da seguire le linee guida del W3C-WAI
per l'accessibilità dei contenuti web (si vedano i loghi a fondo
pagina). Spero che adesso non ci siano problemi di visualizzazione con
nessun tipo di browser, ma in caso contrario vi prego di segnalarmeli
così che possa porvi rimedio il prima possibile.
b) Da questa versione la FAQ è disponibile solo in
formato HTML.
c) Modificata la risposta 0.4 con l'indirizzo diretto
della pagina.
d) Aggiornata la risposta 1.5 e aggiunte le
descrizioni di Ultr@VNC, uVNC, PalmVNC, VNCviewer for PocketPC.
e) Aggiornata la risposta 1.6 per la nuova versione di
TightVNC.
f) Aggiornata la risposta 2.3 tenendo conto della fine
dello sviluppo della distribuzione di OpenSSH curata da
Networksimplicity.
g) Aggiornata la risposta 3.2 tenendo conto del nuovo
nome della casella di spunta per attivare le connessioni loopback in
TightVNC 1.2.8 e del fatto che il loopback funziona ora anche sotto
Unix.
h) Aggiornata la risposta 4.1 con i link alle nuove
distribuzioni citate nella risposta 1.5.
i) Qualcosa mi dice che anche la risposta 0.5 è stata
modificata... ;-)
Versione 0.1.3 beta1 ...ovvero: "la risposta che tutti stavate aspettando"... ;-)
a) Inserita la domanda 1.8 con le istruzioni per
configurare VNC per avere la massima velocità di connessione.
b) Rinumerate le domande successive di
conseguenza.
c) I lettori più attenti avranno notato una modifica
nella domanda 0.5... ;-)
Versione 0.1.2 alpha2 ...ovvero: "ci avviciniamo a grandi passi alla 1.0.0, nostra meta finale"... ;-)
a) Aggiornata la domanda 1.5 per quanto riguarda
RealVNC e TightVNC.
b) Inserita la domanda 1.7 con le istruzioni per
compilare ed installare TightVNC 1.2.6 sotto Unix. Le successive
domande sono state rinumerate di conseguenza.
c) È stata modificata anche la domanda 0.5, nel caso
qualcuno avesse dei dubbi... ;-)
Versione 0.1.1 alpha1 ...ovvero: chi va piano... ;-)
a) Completamente riscritta la domanda 1.6, con le
istruzioni dettagliate per installare e configurare TightVNC sotto
Windows. Le istruzioni per l'installazione in ambiente Unix seguiranno
a breve (spero...).
b) Corretto un refuso nella domanda 1.5.
c) Introdotta la domanda 0.5... ;-)
Versione 0.1.0 pre-alpha1 ...e non dite che non vi ho avvertito! ;-)
a) Prima versione pubblicata.
VNC vuole dire "Virtual Network Computer". È un programma che permette di controllare il proprio computer da una postazione remota. Quando ci si collega da un qualunque computer alla propria macchina con VNC, sullo schermo si apre una finestra che riproduce in tutto e per tutto e in tempo reale lo schermo della macchina remota. A questo punto si può lavorare all'interno di questa finestra esattamente come se si fosse seduti fisicamente davanti a schermo, tastiera e mouse della propria macchina, anche se in realtà ci si trova a chilometri di distanza.
Molti. I principali sono:
a) VNC è multipiattaforma. Questo vuole dire che
potete usarlo su qualunque piattaforma, e la compatibilità è totale. In
particolare, potete collegarvi a una macchina Windows per usarla da
remoto da una macchina Unix, oppure potete collegarvi dal vostro PC con
Windows ad una workstation Unix remota, oppure ancora potete collegarvi
da una macchina che monta MacOS ad un PC con Linux, ecc.
b) VNC è estremamente compatto. In altre parole, il
file .zip contenente sia il server che il client entra tranquillamente
su un normale floppy HD da 1.44MB.
c) VNC non è per nulla invasivo. L'installazione del
server non apporta praticamente nessuna modifica al sistema, neanche
sotto Windows. Inoltre il client non necessita di alcuna installazione
per funzionare. Quindi potete tranquillamente mettere il client su un
floppy e portarvelo appresso per usarlo quando ne avete bisogno, senza
dover installare nulla sul computer che state usando in quel momento
per collegarvi.
d) Del client esiste addirittura una versione scritta
in Java. Quindi potete collegarvi da qualunque macchina che abbia
installata una Java Virtual Machine.
e) I sorgenti di VNC sono disponibili. Quindi potete
sapere esattamente cosa faccia e, se proprio non esiste una versione
già pronta per la vostra macchina, nessuno vi vieta di compilarvela da
voi, magari con delle aggiunte che vi possono essere utili.
f) VNC è gratuito. La qual cosa non guasta di certo...
;-)
Sbagliato. Ci sono moltissimi vantaggi nell'usare VNC al posto di una
sessione X remota. Ad esempio:
a) Potete collegarvi alla vostra workstation Unix
anche da una macchina che non abbia installato un X server. Ad esempio,
potete collegarvi da un PC con Windows.
b) D'accordo, esistono anche X server per Windows. Ma
il client VNC entra comodamente su un floppy e non necessita di alcuna
installazione. Avete mai provato a mettere un X server per Windows già
pronto all'uso su un floppy?
c) La sessione X remota dura fino a che siete
collegati e viene chiusa quando vi scollegate. Quindi, se dovete
avviare sulla macchina Unix remota un processo che durerà molte ore,
l'unica possibilità è restare collegati fino al termine del processo.
Invece, se usate VNC, potete collegarvi, lanciare il processo,
scollegarvi, andare su un altro computer, ricollegarvi molte ore dopo e
ritrovare la vostra sessione sulla macchina Unix esattamente come
l'avete lasciata, come se non vi foste mai scollegati.
Sì, VNC ha almeno un grosso difetto. Questo suo essere intrinsecamente multipiattaforma, questo suo essere estremamente "educato" nei confronti del sistema su cui è installato, lo si paga in termini di prestazioni. VNC funziona (detto in modo grossolano) catturando lo schermo e spedendolo via internet come immagine. La cattura avviene usando funzioni ad alto livello e la quantità di dati che deve essere trasmessa via rete è molto grande. Quindi, se la connessione non è molto veloce, il sistema diventa quasi inutilizzabile. Per questo sono stati sviluppati dei sistemi particolari come il "Tight encoding" (vedi domanda 1.5).
Ne esistono molti. La disponibilità dei sorgenti ha fatto sì che
venissero sviluppate molte diverse "distribuzioni", ognuna con i suoi
pregi e i suoi difetti e ottimizzata per un compito particolare. Quella
che segue non vuole essere certo una lista esaustiva, vista la velocità
con cui si susseguono nuove versioni e nuove "distribuzioni" e vengono
aggiornate quelle esistenti, ma si limita a fornire un panorama
generale della situazione:
a) VNC "liscio":
la versione originale sviluppata dai laboratori della Olivetti e poi
ceduta ai laboratori di Cambridge della AT&T. È la versione "base"
da cui tutte le altre sono derivate. Non supporta nessun sistema di
compressione dei dati, quindi può essere utilizzata senza problemi solo
con una connessione dai 100Mb in su. È assolutamente inutilizzabile via
modem. È disponibile per le piattaforme Unix, Win32, Mac (beta), Java
(solo viewer) e WinCE 2.x (beta, solo viewer). Non è più sviluppata e i
suoi autori si dedicano ora a RealVNC.
b) RealVNC:
evoluzione di VNC "liscio", sviluppata dallo stesso team a più di un
anno dalla sua ultima versione. Incorpora moltissime migliorie, incluso
uno speciale "encoding" per connessioni lente. Non si basa sulle varie
distribuzioni di VNC uscite nel frattempo, ma proviene da una linea di
sviluppo totalmente separata e parallela. Incorpora un sistema per
misurare automaticamente la banda disponibile all'inizio di ogni
connessione. In tal modo è in grado di impostare automaticamente i
parametri di compressione per avere la massima velocità possibile.
Purtroppo non supporta il "Tight encoder" che, in base a quanto ho
sentito dire ma non ho mai verificato di persona, rimane il migliore
quando la banda è veramente poca (leggi: modem 56K). È disponibile per
le piattaforme Unix e Win32.
c) TightVNC:
ovvero VNC con "Tight encoder". Date le limitazioni del VNC "liscio" in
presenza di connessioni lente, è stato sviluppato da Constantin
Kaplinsky il "Tight encoder" per comprimere il più possibile i dati
inviati in internet e ridurre la richiesta di banda. In aggiunta alla
codifica "tight", le immagini dello schermo che vengono inviate via
internet possono essere compresse in formato JPEG (se lo schermo è a 24
o 32 bpp) e/o possono essere compresse con la libreria zlib. Il sistema
funziona così bene da essere utilizzabile addirittura con una
connessione via modem a 56Kbps. È stata annunciata una nuova versione
che dovrebbe incorporare molte delle migliorie introdotte dalle altre
distribuzioni basate su TightVNC (VdaccVNC e eSVNC), rendendole quindi
disponibili anche agli utenti Unix. È disponibile per le piattaforme
Unix, Win32 e Java (solo viewer). Nel seguito parlerò principalmente di
questa distribuzione, visto che è quella che uso io... ;-)
d) VdaccVNC:
ovvero "Video Driver ACCelerated VNC". È una versione sviluppata da
Rudi de Vos a partire da TightVNC per tentare di renderlo ancora più
veloce. La cattura dello schermo avviene non ad alto livello, ma a
livello del driver della scheda video. In questo modo la cattura è
molto più veloce e impegna meno la CPU di sistema. L'altra faccia della
medaglia è la necessità di installare nel sistema operativo un driver
video apposito che si interfacci al driver video esistente. Questo può
ovviamente portare a problemi di compatibilità e a blocchi di sistema,
facendo venire meno la "non invasività" di VNC di cui parlavamo più
sopra. Attualmente il driver esiste per WinNT4/2000/XP. Una ulteriore
miglioria rispetto al "TightVNC" standard riguarda la possibilità di
condividere via internet una sola applicazione invece dell'intero
desktop, come già avviene con le sessioni X remote sotto Unix. Inoltre
è possibile avere un desktop diverso per ogni utente connesso, di nuovo
come già avviene sotto Unix. Queste differenze da TightVNC riguardano
solo il server e quindi, anche se il server di VdaccVNC esiste solo per
Windows, la connessione può essere effettuata a partire da qualunque
macchina usando il normale client di TightVNC. Le ultime versioni di
VdaccVNC incorporano però anche una speciale "cache" di trasmissione e
quindi richiedono l'uso di un client apposito. Alcune delle migliorie,
come la possibilità di condividere una singola applicazione o la
possibilità di avere desktop multipli, potrebbero essere incorporati
nelle prossime versioni "ufficiali" di TightVNC, a patto che questo non
crei problemi per la natura "multipiattaforma" di TightVNC. VdaccVNC
non viene più sviluppato. Gli autori di VdaccVNC e eSVNC hanno unito i
loro sforzi e stanno ora sviluppando Ultr@VNC.
e) eSVNC:
Un'altra versione derivata da TightVNC e di recentissimo rilascio (la
prima versione risale a giugno 2002) creata da Samuel Folliard. Include
molte migliorie, come la possibilità di ridurre la risoluzione dello
schermo remoto per ridurre la quantità di dati da trasmettere via
internet o la possibilità di trasferire dei files dal client al server
e viceversa. Attualmente esiste solo per Windows, ma molte di queste
funzionalità dovrebbero essere incorporate nella prossima versione
"ufficiale" di TightVNC che dovrebbe uscire in autunno, rendendole
quindi disponibili anche agli utenti Unix. eSVNC non viene più
sviluppato. Gli autori di VdaccVNC e eSVNC hanno unito i loro sforzi e
stanno ora sviluppando Ultr@VNC.
f) Ultr@VNC:
una nuova versione di VNC creata dagli autori di VdaccVNC e eSVNC. Non
è stata ancora rilasciata ufficialmente ma è disponibile per il
download la "Release candidate 1.06". Sulla carta questa distribuzione
dovrebbe essere una vera bomba, dato che vuole mettere insieme tutte le
caratteristiche migliori di VdaccVNC, di eSVNC, di TightVNC e di
RealVNC e vuole anche aggiungerne molte altre. Per citarne alcune:
configurazione automatica delle impostazioni di compressione in base
alla banda disponibile (RealVNC), trasferimento di files dal client al
server (eSVNC), cattura dello schermo tramite driver video (VdaccVNC),
autenticazione NT "nativa" (user, pass e dominio) invece della semplice
password di VNC, riscalatura automatica dello schermo per ridurre i
dati da trasferire (eSVNC), cache di trasmissione (VdaccVNC), gestione
del cursore remoto sul client (TightVNC), "tight encoder" (TightVNC),
supporto di plug-in per effettuare ulteriori operazioni su dati
trasmessi tra client e server (cifratura, ulteriori controlli dei
diritti di accesso, ecc.), possibilità di cambiare la modalità video
del server senza interrompere la connessione, finestra di chat testuale
tra client e server, connessione XDMCP, ecc. Tutto ciò è disponibile
solo per Win32, ma client e server Ultr@VNC sono compatibili con tutte
le altre distribuzioni. Questo può eliminare molti problemi in caso di
ambienti misti Unix/Win32, anche se ovviamente le funzioni avanzate
sono disponibili solo quando si usano sia il client che il server di
Ultr@VNC.
g) TridiaVNC:
Una versione commerciale di VNC con molte funzioni aggiuntive, come ad
esempio il supporto per una autenticazione "NT-nativa" degli utenti
remoti sotto WinNT/2K. Si basa su TightVNC per quanto riguarda il
sistema di compressione dei dati. Esiste anche una versione gratuita ma
con molte meno funzioni aggiuntive.
h) uVNC:
una versione del server di VNC per computer a 8 bit, incluso il
Commodore 64. Dovrebbe essere compatibile con ogni tipo di client.
i) PalmVNC:
una versione di VNC che comprende una versione modificata del server di
VNC "liscio" per Win32 e un client per Palm. Dovrebbe funzionare anche
con il server standard, ma in tal caso non sarebbero disponibili le
funzioni di riscalatura dello schermo.
j) VNCviewer for PocketPC:
una versione per PocketPC del client di VNC "liscio".
La procedura descritta è relativa a TightVNC 1.2.8 su Win2K/SP2, ma può
essere applicata ad altre distribuzioni con minimi cambiamenti.
a) La prima cosa da fare è ovviamente collegarsi al
sito http://www.tightvnc.org/ e
andare nella sezione "download". Da qui è possibile scaricare un file
.exe autoscompattante e autoinstallante per Win32
(tightvnc-1.2.8-setup.exe). In alternativa, è anche possibile scaricare
un semplice file .zip da scompattare in un cartella qualunque creando
poi a mano le icone del menù avvio. Ovviamente si possono scaricare
anche i sorgenti.
b) Una volta scaricato il file di installazione, basta
avviarlo, scegliere la cartella in cui installare il programma (ad
esempio c:\programmi\tightvnc) e rispondere "next" a un paio di
domande. In pochi secondi l'installazione termina e non è necessario
riavviare la macchina. Alla fine dell'installazione dovrete decidere se
installare il server di TightVNC come "servizio", caricandolo quindi a
ogni accensione della macchina e rendendo disponibile la connessione
dall'esterno anche se nessun utente è loggato in locale, oppure se
lanciare il TightVNC server solo quando ne avete bisogno. Potrete
cambiare questa decisione in qualunque momento.
c) Ora vi trovate con un nuovo gruppo di programmi nel
menù avvio: il gruppo TightVNC:
Al suo interno si trovano le icone per avviare il client, per avviare
il server, un sottogruppo "Administration" per l'impostazione dei
parametri del server e un altro sottogruppo con i link alla
documentazione.
d) Se non lo avete fatto prima e volete installare
TightVNC come "servizio", nel sottogruppo "Administration" cliccate
sull'icona "Install VNC Service". Si aprirà una finestra avvertendovi
dell'avvenuta installazione. Anche in questo caso riavviare la macchina
non è necessario, basta andare nel pannello di controllo, nell'elenco
dei "servizi", premere col tasto destro su "WinVNC" e scegliere
"start". A questo punto è consigliabile riandare nel sottogruppo
"Administration" e cliccare su "Run Service Helper". Si attiverà in
questo modo l'icona accanto all'orologio da cui controllare lo stato
del server e modificarne le impostazioni. Ovviamente da ora in poi
l'avvio del servizio sarà automatico ad ogni avvio del sistema e
l'avvio del "service helper" sarà automatico ad ogni login, sia in
locale che da remoto.
e) Ok, ora dovete solo configurare il server. Nel
solito sottogruppo "Administration" c'è l'icona "Show Default Settings"
e nel gruppo principale "TightVNC" c'è l'icona "Show User Settings". Il
server, quando qualcuno cerca di connettersi dall'esterno, per prima
cosa controlla quale utente è loggato in locale e poi carica e rende
effettive le opzioni che quell'utente ha impostato nella finestra "Show
User Settings". Se nessun utente è loggato in locale o se l'utente
attualmente loggato non ha impostato nessuna opzione personalizzata, il
server userà le opzioni impostate in "Show Default Settings". Le due
finestre ("Show User Settings" e "Show Default Settings") sono
assolutamente identiche e contengono le medesime opzioni, quindi ne
riporto solo una per brevità:
La prima cosa da impostare è la password nell'apposita casella. Come
tutte le altre opzioni, anche la password può essere diversa a seconda
dell'utente che è attualmente loggato in locale sulla macchina, ma non
può essere diversa in base all'utente che si sta connettendo da remoto.
Anche se nella casella è possibile impostare una password di qualunque
lunghezza, solo i primi 8 caratteri vengono effettivamente registrati
ed utilizzati. È possibile anche impostare una password aggiuntiva "in
sola visione". I client che si collegano usando questa password possono
vedere il desktop della macchina server ma non possono interagire con
esso. Dopo aver scelto la password, è possibile impostare la porta su
cui il server dovrà mettersi in ascolto. Se non si hanno fondati motivi
per non farlo, si può tranquillamente lasciare questa opzione su
"auto". È anche consigliabile impostare la disattivazione della
tastiera e del mouse "locali" in presenza di una connessione remota. Le
opzioni di "polling" riguardano il modo in cui il server controlla cosa
viene modificato sullo schermo per inviarlo al client. Il server
dovrebbe riuscire a intercettare tutti gli aggiornamenti dello schermo
in automatico, ma per alcune finestre (come il prompt dei comandi)
questo non funziona e sorge la necessità di controllarne periodicamente
"a mano" il contenuto. È ovviamente consigliabile attivare il "polling"
solo per le finestre che effettivamente lo richiedono, pena un
decadimento delle prestazioni. Di default questo trattamento è
riservato al solo prompt dei comandi, e solo se in primo piano. È anche
possibile impostare il server per "lockare" la workstation o eseguire
un logoff quando l'ultimo client si disconnette. Da ultimo, si può
scegliere se far rimuovere al server l'immagine di sfondo del desktop
durante le connessioni (altamente consigliabile, a meno che non si
abbia una connessione davvero veloce).
g) Ora provate a premere sul bottone "Advanced".
Si aprirà una finestra di questo tipo:
Da qui è possibile impostare il server per chiedere una conferma
all'utente eventualmente loggato in locale prima di accettare una
connessione da remoto. Ovviamente, se la risposta dell'utente locale
non arriva entro un certo tempo, la connessione può essere accettata
automaticamente o rifiutata automaticamente. In questa finestra è anche
possibile impostare la priorità delle connessioni. Ovvero, se un utente
è già loggato da remoto e il server riceve la richiesta di una seconda
connessione, che deve fare? Deve disconnettere la connessione
precedente e avviare la nuova, rifiutare la nuova connessione e restare
con la vecchia o trasformare la vecchia sessione in una sessione
"condivisa" tra i due utenti remoti? La scelta è solo vostra... ;-) Il
server di VNC contiene anche un piccolo server HTTP, che viene usato
per connettersi tramite il client Java e un browser web. Personalmente
non uso il client Java e quindi ho disabilitato il server HTTP
deselezionando l'opportuna casella in questa finestra delle opzioni
"Advanced", ma questo non vuole dire che voi dobbiate fare lo stesso.
Molto importanti in questa stessa finestra sono le due opzioni
riguardanti le connessioni "loopback", cioè sull'interfaccia 127.0.0.1.
Di default sono disabilitate, ma se si vuole usare un tunnel SSH (vedi
punto 3.2), devono essere attivate entrambe: "Allow loopback
connections" e "Allow only loopback connections". Infine, si possono
impostare le opzioni riguardanti il file di log (se attivarlo o meno e
quanto farlo dettagliato) e per disabilitare le password "vuote" (cosa
altamente consigliabile!).
h) Da ultimo, ricordate che l'icona del server accanto
all'orologio (sia esso il "service helper" o una istanza del server avviata
all'occasione) cambia colore in presenza di una connessione:
Non connesso: 
, Connesso: 
.
Anche l'installazione sotto Unix è molto semplice:
a) La prima cosa da fare è installare le librerie
richieste per la compilazione, cioè la zlib e la jpeg. Ma questo sono
molto probabilmente già installate sul vostro sistema.
b) Poi dovete scaricare il .tar.gz con i sorgenti e
scompattarlo. Si creerà in tal modo una sottodirectory chiamata
"vnc_unixsrc".
c) Se necessario, aprite con un editor di testo il
file "imakefile" nella sottodirectory "vncviewer" e impostate la
posizione corretta delle librerie zlib e jpeg nel vostro sistema.
Inizialmente potete anche saltare questo punto ed eseguirlo solo in un
secondo momento, se durante il primo tentativo di compilazione
incappate in un errore causato da librerie mancanti.
d) Nella cartella "vnc_unixsrc" lanciate il comando
"xmkmf" e, poi, il comando "make World". Se siete fortunati, e le
librerie sono tutte al posto giusto, avrete in tal modo compilato tutto
tranne il server di VNC.
e) Entrate ora nella sottodirectory "Xvnc/config/cf",
aprite il file "vnclibs.def" con un editor di testo e modificate il
percorso delle librerie jpeg e zlib. Se questa operazione era stata
necessaria al punto "c", lo sarà molto probabilmente anche adesso. Se,
invece, allora si era rivelata inutile, potete anche saltare questo
punto.
f) Ritornate nella cartella "Xvnc" ed eseguite,
nell'ordine, "./configure" e "make". Se tutto va bene, avete compilato
anche il server.
g) A questo punto, tornate nella cartella
"vnc_unixsrc" ed eseguite "./vncinstall /usr/local/bin /usr/local/man",
ove "/usr/local/bin" è la cartella in cui volete installare i binari
appena compilati e "/usr/local/man" è la cartella in cui volete mettere
le manpages.
h) Copiate infine a mano il contenuto della
sottocartella "classes" ove appropriato, se volete usare la versione
Java del client su questa macchina.
i) Aprite il file "/usr/local/bin/vncserver" e
modificatelo secondo le vostre esigenze. In particolare, modificate la
path ove sono installati i font, o VNC avrà dei problemi a funzionare.
Per sapere quale è l'esatta "fontpath" del vostro sistema, potete usare
il comando "xset -q".
j) Perfetto, ora avete finito. Tutto quello che dovete
fare ora è "loggarvi" sulla machina col nome utente di chi dovrà usare
VNC e lanciare "vncserver". La prima volta che lo lancerete, vi verrà
richiesto di impostare una password, che sarà la password di login su
VNC di quel particolare utente. Poi vi verrà detto su che "display" è
stata aperta la sessione VNC dell'utente e potrete collegarvici col
client. Se il desktop standard di VNC non vi soddisfa, potete
modificare il file "xstartup" nella sottocartella ".vnc" nella HOME
dell'utente, in modo da avviate il window manager preferito.
k) Ricordate che la sessione VNC su Unix resta attiva
anche dopo che chiudete il client e vi disconnettete. Se vi
riconnettete in un secondo momento, ritrovate il vostro desktop proprio
come lo avevate lasciato, con tutti i programmi aperti e funzionanti.
Per chiudere la sessione definitivamente dovete usare il comando
"vncserver -kill :n" ove "n" è il numero del vostro "display". Penso
che questo comando debba essere dato loggandosi su un altro canale
diverso da VNC (ad esempio con telnet o ssh), ma non ne sono sicuro al
100%.
l) Ovviamente più utenti possono avere più sessioni
VNC aperte contemporaneamente. Ogni sessione sarà su un diverso
"display".
La velocità di VNC dipende da vari fattori. La connessione è formata da
varie fasi, ognuna delle quali ha le sue esigenze in termini di
velocità, che non sono necessariamente compatibili con quelle delle
altre fasi. Si dovrà pertanto provare più volte per trovare il miglior
compromesso. Le varie fasi sono:
a) Il server analizza lo schermo e individua le parti
modificate che devono essere spedite al client.
Qui non c'è molto da fare per migliorare la velocità, l'unico modo per
velocizzare questa fase è usare una distribuzione di VNC
particolarmente "ottimizzata" in tal senso. Ad esempio, Vdacc-VNC
cattura a livello di driver video invece che di API ad alto livello ed
è quindi più veloce, però esiste solo per Win32. Secondo l'autore di
eSVNC, un forte miglioramento della velocità di questa fase si ha
eliminando ogni forma di accelerazione grafica sul server, agendo dal
pannello di controllo:
Personalmente non ho mai provato e quindi non saprei dire, ma sulle
mailing list ho letto molti commenti di persone decisamente soddisfatte
da questo "trucco".
b) Il server codifica queste parti di schermo con l'encoding
scelto dall'utente e applica l'eventuale compressione.
Per accelerare questa fase è necessario usare un "encoding" veloce e
impostare la compressione al minimo o, meglio, disabilitarla del tutto.
Per avere la massima velocità possibile in questa fase, le opzioni del
client dovranno essere impostate nel seguente modo (l'immagine si
riferisce a TightVNC 1.2.6, ma le differenze dalle altre distribuzioni
sono minime):
La migliore velocità in questa fase si ottiene con l'encoding "hextile"
e nessuna compressione. Questo però comporta un utilizzo di banda molto
grande.
c) Il server spedisce via rete i dati al client.
Neanche a dirlo, per avere la massima velocità in questa fase è
necessario impostare la compressione al massimo (l'immagine si
riferisce a TightVNC 1.2.6, ma le differenze dalle altre distribuzioni
sono minime):
La velocità massima nella trasmissione si ottiene con l'encoding
"Tight", la compressione al massimo (9) e la compressione JPEG al
massimo (0). Questo però comporta un carico di lavoro molto grande
sulla CPU del server. Un ulteriore miglioramento si ha con eSVNC, che
può ridurre la risoluzione dello schermo del server per ridurre la
quantità di dati da spedire via rete. Purtroppo è disponibile solo per
Win32. Bisogna ricordare che non sempre attivare "restrict pixels to
8-bit" comporta una minor richiesta di banda. Sui pixel a 8 bit,
infatti, non può essere applicata la compressione JPEG. Quindi una
connessione a 24 bit compressa JPEG può richiedere meno banda di una a
8 bit senza compressione JPEG.
d) Il client riceve i dati, li decodifica e aggiorna lo schermo
in maniera corrispondente. Di nuovo, come nel punto
b), una minore compressione si traduce in un minor carico di lavoro del
client e quindi in una maggiore velocità. Vdacc-VNC incorpora una
"cache" nel client, che può velocizzare di molto la connessione. Ad
esempio, se riducete a icona una finestra e poi la ri-espandete, non
serve che sia rispedito via rete il contenuto della finestra. Anche
eSVNC ha adottato la stessa cache, ma entrambi sono disponibili solo
per Win32. La nuova versione di TightVNC (la 1.3 attualmente in fase di
sviluppo) dovrebbe implementarla anch'essa, quindi la "cache" sarà
presto disponibile anche sotto Unix.
Quindi, per avere la connessione più veloce possibile, è necessario
sapere quale delle fasi qui sopra sia il collo di bottiglia del proprio
sistema, e velocizzarla al massimo, anche a scapito delle altre. Farò
qualche esempio che mi viene dalla mia esperienza personale:
a) I due computer (client e server) sono connessi
direttamente con una LAN da 100 Mbit. In questo caso il collo di
bottiglia non è certo la connessione. Impostate in modo da velocizzare
al massimo le fasi b) e d), cioè l'encoder "hextile" e nessuna
compressione, tanto avete banda a sufficienza per una connessione non
compressa.
b) Almeno uno dei computer è connesso con un modem
analogico a 56K. In questo caso, il collo di bottiglia è invece la
connessione. Attivate il "Tight" encoder e impostate la compressione al
massimo.
Questi sono solo due esempi estremi e non vanno presi alla lettera. Se
la CPU del server è molto lenta o ha molto carico, potrebbe essere
opportuno non impostare la compressione al massimo neanche su modem a
56K. E se la LAN da 100 Mbit è sovraccarica, magari un po' di
compressione può essere di aiuto. Il mio consiglio quindi è:
a) prima di tutto, in base a quanto scritto qui sopra,
scegliete la distribuzione di VNC più veloce per il vostro sistema;
b) poi armatevi di pazienza, fate un po' di prove sul
campo e cercate il miglior compromesso tra velocità di
codifica/decodifica e velocità di trasmissione.
Dipende. Il server di VNC, per funzionare, deve necessariamente aprire una porta TCP e restare in attesa di una connessione. Qualche malintenzionato potrebbe entrare se la password di VNC è banale, oppure potrebbe tentare di sfruttare qualche "bug" non ancora scoperto di VNC per eseguire codice arbitrario sulla macchina. In generale, installare VNC comporta gli stessi rischi che comporta installare un qualunque servizio sulla macchina. La password con cui ci si autentica all'inizio della connessione non viene inviata in chiaro, quindi non può essere intercettata. Dopo l'autenticazione, però, la connessione prosegue in chiaro e quindi in teoria può essere intercettata. Intercettare una sessione di VNC non è per nulla facile, visto che non è composta da una serie di stringhe di testo come una sessione telnet, però in teoria il rischio c'è. Inoltre, la password di VNC è una sola, che deve essere quindi nota a tutti gli utenti. È vero che è possibile impostare diverse password, ma solo in base all'utente attualmente collegato in locale, non in base all'utente che cerca di collegarsi da remoto. Quindi, visto che la password dovrà essere nota a un certo numero di persone, è possibile che qualche malintenzionato la scopra anche se è stata scelta in maniera opportuna. La probabilità che ciò avvenga è direttamente proporzionale al numero di persone che debbono essere a conoscenza della password. Salvo esigenze molto particolari, è sempre consigliabile "proteggere" VNC con un tunnel SSH, che fornisce ben altre garanzie di sicurezza sia in fase di autenticazione che durante la connessione vera e propria.
In linea puramente teorica, se state lavorando su una macchina con VNC
installato e attivo, qualcuno potrebbe collegarsi dall'esterno, vedere
esattamente il vostro stesso desktop e spiare tutto quello che fate. In
pratica questo rischio non si pone per una serie di motivi:
a) L'icona di VNC nella tray area cambia colore in
presenza di una connessione attiva. Quindi nessuno può collegarsi per
spiarvi senza che voi ve ne accorgiate.
b) È buona norma impostare VNC per ignorare la
tastiera e il mouse locali in presenza di una connessione remota.
Questo per evitare che, ad esempio, mentre si sta lavorando da remoto
qualcuno urti per sbaglio il mouse "locale" sul tavolo e sposti il
cursore dal pulsante "OK" a quello "Annulla" proprio mentre si sta
premendo il pulsante del mouse remoto. Ma questo è anche un ulteriore
motivo per cui nessuno può collegarsi e spiarvi a vostra insaputa.
c) Se proprio dovete fare qualcosa di altamente
riservato e non volete correre alcun rischio, potete sempre disattivare
momentaneamente VNC o impostarlo per richiedere una password diversa da
quella standard quando voi siete loggati (se il vostro amministratore è
d'accordo, ovviamente).
d) Se il vostro amministratore vuole essere sempre e
comunque in grado di collegarsi alla vostra macchina con VNC, anche
mentre state lavorando, non dovete comunque preoccuparvi. Egli (se
vuole) ha infatti in ogni caso tanti di quei metodi per spiarvi che
disattivare VNC non gli cambia davvero nulla... ;-).
e) Se disattivate l'icona di VNC nella tray area,
lasciate il mouse e la tastiera locali attivi durante la connessione
remota, non proteggete VNC con SSH e usate "pippo" come password di
VNC, beh, in questo caso ve la siete proprio cercata! ;-)
Una trattazione completa di SSH è al di là degli scopi di questo documento. Si rimanda pertanto ai link forniti in calce. Per gli scopi che ci prefiggiamo ci basterà dire che SSH (che vuole dire "Secure SHell") è un protocollo che consente di aprire una finestra di terminale in modalità a caratteri su una macchina remota ed utilizzarla come se si fosse in locale. Non è assolutamente un'alternativa a VNC, visto che consente solo di aprire un terminale remoto in modalità a caratteri e non di avere un desktop grafico remoto, però ne è il complemento ideale. La connessione SSH tra due macchine è interamente criptata e quindi non è intercettabile. Le password non vengono inviate in chiaro sulla rete, ma criptate anch'esse. L'autenticazione dell'utente può avvenire sia con le tradizionali password di login che con un sistema di firma digitale con chiave DSA o RSA. Inoltre SSH può essere usato per creare un tunnel cifrato tra le due macchine per farvi passare un altra connessione TCP: il client si mette in ascolto su una determinata porta sull'indirizzo IP locale e qualunque connessione a quella porta viene inviata attraverso il canale cifrato SSH ad una opportuna porta sulla macchina remota. In questo modo è possibile connettersi su un canale criptato a servizi che in teoria non supporterebbero questa possibilità. Ad esempio è possibile connettersi a un server di posta POP3 attraverso un canale cifrato SSH, mettendo in comunicazione con un tunnel la porta 110 locale con la porta 110 del computer remoto. Oppure è possibile collegarsi su un canale criptato con VNC a una macchina remota a cui ci si sia preventivamente collegati con SSH. Esistono due versioni del protocollo SSH: SSH1 e SSH2. La prima è ormai vecchia ed ha anche alcuni problemi di sicurezza, completamente assenti nella seconda. Si sconsiglia pertanto nel modo più assoluto di installare sistemi di connessione che supportino solo il vecchio protocollo SSH1. Nel seguito, quando mi riferirò al protocollo SSH, sarà implicito che sto parlando di SSH2.
Vi sono essenzialmente solo due programmi in grado di funzionare da server SSH. Il primo si chiama, per l'appunto, "SSH" ed è quello che per primo ha introdotto questo protocollo (sia nella versione 1 che nella versione 2). E gratuito solo per uso non commerciale o anche per uso commerciale nella sola versione per Unix. Il secondo si chiama "OpenSSH" ed è stato sviluppato in maniera indipendente dal primo dal team di sviluppo di OpenBSD. È totalmente gratuito per ogni piattaforma. Tutto quello che dirò nel seguito riguarda OpenSSH, ma è applicabile anche a SSH con minimi aggiustamenti.
Per quanto riguarda invece il client, sia SSH che OpenSSH ne comprendono uno. A volte, però, potrebbe non essere possibile o semplicemente essere scomodo installare un sistema SSH completo sul PC da cui ci si vuole connettere. Questo soprattutto nel caso in cui il PC in questione usi Windows, visto che SSH viene installato quasi di default sia in Linux che in Unix. Si preferirebbe quindi avere un semplice client SSH per Windows che consenta di connettersi alla propria macchina, magari abbastanza piccolo e compatto da entrare nello stesso floppy su cui ci portiamo appresso il client VNC, e che non richieda alcuna installazione. Un programma del genere (un vero e proprio "coltellino svizzero") esiste e si chiama PuTTY.
Dipende dalla macchina, ovviamente. Se è una macchina Unix/Linux/BSD/ecc. ci sono ottime probabilità che SSH sia già installato di default. Se non lo è, chiedete al più presto al vostro amministratore di installarlo. Nel caso siate voi l'amministratore, non abbiate timore: tutto quello che dovete fare è scaricare da internet l'archivio .tar.gz del programma che avete deciso di installare, scompattarlo in una cartella temporanea e poi compilarlo e installarlo con gli script forniti (a patto di avere già installate tutte le librerie necessarie alla compilazione). Ovviamente poi dovrete leggere attentamente la manpage relativa e impostare le dovute opzioni nel file di configurazione. Infine dovrete riprendere la lettura di questo documento e configurare SSH in modo da consentire il tunnel della connessione VNC.
Se invece la vostra è una macchina Windows, le cose si fanno
leggermente più complicate. Non perché non esista la possibilità di
installare SSH sotto Windows, anzi, ma perché la procedura è abbastanza
diversa da una normale installazione di un programma per Windows, a
meno che non vi rivolgiate alla versione commerciale di SSH.
Principalmente avete due possibilità.
a) La prima è installare Cygwin, che è un ambiente
simil-Unix per Windows. Cygwin consente di compilare sotto Windows in
maniera quasi indolore programmi scritti per Unix, rendendo disponibili
una serie di funzioni che invece Windows non supporta in maniera
nativa. Cygwin comprende al suo interno versioni ricompilate per
Windows di moltissimi programmi, tra cui anche OpenSSH. Il programma
di installazione di Cygwin consente di scegliere quali "pacchetti"
installare, quindi non è necessario installare l'ambiente completo se è
solo OpenSSH che si vuole avere. Installando Cygwin, tra le altre cose,
si avrà anche la possibilità di connettersi tramite SSH alla propria
macchina Windows con una vera e propria finestra di terminale remoto in
modalità a caratteri, con "bash" come shell di sistema.
b) La seconda possibilità è usare una versione di
OpenSSH esplicitamente "portata" sotto Windows resa disponibile da Networksimplicity.
In questo caso l'installazione è più semplice, ma bisogna rinunciare a
un pò di cose che non possono essere supportate da Windows in maniera
nativa. Ad esempio la finestra di terminale remoto usa command.com o
cmd.exe invece di bash come shell. Questa versione di OpenSSH non è più
né sviluppata né supportata dall'autore, quindi è altamente
consigliabile usare quella di Cygwin, visto che può essere utile per
una marea di altre cose (include tra l'altro anche una versione ad hoc
sia di X-Free86 come server X che di KDE, WindowMaker, XFCE, ecc., nel
caso servisse stabilire una sessione X remota...).
Nel file di configurazione del server SSH (solitamente "/etc/sshd_config") è necessario specificare l'opzione "AllowTCPForwarding yes". Nel caso non si stia usando OpenSSH, la sintassi del comando potrà essere leggermente diversa. Anche se non è richiesto per la connessione con VNC, si consiglia di disabilitare nel suddetto file di configurazione tutti i sistemi di autenticazione che non verranno usati. Se si decide di autenticare gli utenti con le password tradizionali, lasciare solo "PasswordAuthentication" su "yes" e impostare tutte le altre opzioni su "no". Analogamente, se si opta per l'autenticazione con firma digitale, impostare solo "PubkeyAuthentication" su "yes" e tutte le altre su "no". E così via. In questo modo eventuali "bug" di OpenSSH nella gestione dei metodi di autenticazione non utilizzati non mineranno la sicurezza del sistema. Si consiglia inoltre di disabilitare del tutto il supporto al vecchio protocollo SSH1, per evitare che una errata configurazione del client SSH causi l'apertura di una connessione meno sicura di quello che si pensa.
Questa è una parte abbastanza delicata. Non basta infatti impostare VNC per accettare le connessioni attraverso il tunnel SSH, ma è necessario impostarlo per accettare solo le connessioni provenienti dal tunnel SSH. Diversamente, l'uso del tunnel sarebbe solo una inutile complicazione per gli utenti autorizzati, mentre i malintenzionati lo eviterebbero senza problemi. Quando si stabilisce il tunnel SSH, è lo stesso server SSH installato sulla macchina ad aprire la connessione alla porta a cui punta il tunnel. Quindi, dal punto di vista di VNC, una connessione attraverso un tunnel SSH è una connessione sull'interfaccia 127.0.0.1, cioè che proviene dalla stessa macchina su cui VNC è installato. Questo tipo di connessioni è rifiutato di default da VNC, ma in questo caso la connessione è fatta a partire dalla stessa macchina solo in apparenza, a causa della presenza del tunnel, e quindi bisogna impostare VNC per accettarla. Di più, bisogna impostare VNC per accettare solo le connessioni che provengono dalla stessa macchina, in modo da far sì che ci si possa connettere a VNC solo attraverso il tunnel SSH. Nel caso si stia usando TightVNC (o una versione da esso derivata) sotto Windows, nella finestra delle opzioni avanzate è necessario spuntare sia la casella "Allow loopback connections" che la casella "Allow only loopback connections". Nel caso invece in cui si stia usando VNC "liscio", sarà necessario modificare un paio di chiavi nel registro di configurazione (si rimanda al manuale di VNC per una spiegazione dettagliata). Nel caso in cui si sia usando VNC (qualunque versione, almeno che io sappia) sotto Unix, sarà necessario lanciare il server VNC con il parametro "-localhost".
Ok, questo è più facile. Nel caso stiate usando il client di OpenSSH dalla riga di comando di Cygwin o di una macchina Unix, dovete usare il seguente parametro: "-L 5901:127.0.0.1:5900". Questo parametro vuole dire che le connessioni effettuate sulla macchina locale alla porta 5901 verranno inviate in tunnel alla porta 5900 (quella di VNC) della macchina remota sull'interfaccia del localhost (questo è il senso di quel 127.0.0.1). In altre parole, alla macchina remota sembrerà che qualcuno tenti di connettersi alla porta 5900 a partire da sé stessa e VNC quindi accetterà la connessione. Se invece state usando PuTTY, c'è una apposita finestra di dialogo in cui specificare i tunnel da stabilire, con la stessa sintassi vista qui sopra: dalla 5901 alla 127.0.0.1:5900. La scelta di usare la porta 5901 invece della 5900 sulla macchina locale è motivata dal fatto che anche su questa macchina vi potrebbe essere installato VNC e in tal caso la porta 5900 sarebbe già impegnata. Le porte ai due estremi del tunnel SSH possono essere benissimo diverse, non c'è motivo per cui debbano essere uguali. Attivare la compressione dei dati sul canale SSH non è una buona idea se si usa TightVNC. Infatti in tal caso la connessione è già compressa il più possibile e una ulteriore compressione ottiene il solo risultato di assorbire risorse dalla CPU del sistema (sia di quello locale che di quello remoto) senza apportare benefici in termini di richieste di banda.
Questa è la parte più facile. Basta impostarlo per connettersi a "127.0.0.1:1", cioè alla porta 5901 della macchina locale (che è il primo estremo del tunnel). Ovviamente la connessione SSH con il relativo tunnel dovrà essere già aperta. La connessione verrà inviata automaticamente e in modo del tutto trasparente alla porta 5900 della macchina remota (l'altro estremo del tunnel) dove il server VNC è in ascolto. Dovrete solo fare un pò di prove per trovare i valori ottimali delle opzioni di compressione nel client di TightVNC. Infatti, mettendo tutte le impostazioni al massimo la banda richiesta è minima, ma l'utilizzo di CPU sia sul server che sul client è massimo e questo rallenta il sistema. Viceversa, a una compressione minima corrisponde un utilizzo minimo della CPU ma una richiesta di banda molto maggiore, banda che potrebbe non essere disponibile. La massima velocità si ottiene quindi impostando la compressione al livello minimo consentito dalla vostra connessione, e questo livello potrà essere trovato solo con un pò di prove.
VNC "liscio": http://www.uk.research.att.com/vnc
RealVNC: http://www.realvnc.com
TightVNC: http://www.tightvnc.org
VdaccVNC: http://services.simac.be/vnc
eSVNC: http://perso.wanadoo.fr/samfd/esvnc
Ultr@VNC: http://ultravnc.sourceforge.net
TridiaVNC: http://www.tridiavnc.com
uVNC: http://www.sics.se/~adam/uvnc
PalmVNC: http://palmvnc2.free.fr
VNCviewer for PocketPC: http://www.cs.utah.edu/~midgley/wince/vnc.html
Una fonte inesauribile di informazioni è costituita dalle mailing list su VNC. Ne trovate un elenco alla pagina: http://www.uk.research.att.com/vnc/intouch.html. Vi è anche una lista specifica su TightVNC raggiungibile da http://www.tightvnc.org. Queste mailing list sono accessibili anche su usenet tramite il server news.gmane.org.
Poi, ovviamente, c'è il link dei link: http://www.google.com... ;-)
SSH: http://www.ssh.com
OpenSSH: http://www.openssh.org
Cygwin: http://www.cygwin.com
NetworkSimplicity: http://www.networksimplicity.com/openssh/
PuTTY: http://www.chiark.greenend.org.uk/~sgtatham/putty/
