Differences

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

--- doc:appunti:linux:tux:remote_desktop [2007/10/02 20:39] – external edit 127.0.0.1
+++ doc:appunti:linux:tux:remote_desktop [2017/05/31 12:46] – [X11 forward] niccolo
@@ Line 1: / Line 1: @@
 ====== Desktop remoto con Linux ======
+===== vncserver e vncviewer =====
+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.
+===== 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 =====
@@ Line 14: / Line 32: @@
 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]].
+Anche ''x11vnc'' supporta il viewer Java tramite http, dopo aver installato il pacchetto **vnc-java** si esegue ''x11vnc'' con la sintassi:
+<code>
+x11vnc -httpdir /usr/share/vnc-java
+</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 39: / Line 107: @@
 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 48: / Line 133: @@
 </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 54: / Line 139: @@
 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 ====