Desktop-Fernsteuerung

Eine abgesicherte Fernsteuerung (Remote Control) von PCs mittels einzelner grafischer Anwendungen ist ja bekanntermaßen leicht mit der Secure Shell möglich. Mit ssh -X -C user@pc wird ein SSH-Tunnel mit X11 Forwarding eingerichtet, wobei die Zusatzoption ‚-C‘ Datenkompression aktiviert.

Damit lassen sich aber nur einzelne Anwendungen weiterleiten und keine komplette Desktopumgebungen. Um solche umfangreichen Lösungen soll es nun hier gehen.

Instant-Lösungen

  • TeamViewer - etablierte Software (auch LAN-only nutzbar)

  • AnyDesk - modern, effizient (das generische Paket reicht für ein Starten mit eingeschränkten Rechten aus, wenn vorher das Debian-Paket libgtkglext1 installiert wurde)

  • UltraScreen - bietet nur Screen Sharing (als AppImage verfügbar)

Klassische Lösungen

  • X Display Manager Control Protocol (XDMCP), in der X11-Archtitektur integriert (keine weitere Software erforderlich), die Anmeldung geschieht am entfernt laufendenden Display Manager

  • Virtual Network Computing (VNC), altes Unix-Fersteuerverfahren in vielen Implementierungen (Paket „tightvncserver“ für spätere Integration in lightdm erforderlich)

  • Remote Desktop Protocol (RDP), proprietäres Netzwerkprotokoll von Microsoft, unter Linux ebenfalls nutzbar, sehr performant

  • SPICE, eher zum Fernsteuern von VMs, => https://www.heise.de/ix/artikel/Gewuerzmischung-1748671.html

  • X2go (anfänglich leicht einzurichten, eher in die Rubrik Terminal-Server einzuordnen)

  • LTSP (gestandenes und frisch überarbeitetes Linux Terminal Server Project)

XDMCP

Das X Display Manager Control Protocol ist direkt in einem typischen X11-Window-System enthalten und muss nur aktiviert werden.

  1. Server: Xorg, via Debian 10 mit lightdm und XFCE-Desktop

  2. Clients: Xephyr (Linux), MobaXterm (Windows)

Wir bearbeiten die Konfigurationsdatei des Display-Managers „lightdm“ namens /etc/lightdm/lightdm.conf und setzen die Konfiguration auf die folgenden Werte:

[XDMCPServer]
enabled=true

Unter Debian installiere man sich nun das Paket xserver-xephyr, danach lässt sich testweise z.B. auch vom eigenen Hosts aus mittels Xephyr -query localhost :1 -screen 1024x768 eine Verbindung zum Login-Verwalter aufbauen. Allerdings müssen wir einen anderen Sitzungstyp als den voreingestellten „XFCE“ benutzen; am besten den Fenstermanager ‚openbox‘ auswählen (der natürlich installiert sein muss).

Unter Windows gibt es in MobaXterm guten XDMCP-Support. Eine solche Sitzung ist leicht eingerichtet, allerdings kann es im Zusammenhang mit der Netzwerkkonfiguration zu Problemen kommen („DEBUG: Send Decline(status=‘No valid address found‘…“), was in ähnlicher Weise hier beschrieben ist. Abhilfe schafft bei Benutzung von VirtualBox das Koppeln der VM via „Host-only-Netzwerk“ (192.168.56.0/24).

Nach einem systemctl restart lightdm verrät uns lsof -nPi:177, dass XDMCP auf eingehende Anfragen lauscht.

VNC

Beim Virtual Network Computing kommt das Remote Framebuffer Protocol zum Einsatz - ein altgestandenes Protokoll, was Plattformunabhängigkeit garantiert.

VNC für Login via Display-Manager

Im ersten Einsatzszenario soll VNC bereits für den Loginprozess genutzt werden. Als Voraussetzung installieren wird das Paket „tightvncserver“, damit der Display-Manager dann tatsächlich den Port 5900 öffnen kann:

root@LinPC ~# apt-get install tightvncserver
...

Nun bearbeiten wir wiederum die Konfigurationsdatei /etc/lightdm/lightdm.conf und setzen die Konfiguration auf folgende Werte:

[VNCServer]
enabled=true

Nach einem abschließenden systemctl restart lightdm verrät uns lsof -nPi:5900, dass VNC auf eingehende Anfragen lauscht.

Als Windows-Client kann wieder das oben genannte MobaXterm verwendet werden. Eine VNC-Session in MobaXterm mit Standard-Port 5900 fragt allerdings nach einem initialen Passwort, was wir aber NICHT eingeben müssen (Feld leer lassen); wir wollen ja den normalen Display-Manager zu Gesicht bekommen, der dann den Login vornimmt.

VNC als normaler Nutzer

In diesem zweiten Szenario möchte ein einfacher Nutzer seinen Desktop nur gelegentlich freigeben. Dazu muss wiederum das Paket tightvncserver installiert sein.

Mit dem Kommando vncserver kann er nun ganz einfach den Server starten, wobei er ein Passwort für vollen Zugriff festlegen muss; - und ein zweites für reines, passives Zuschauen („view-only password“) vergeben kann. Der Zugriff von Entfernt geschieht dann a) via Hostname/IP-Adresse, b) die VNC-Display-Nummer :1 (= 1. Display, = TCP-Port 5901) sowie c) das festgelegte Passwort. Den üblichen Nutzernamen gibt es hierbei nicht, was Multiuserbetrieb nicht ausschließt: ein anderer Nutzer auf derselben Maschine, der vncserver startet, würde sein separates Passwort mit der Display-Nummer :2 (= 2. Display, = TCP-Port 5902) ins Spiel bringen.

