Su una Debian Lenny si hanno diverse possibilità di scela per VNC client e server:

• vnc4server e xvnc4viewer, compatibile con il vecchio VNC versione 3, offre un nuovo protocollo ottimizzato per le connessioni a banda stretta, con prestazioni comparabili a quelle di tightVNC.
• tightvncserver e xtightvncviewer, rispetto al tradizionale VNC versione 3 offre un protocollo ottimizzato per connessioni a banda stretta.
• krdc software client, integrato con l'ambiente KDE.

Invece di utilizzare un VNC viewer standard, può essere comodo eseguire un VNC viewer all'interno di un browser web. In tal caso il server VNC si pone in ascolto su una porta diversa (solitamente la TCP 5800) e fornisce ai client l'applet Java necessaria.

Sull'host che esegue il vncserver si deve installare il pacchetto vnc-java che contiene l'applet, il server dovrebbe trovare automaticamente l'archivio jar necessario (altrimenti si utilizza il parametro -httpd). Infine si punta il browser all'url

http://remotehost:5800/

L'utente proprietario della sessione X lancia x11vnc -display :0, l'utente remoto esegue xvncviewer -fullscreen host:0. Il passaggio dalla modalità finestra a quella full-screen (F8 per attivare il pop-up), non funziona sul PC provato, bisogna partire direttamente full-screen. Sembra che sia un bug di xvncviewer, utilizzare krdc al suo posto.

Con x11vnc è possibile anche prendere possesso remoto dello schermo dove sta girando il display manager (la richiesta di login di kdm, ad esempio). Bisogna anzitutto scoprire quale X authority file sta utilizzando il server X, ed utilizzarlo con x11vnc:

# ps uax | grep X | grep auth
root      1839  0.2  3.8 19572 9880 ?        S<   18:59   0:28 /usr/X11R6/bin/X -nolisten tcp -auth /var/run/xauth/A:0-SZUARw vt7
x11vnc -auth /var/run/xauth/A:0-SZUARw -display :0

Quindi ci si connette con un client VNC alla porta opportuna (default 5900). La sessione termina al logout dell'utente. Ulteriori dettagli in x11vnc: a VNC server for real X displays.

Anche x11vnc supporta il viewer Java tramite http, dopo aver installato il pacchetto vnc-java si esegue x11vnc con la sintassi:

x11vnc -httpdir /usr/share/vnc-java

Se l'host remoto è dietro ad un firewall, è possibile realizzare una connessione inversa dove il server VNC contatta il client in ascolto.

Il client avvia il programma con:

vncviewer -listen

La porta di default è la TCP 5500. Chi vuole condividere il desktop esegue:

x11vnc -connect <viewer_host>:5500

KDE Remote Desktop Client, è il client VNC e RDP fornito con l'ambiente KDE. Migliore di xvncviewer, funziona il panning, Alt+Tab, iconize, ecc. Unico inconveniente è che per le connessioni VNC bisogna indicare obbligatoriamente il protocollo, ad esempio vnc:/217.19.150.150.

KDE’s VNC management tool.

Client per Windows NT/2000 Terminal Server.

Port forward sulla connessione ssh:

ssh -g -L <local_port>:<remote_host>:<remote_port> user@remote.host

L'opzione -g effettua il bind della porta locale su tutte le interfacce, altrimenti funzionerebbe solo la 127.0.0.1 e non si potrebbe condividere la porta forwardata con altri PC in LAN.

Per consentire l'accesso root da remoto e per consentire il forward di X11 in /etc/ssh/sshd_config si imposta:

X11Forwarding yes
PermitRootLogin yes

Per far funzionare il forward automatico di X11 si deve avere (sul server) il programma xauth, incluso nel pacchetto xbase-clients.

Il forward X11 significa che l'output X11 viene automaticamente rediretto dal server verso il display del client che si è connesso tramite ssh. In realtà la ridirezione avviene su un canale sicuro appositamente aperto tra ssh e sshd.

Quando da un client si lancia ssh si può specificare su riga di comando che vogliamo il forward di X11, con l'opzione -X, altrimenti viene consultato il file /etc/ssh/ssh_config, qui l'opzione ForwardX11 puo' essere impostata a yes per nessuno, per tutti o solo per specifici host.

Se si desidera eseguire in una shell remota dei comandi che impiegano molto tempo a terminare, può essere utile scollegarsi dalla shell e lasciare il comando in esecuzione. Normalmente chiudendo la shell i processi in background vengono terminati con un SIGHUP.

Ci sono due metodi per evitare questo, il primo è eseguire il comando tramite nohup:

nohup wget http://http.debian.org/cdimage.iso &

Altrimenti si utilizza il comando screen che apre un terminale virtuale. Dentro il terminale virtuale esegue tutto quello che si vuole, con Ctrl-A-D si esegue il detach dal terminale. In un secondo momento ci si ricollega al terminale virtuale eseguendo screen -r.

Se ci siamo dimenticati di avviare screen e si vuole agganciare un processo che sta girando in un altro terminale si può sperare di riprendere il processo con retty.

Supponiamo che il server VNC (es. PC Windows che richiede assistenza remota) ed anche il client (es. PC Linux con vncviewer) siano entrambi dietro ad un firewall e non sia possibile attivare un port forwarding, è possibile darsi appuntamento su un host con IP pubblico. Si utilizza una connessione iniziata dal server, in questo caso è il vncviewer che si mette in ascolto su una porta.

Il client, dovunque sia, si connette in ssh all'host pubblico reindirizzando in locale la porta 5500 remota (si deve fare accesso come root ed è necessario che il server ssh abbia l'opzione GatewayPorts yes):

ssh root@paros.rigacci.org -g -R *:5500:localhost:5500

Quindi il client lancia il vncviewer su localhost:

vncviewer -listen

Il server avvia VNC con l'opzione connect:

winvnc -connect paros.rigacci.org::5500