Differences

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

--- doc:appunti:linux:tux:remote_desktop [2009/09/18 09:07] – niccolo
+++ doc:appunti:linux:tux:remote_desktop [2022/01/31 16:25] (current) – [x11vnc] niccolo
@@ Line 21: / Line 21: @@
 ===== 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.
-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'':
+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//):
+<code>
+x11vnc -display :0
+</code>
+L'utente remoto esegue invece:
 <code>
-# ps uax | grep X | grep auth
+xtightvncviewer <ip_address>: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]].
+In alternativa a **xtightvncviewer** si può utilizzare **krdc**.
-Anche ''x11vnc'' supporta il viewer Java tramite http, dopo aver installato il pacchetto **vnc-java** si esegue ''x11vnc'' con la sintassi:
+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 -httpdir /usr/share/vnc-java
+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 63: / 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 72: / 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 78: / 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 ====