Eine solche, erste Sitzung sieht folgendermaßen aus:

tux@LinPC:~$ vncserver

You will require a password to access your desktops.

Password:
Verify:
Would you like to enter a view-only password (y/n)? n

New 'X' desktop is LinPC:1

Creating default startup script /home/tux/.vnc/xstartup
Starting applications specified in /home/tux/.vnc/xstartup
Log file is /home/tux/.vnc/LinPC:1.log

tux@LinPC:~$

Hierbei wird nun der TCP-Port 5901 geöffnet, auf den clientseitig im Folgenden über die VNC-Display-Nummer :1 zugegriffen werden kann. Damit das erst einmal problemlos funktioniert, ist es ratsam, auf dem Server ein minimales X-Window-System einzurichten, wie es [weiter unten] bei der Fehlersuche von RDP beschrieben ist.

Der Linux-Client installiert sich unter Debian als Voraussetzung das Paket xtightvncviewer und kann dann die Sitzung starten (Das einzugebende Passwort ist das, was soeben beim Starten von ‚vncserver‘ gesetzt wurde.):

tux@d10wks :~$ vncviewer 192.168.2.107:1
Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions
Performing standard VNC authentication
Password:

Authentication successful
Desktop name "tux's X desktop (LinPC:1)"
VNC server default format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor.  Pixel format:
32 bits per pixel.
Least significant byte first in each pixel.
True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
tux@d10wks :~$

Dabei sind jetzt insgesamt folgende Ports geöffnet worden (177 für XDMCP, 5900 für lightdm und 5901 für die benutzerdefinierte Sitzung):

root@LinPC ~# lsof -Pni:177,5900-5905
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
Xtightvnc 7500  tux    3u  IPv4  80008      0t0  TCP *:5901 (LISTEN)
lightdm   7996 root   11u  IPv4  88387      0t0  UDP *:177
lightdm   7996 root   12u  IPv6  88388      0t0  UDP *:177
lightdm   7996 root   13u  IPv4  88389      0t0  TCP *:5900 (LISTEN)
root@LinPC ~#

VNC via SSH für Remote Support

Mit dem folgenden Skript ist es relativ einfach, einem bestimmten entfernten Nutzer einen SSH-Login auf der eigenen Maschine als Nutzer ‚meetme‘ einzuräumen, auf welcher der Helfer bereits mittels vncviewer -listen auf ihn wartet (= Reverse VNC Session):

#!/bin/sh
#
# netzhelfer-upload.sh

cat > /tmp/netzhelfer <<EOF
#!/bin/sh
#
# netzhelfer
# Axel Pemmann
# Siehe dazu https://wiki.ubuntuusers.de/VNC#Reverse-VNC-Verbindung-ueber-SSH-Verbindung

### Der helfende Linux-Admin:
## ...lädt dieses Skript mit aktualisierter IP-Adresse auf Relaystation hoch: http://myhomeserver.spdns.org/netzhelfer
#   vncviewer -listen
#   vncviewer -listen -geometry 1024x768 -LowColourLevel 2

### Der Hifesuchende:
## ...führt dann folgendes aus (gern via .desktop-Datei):  wget -O - http://myhomeserver.spdns.org/netzhelfer | bash
#   Voraussetzung: apt install x11vnc
ssh -NfL 5500:localhost:5500 meetme@$(wget -qO- v4.ifconfig.co) sleep 2 && \
    x11vnc -ncache 10 -connect_or_exit localhost:5500 -scale 1024x768 -solid darkblue
EOF

# Bereitstellen des Skriptes 'netzhelfer' auf einem geeigneten Webserver (= "Relaystation"):
scp /tmp/netzhelfer uploader@myhomeserver.spdns.org:/srv/www/html

RDP

