Su una Debian Lenny si hanno diverse possibilità di scela per VNC client e server:
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/
Il programma x11vnc consente di condividere tramite protocollo di rete VNC uno schermo X11 esistente, cioè una sessione già iniziata oppure la schermata di login del display manager.
Sulla postazione che vuole condividere lo schermo X11 (il server) si installa il pacchetto x11vnc, sul client remoto si installa un client VNC, ad esempio xtightvncviewer contenuto nell'omonimo pacchetto Debian (es. Debian 10 Buster).
Esaminando il contenuto della variabile d'ambiente DISPLAY si determina qual'è lo schermo X11 utilizzato che si intende condividere, di solito si tratta di :0.0. Il primo zero indica il display e il secondo lo schermo (uno stesso display può avere più di uno schermo). L'utente proprietario della sessione lancia il comando (può omettere l'indicazione dello schermo):
x11vnc -display :0
L'utente remoto esegue invece:
xtightvncviewer <ip_address>:0
In alternativa a xtightvncviewer si può utilizzare krdc.
Con x11vnc è possibile anche prendere possesso remoto dello schermo dove sta girando il display manager (la richiesta di login di lightdm, ad esempio). Ovviamente si deve avere i permessi sul file auth, cioè si dovrà essere root:
x11vnc -auth guess -display :0 -noxdamage
Il parametro guess tenta di indovinare automaticamente qual'è l'X authority file che sta utilizzando il server Xorg. Se l'operazione guess dovesse fallire è possibile scoprirlo vedendo il processo Xorg in esecuzione (nell'esempio sotto si tratta del file /var/run/lightdm/root/:0):
Il parametro -noxdamage disabilita una estensione del protocollo che dovrebbe ottimizzare la ritrasmissione solo delle porzioni dello schermo che cambiano, purtroppo nel nostro caso (Debian 11) causava continui problemi di tipo caught XIO error.
ps uax | grep Xorg | grep auth ... /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
Il programma x11vnc può essere usato per condividere il desktop, in sola visione, con password:
x11vnc -ncache 10 -viewonly -passwd MySecret -speeds dsl
In teoria l'accoppiata krdc e krfb (client/server) sarebbero la scelta privilegiata per l'ambiente KDE, tuttavia c'è un bug (KDE 4.4.5) che impedisce la visualizzazione dei movimenti del mouse sul il desktop remoto.
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.
Per accedere ad un Remote Dektop Windows si deve installare anche il pacchetto rdesktop e lanciare un comando del tipo:
krdc rdp://192.168.0.21
C'è un problema se ci si trova in queste condizioni:
in pratica i tasti che differiscono fra tastiera IT e tastiera US non funzionano. La soluzione è cambiare (anche provvisoriamente, con le apposite applet) la tastiera del client, impostandola su US. In questo modo si ottiene una corrispondenza esatta fra tasti premuti (italiani) e keycode ricevuti dall'host remoto.
Il problema è stato riscontrato sia con client krdc che con client remmina, su Debian Jessie.
Per inviare la combinazione speciale Ctrl-Alt-Del (es. per logon o task manager di Windows) basta premere Ctrl-Win-Alt-Del.
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 navigare usando l'IP di una macchina remota:
aprire una connessione ssh con la macchina remota allocando un socket SOCKS5:
ssh -D 8080 remote.host
quindi configurare il browser (es. FireFox): Preferences, Advanced, Network, Settings, Manual proxy configuration, SOCKS Host: 127.0.0.1, Port: 8080.
Alcuni browser (es. Chromium) accettano l'impostazione del proxy da riga di comando, esempio:
chromium --proxy-server=socks://localhost:8080
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 xauth (nelle distro Debian più vecchie era 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.
Si potrebbe incappare nell'errore:
X11 forwarding request failed on channel 0
mostrato subito dopo il login sull'host remoto. Potrebbe essere causato dal tentativo di utilizzare IPv6 da parte di sshd. In questo caso una soluzione è restringere sshd all'uso di IPv4, impostando in /etc/ssh/sshd_config
AddressFamily inet
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