Differences

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

--- doc:appunti:linux:tux:remote_desktop [2016/04/22 12:11] – [krdc] niccolo
+++ doc:appunti:linux:tux:remote_desktop [2024/12/09 11:27] (current) – [Sessione X11 remota con client e server dietro firewall] 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>
+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>
-# ps uax | grep X | grep auth
+x11vnc -auth guess -display :0 -noxdamage
-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]].
+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**):
-Anche ''x11vnc'' supporta il viewer Java tramite http, dopo aver installato il pacchetto **vnc-java** si esegue ''x11vnc'' con la sintassi:
+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>
-x11vnc -httpdir /usr/share/vnc-java
+ps uax | grep Xorg | grep auth
+... /usr/lib/xorg/Xorg :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
 </code>
@@ Line 48: / Line 63: @@
 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 =====
+===== X11vnc con reverse connection =====
 Se l'host remoto è dietro ad un firewall, è possibile realizzare una connessione inversa dove il server VNC contatta il client in ascolto.
@@ Line 63: / Line 78: @@
 x11vnc -connect <viewer_host>:5500
 </code>
+===== Sessione X11 remota con client e server dietro firewall =====
+Nel caso in cui sia il server che il client si trovino dietro a rispettivi firewall, è possibile utilizzare un **server proxy** tramite il quale far transitare il traffico. Sul server proxy è necessario avere un **accesso ssh** e che sia presente l'opzione **GatewayPorts yes**.
+Questo uno esempio di script da eseguire come utente root sul server che vuole condividere la sessione X11:
+<code bash>
+#!/bin/sh
+PROXY_SERVER='proxy.server.org'
+PROXY_PORT='5500'
+DISPLAY="$(($PROXY_PORT - 5500))"
+if [ "$DISPLAY" -eq '0' ]; then
+    DISPLAY=""
+fi
+echo "======================================================================"
+echo "Execute X11VNC(1) connecting to the proxy ${PROXY_SERVER}:${PROXY_PORT},"
+echo "where sshd must be running with the option \"GatewayPorts yes\"."
+echo
+echo "The client must already be connected to the proxy with:"
+echo
+echo "  ssh $PROXY_SERVER -R $PROXY_PORT:localhost:$PROXY_PORT -N -f"
+echo "  vncviewer -listen $DISPLAY"
+echo
+echo "======================================================================"
+read -p "Press Enter to continue... " REPLY
+set -x
+x11vnc -auth guess -display :0  -connect "$PROXY_SERVER:$PROXY_PORT"
+</code>
+Il server **x11vnc** è fornito dall'omonimo pacchetto Debian, il client **vncviewer** può essere fornito dal pacchetto Debian **xtightvncviewer**.
 ===== 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:
@@ Line 79: / Line 128: @@
   * Host remoto configurato per tastiera italiana
-  * Clien su cui gira krdc configurato con 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.
@@ Line 118: / Line 167: @@
 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 127: / Line 182: @@
 </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 133: / Line 188: @@
 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 ====