Mittels apt-get install xrdp installieren wir die Software. Unter Debian 10 ist die Installation des Pakets „tigervnc-standalone-server“ nicht mehr erforderlich, weshalb als Sitzungstyp im Sesman (= Session Manager) auch nicht mehr „Xvnc“ ausgewählt werden muss; „X11“ funktioniert jetzt problemlos:

root@LinPC ~# grep 3389 /etc/services
root@LinPC ~#
root@LinPC ~# lsof -iTCP:3389 -Pn
root@LinPC ~#
root@LinPC ~#
root@LinPC ~# systemctl status xrdp
● xrdp.service - xrdp daemon
Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: enabled)
Active: inactive (dead)
    Docs: man:xrdp(8)
        man:xrdp.ini(5)

Jun 15 12:36:02 LinPC systemd[1]: /lib/systemd/system/xrdp.service:8: PIDFile= references path below legacy directory /v
Jun 15 12:36:02 LinPC systemd[1]: /lib/systemd/system/xrdp.service:8: PIDFile= references path below legacy directory /v
Jun 15 12:36:03 LinPC systemd[1]: /lib/systemd/system/xrdp.service:8: PIDFile= references path below legacy directory /v
Jun 15 12:36:03 LinPC systemd[1]: /lib/systemd/system/xrdp.service:8: PIDFile= references path below legacy directory /v
root@LinPC ~#
root@LinPC ~#
root@LinPC ~# systemctl start xrdp
root@LinPC ~#
root@LinPC ~# systemctl status xrdp
● xrdp.service - xrdp daemon
Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2020-06-15 12:39:05 CEST; 2s ago
    Docs: man:xrdp(8)
        man:xrdp.ini(5)
Process: 9002 ExecStartPre=/bin/sh /usr/share/xrdp/socksetup (code=exited, status=0/SUCCESS)
Process: 9010 ExecStart=/usr/sbin/xrdp $XRDP_OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 9011 (xrdp)
    Tasks: 1 (limit: 966)
Memory: 1.0M
CGroup: /system.slice/xrdp.service
        └─9011 /usr/sbin/xrdp

Jun 15 12:39:04 LinPC systemd[1]: Starting xrdp daemon...
Jun 15 12:39:04 LinPC xrdp[9010]: (9010)(140694867613504)[DEBUG] Testing if xrdp can listen on 0.0.0.0 port 3389.
Jun 15 12:39:04 LinPC xrdp[9010]: (9010)(140694867613504)[DEBUG] Closed socket 7 (AF_INET6 :: port 3389)
Jun 15 12:39:04 LinPC systemd[1]: xrdp.service: Can't open PID file /run/xrdp/xrdp.pid (yet?) after start: No such file
Jun 15 12:39:05 LinPC systemd[1]: Started xrdp daemon.
Jun 15 12:39:06 LinPC xrdp[9011]: (9011)(140694867613504)[INFO ] starting xrdp with pid 9011
Jun 15 12:39:06 LinPC xrdp[9011]: (9011)(140694867613504)[INFO ] listening to port 3389 on 0.0.0.0
root@LinPC ~#
root@LinPC ~#
root@LinPC ~# lsof -iTCP:3389 -Pn
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
xrdp    9011 xrdp   11u  IPv6  95766      0t0  TCP *:3389 (LISTEN)
root@LinPC ~#
root@LinPC ~#

Als normaler Nutzer von einer anderen Maschine aus:

root@LinPC ~# # rdesktop 192.168.2.107
root@LinPC ~# #
root@LinPC ~# # (der Sitzungstyp X11 funktioniert hier prima, kein weiteres VNC-Paket 'tigervnc-standalone-server' erforderlich)
root@LinPC ~#
root@LinPC ~#
root@LinPC ~# dpkg -l tigervnc-standalone-server
dpkg-query: Kein Paket gefunden, das auf tigervnc-standalone-server passt
root@LinPC ~#

Mittels MobaXterm ist nun auch eine RDP-Sitzung problemlos möglich und auch der Windows-RDP-Terminalclient funktioniert gut (WIN: rdp).

Hinweise zur Fehlersuche:

  • Bitte darauf achten, dass kein User-Prozess von ‚vncserver‘ existiert (von vorherigen Experimenten), der Session-Manager kann sonst u.U. nicht den nativen Login via Xorg nutzen.

  • Minimales X-Window-System: Es macht sich für erste Tests gut, eine kleine Umgebung nur mit openbox und tint2 zu benutzen. Der betreffende User kann sich dazu auf dem Server die erforderliche Konfigurationsdatei ~/.xsession ganz einfach mit folgendem Inhalt erstellen:

    # Datei ~/.xsession
xterm &
tint2 &
exec openbox

Und natürlich nicht vergessen, die Pakete xterm, tint2 und openbox zu installieren.