Differences

This shows you the differences between two versions of the page.

--- doc:appunti:linux:tux:remote_desktop [2009/03/30 13:59] – niccolo
+++ doc:appunti:linux:tux:remote_desktop [2022/01/31 16:25] (current) – [x11vnc] niccolo
@@ Line 5: / Line 5: @@
 Su una Debian Lenny si hanno diverse possibilità di scela per VNC client e server:
-  * **vnc4server** e **xvnc4viewer**
+  * **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**
+  * **tightvncserver** e **xtightvncviewer**, rispetto al tradizionale VNC versione 3 offre un protocollo ottimizzato per connessioni a banda stretta.
-  * **krdc**
+  * **krdc** software client, integrato con l'ambiente KDE.
+===== VNC Java Viewer =====
+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
+<code>
+http://remotehost:5800/
+</code>
 ===== x11vnc =====
-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.
+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).
-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'':
+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//):
 <code>
-# ps uax | grep X | grep auth
+x11vnc -display :0
-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
 </code>
-Quindi ci si connette con un client VNC alla porta opportuna (default 5900). La sessione termina al logout dell'utente. Ulteriori dettagli in [[http://www.karlrunge.com/x11vnc/|x11vnc: a VNC server for real X displays]].
+L'utente remoto esegue invece:
+<code>
+xtightvncviewer <ip_address>:0
+</code>
+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**:
+<code>
+x11vnc -auth guess -display :0 -noxdamage
+</code>
+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**.
+<code>
+ps uax | grep Xorg | grep auth
+... /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
+</code>
+==== Condivisione dekstop ====
+Il programma **''x11vnc''** può essere usato per condividere il desktop, in sola visione, con password:
+<code>
+x11vnc -ncache 10 -viewonly -passwd MySecret -speeds dsl
+</code>
+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.
+===== Reverse connection =====
+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:
+<code>
+vncviewer -listen
+</code>
+La porta di default è la **TCP 5500**. Chi vuole condividere il desktop esegue:
+<code>
+x11vnc -connect <viewer_host>:5500
+</code>
 ===== krdc =====
-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 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:
+<code>
+krdc rdp://192.168.0.21
+</code>
+==== Problema mappatura tastiera ====
+C'è un problema se ci si trova in queste condizioni:
+  * Host remoto configurato per tastiera italiana
+  * krdc eseguito da client configurato con tastiera italiana
+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.
+==== Ctrl-Alt-Del ====
+Per inviare la combinazione speciale **''Ctrl-Alt-Del''** (es. per logon o task manager di Windows) basta premere **''Ctrl-Win-Alt-Del''**.
 ===== krfb =====
@@ Line 47: / Line 122: @@
 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.
+==== HTTP proxy con SOCKS5 server ====
+Per navigare usando l'IP di una macchina remota:
+aprire una connessione ssh con la macchina remota allocando un socket SOCKS5:
+<code>
+ssh -D 8080 remote.host
+</code>
+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:
+<code>
+chromium --proxy-server=socks://localhost:8080
+</code>
 ==== X11 forward ====
@@ Line 56: / Line 148: @@
 </code>
-Per far funzionare il forward automatico di X11 si deve avere (sul server) il programma ''**xauth**'', incluso nel pacchetto ''**xbase-clients**''.
+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.
@@ Line 62: / Line 154: @@
 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**:
+<code>
+X11 forwarding request failed on channel 0
+</code>
+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
+<file>
+AddressFamily inet
+</file>
 ==== Comandi in backgroung in shell remota ====