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. a) Server: Xorg, via Debian 10 mit lightdm und XFCE-Desktop b) 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: .. highlight:: bash :: [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: .. highlight:: shell-session :: root@LinPC ~# apt-get install tightvncserver ... Nun bearbeiten wir wiederum die Konfigurationsdatei ``/etc/lightdm/lightdm.conf`` und setzen die Konfiguration auf folgende Werte: .. highlight:: bash :: [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: .. highlight:: shell-session :: 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 :ref:`[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): .. highlight:: bash :: #!/bin/sh # # netzhelfer-upload.sh cat > /tmp/netzhelfer <`_ - https://wiki.ubuntuusers.de/VNC/#Reverse-VNC-Verbindung-ueber-SSH-Verbindung - http://blog.jochenschwenk.de/2018/05/20/fernwartung-mit-ultravnc-und-securevncplugin/ - https://www.linux-magazin.de/ausgaben/2016/06/bitparade/6/