====== 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 =====

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//):

<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>
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%%**''.

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 =====

KDE’s VNC management tool.

===== rdesktop =====

Client per Windows NT/2000 Terminal Server.

===== ssh =====

==== Port forward ====

Port forward sulla connessione ssh:

<code>
ssh -g -L <local_port>:<remote_host>:<remote_port> user@remote.host
</code>

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 ====

Per consentire l'accesso root da remoto e per consentire il forward di X11 in /etc/ssh/sshd_config si imposta:

<code>
X11Forwarding yes
PermitRootLogin yes
</code>

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**:

<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 ====

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''**:

<code>
nohup wget http://http.debian.org/cdimage.iso &
</code>

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''**.

===== VNC dietro a firewall =====

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**):

<code>
ssh root@paros.rigacci.org -g -R *:5500:localhost:5500
</code>

Quindi il client lancia il vncviewer su localhost:

<code>
vncviewer -listen
</code>

Il server avvia VNC con l'opzione connect:

<code>
winvnc -connect paros.rigacci.org::5500
</code>