Linux Remote-Desktop im Eigenbau

  Lioh Möller   Lesezeit: 7 Minuten  🗪 19 Kommentare

Wie sperrt man Microsoft Teams auf einen Desktop in der Cloud, oder ein Linux Remote-Desktop im Eigenbau.

linux remote-desktop im eigenbau

Die Idee begann damit, dass ich die Applikation Teams, welche ich beruflich nutze, nicht mehr auf meinem Rechner im Homeoffice betreiben wollte. Die Gründe dafür sind vielfältig und wurden im Artikel zum Thema Telemetriedaten bereits erläutert.

Zunächst habe ich mich informiert, welche Lösungen und Angebote es zurzeit in diesem Bereich gibt. In den Medien war in den letzten Monaten öfters die Rede von shells.com, welche fix fertige Linux Remote-Desktops anbieten. Aus moralischer Sicht war ich etwas vorbelastet, denn die Firma dahinter wird von der gleichen Person betrieben, die für das Ende von Freenode verantwortlich ist. Nichtsdestotrotz habe ich das Angebot in Anspruch genommen, zumal eine 7-Tage-Geld-Zurück-Garantie geboten wird.

Leider waren meine ersten Tests alles andere als erfolgreich. Die VM startete nicht und es konnte keine Verbindung zu meinem virtuellen Desktop aufgebaut werden, weder über das Webfrontend, noch über den recht spartanischen Client. Ich wollte bereits das Angebot kündigen, als ich mich doch noch entschlossen habe, den Support zu kontaktieren. Nach einigem hin-und-her kam heraus, dass die Betreiber Probleme mit VMs am Standort Amsterdam haben. Diesen hatte ich gewählt, da es der einzige europäische Standort im Angebot ist. Nach 3 Tagen gelang es mir dann, mich mit der VM zu verbinden. Leider reagierte diese so träge und der Bildaufbau zeigte den Desktop-Inhalt zunächst schwammig an, dass ich das Experiment aufgeben musste.

Bisher bekannt war mir ausserdem die Freie Lösung x2go. Als Basis für meine Experimente sollte ein kleiner vserver bei Netcup dienen. x2go lässt sich schnell einrichten und die Installation ist unter Debian GNU/Linux mithilfe des folgenden Befehls bereits erledigt:

sudo apt-get install x2goserver x2goserver-xsession

Die Verbindung liess sich dank des x2goclients ohne weiteres herstellen. Die Geschwindigkeit bei einer regulären Desktopnutzung ist ausreichend, Videos lassen sich allerdings darüber nicht abspielen.

Man könnte nun annehmen Teams wäre ein einfacher Chatclient. In Wahrheit ist die Applikation allerdings extrem ressourcenhungrig und liess sich im virtuellen Desktop nicht nutzen, auch wenn man die grafischen Spielereien und sonstigen SchickSchnack deaktiviert.

x2go basiert auf dem nx Protokoll, welches von dem Hersteller NoMachine entwickelt und unter einer Freien Lizenz bereitgestellt wird. Der grafische Client/Server ist dabei allerdings proprietär. Dennoch habe ich mich in meiner Not dazu entschieden NoMachine einen Test zu unterziehen. Die Anwendung steht für x86 und x86_64 Linux im rpm, deb oder als Binärarchiv zum Download zur Verfügung. Auf dem netcup Server habe ich openSUSE installiert. Da für die Nutzung als Desktop eine Benutzeroberfläche benötigt wird, habe ich Xfce nachinstalliert:

zypper in -t pattern xfce

Einen regulären Benutzeraccount konnte ich mithilfe von YaST in wenigen Schritten hinzufügen.

Daraufhin habe ich das angebotene rpm Paket von NoMachine auf meinem lokalen Computer heruntergeladen und mittels scp auf das Zielsystem übertragen. Dort konnte ich es mit folgendem Befehl installieren:

rpm -Uvh /pfad/zum/Paket

Für den Zugriff muss der TCP Port 4000 geöffnet sein. Da bei openSUSE firewalld zum Einsatz kommt, gelang mir dies wie folgt:

firewall-cmd --permanent --zone=public --add-port=4000/tcp;  firewall-cmd --reload

Das NoMachine-Paket enthält sowohl die Client- als auch die Serverkomponente. Daher musste ich das gleiche Paket auf meinem lokalen Computer installieren; dieses Mal allerdings aus dem Binärarchiv. Letzteres enthält ein README, welches unbedingt befolgt werden sollte.

Nach dem Aufruf von NoMachine aus dem Startmenü, konnte ich eine neue Verbindung hinzufügen:

Nach einem Klick auf Verbinden wird der Benutzername und das Passwort des Remote-Rechners erfragt. Dabei sollte dieser so wie zuvor eingerichtet angegeben werden. Alternativ lässt sich eine SSH-Key basierte Anmeldung nutzen.

Nach kurzer Zeit wird die Verbindung aufgebaut und ein Assistent führt den Nutzer durch die wichtigsten Funktionen. Dazu gehört ein Blättermenü welches sich ähnlich wie eine Buchseite präsentiert.

Über den hervorgehobenen Button lässt sich das Bild auf den Fensterinhalt skalieren. Bei meinen Tests funktionierte dies ohne Performance-Einbussen auch auf einem Display mit 3440x1440px Auflösung. Im Browser konnte ich störungsfrei Videos bis zu einer Auflösung von 480p betrachten.

Doch die eigentliche Intention bestand ja darin, Teams auszusperren. Dazu habe ich die Anwendung als Flatpak in meinem Remote-Desktop installiert, was bereits in gewisser Weise dafür sorgt, dass sich diese nicht ganz so frei im System bewegen darf.

In den ersten Test stellt sich allerdings heraus, dass die 2GB RAM und 1 vCore nicht ausreichend sind.

Nach einem Upgrade auf 8GB und 2 Cores, lässt sich nun auch ein Softwaremonster wie Teams im Remote-Desktop nutzen.

Die vorgestellte Software lässt sich für unterschiedlichste Einsatzzwecke nutzen, und steht auch für Raspberry Pi und ARMv7 sowie ARMv8 zur Verfügung. Letztendlich ist der selbstgebaute Remote-Desktop noch kostengünstiger als eine Fertiglösung und ich habe volle Kontrolle darüber.

Tags

Linux, Desktop, NoMachine, openSUSE, Remote-Desktop, Remote, NoMachin, Angebot

kamome
Geschrieben von kamome am 14. Dezember 2021 um 14:21

Hmm, bei „Linux Remote-Desktop“ hatte ich jetzt nicht an Teams gedacht ;) Wenn es Teams sein muss, kann man da halt nix machen.

Für vieles reicht ja auch Jitsi Meet (wenn keine Desktop-Fernsteuerung benötigt). Gerade mal geschaut, Jitsi ist bei Yunohost gar nicht dabei, dafür Galène – hat da jemand von Euch Erfahrung?

Bimbam
Geschrieben von Bimbam am 14. Dezember 2021 um 14:24

Hi,

hast du dir schon mal guacamole (https://guacamole.apache.org/) angeschaut? Ich habe mit xrdp und Guacamole ziemlich gute Ergebnisse erzielen koennen. Beim Heim-Router mit einem DynDNS-Eintrag und Port forwarding auf https wird Guacamole dann erreichbar. Unterstuetzt wird dann nicht nur grafisches Forwarding ueber den Browser, sondern eben auch SSH ueber den Browser.

Gruesse

Lioh
Geschrieben von Lioh am 14. Dezember 2021 um 14:50

Klingt auf jeden Fall spannend. Allerdings nutzt es im Hintergrund vnc oder rdp. Beides liefert nach meiner Erfahrung nicht die benötigte Performance. Ein guter Indikator ist, wenn du dir im Browser ruckelfrei Videos anschauen kannst.

2cents
Geschrieben von 2cents am 14. Dezember 2021 um 17:56

Wenn ich eine "isolierte" Maschine benötige, starte ich gerne VirtualBox und installiere dort das benötigte Betriebssystem und anschließend das Programm, welches laufen soll.

Auf diese Weise läuft Windows 7, 10 und auch 11 unter einem debian "buster" host problemlos. Erforderlich ist genügend RAM und natürlich ein Prozessor mit möglichst vielen CPUs/Threads.

Lioh
Geschrieben von Lioh am 14. Dezember 2021 um 18:01

Damit löst du nur einen Teil des Problems. Die Instanz befindet sich immer noch bei dir im Heimnetzwerk. Und selbst wenn du strikte Netzwerkisolation machst, geht es noch über deinen Router. Dazu müsstest du noch VPN nutzen, um deinen Standort zu verschleiern. Auch dies ist nur sicher, wenn du deinen eigenen VPN Endpoint betreibst.

So bin ich ausserdem flexibel und kann von überall darauf zugreifen.

2cents
Geschrieben von 2cents am 14. Dezember 2021 um 18:22

Um flexibel von "überall" auf meine Daten zugreifen zu können nutze ich einen privaten nextcloud Server. Der stellt zusätzlich ein Office Paket (Collabora) zur Verfügung, mit dem ich via Browser Word-, Excel-, Powerpoint-Dateien bearbeiten kann. Der nextcloud Client im PC synchronisiert den Datenbaum zwischen PC und nextcloud-Server. Die virtuellen PC nutze ich nur für Applikationen, welche isoliert laufen sollen z.B. für die Buchhaltung oder für Tests. Vorteil: Ich brauche keinen Dienstleister, sondern verwalte meine Daten und Programme selbst. Die Verschleierung von IP Adressen hat bei mir keine Prio.

Lioh
Geschrieben von Lioh am 14. Dezember 2021 um 18:28

Ist ein anderer Anwendungsfall. Für meine privaten Daten nutze ich es auch so.

Andreas G.
Geschrieben von Andreas G. am 14. Dezember 2021 um 18:09

Recht interessant finde ich auch den Lösungsansatz von LinuxServer IO. Sie nennen das ganze Webtop. Das sind Docker Container die ein vollständiges Deskopsystem enthalten und der Zugriff erfolgt über den Guacamole Webclient.

👓
Geschrieben von 👓 am 15. Dezember 2021 um 07:53

Warum nicht teams.microsoft.com nutzen?

Lioh
Geschrieben von Lioh am 15. Dezember 2021 um 08:35

Wie kommst du darauf, dass die WebApp weniger Telemetriedaten erfasst? Falls es dir um Performance ging, diese ist dort gleich schlecht.

👓
Geschrieben von 👓 am 15. Dezember 2021 um 12:41

Dachte halt, dass wenn es im Browser ausgeführt wird hat Teams weniger systemzugriff und somit weniger Telemetire hat.

Um welche Telemetrie geht es denn hier?

Allenfalls könnte es aber auch sein, dass es dann so einfacher wäre, die Webseite via VPN zu routen. Mittlerweile kann die Firefox Container technologie auch nur bestimmte container übers VPN leiten.

Könnte man dann vielleicht sogar selber machen und via uberspace.de routen?

👓
Geschrieben von 👓 am 15. Dezember 2021 um 12:46

ist das Mozilla VPN addon (verwendet ja wireguard) OSS? Dann könnte man den für einen eigenen Wireguard server nutzen.

Lioh
Geschrieben von Lioh am 15. Dezember 2021 um 12:57

Schaue dir bitte den verlinkten Artikel zu Telemetriedaten an. VPN ist wie erwähnt eine Möglichkeit, solange du den Server selbst betreibst.

👓
Geschrieben von 👓 am 15. Dezember 2021 um 17:38

Den Artikel hab ich gelesen aber vermutlich nicht so verstanden wie du es beabsichtigst hast.

Einen Teil dieser Daten hat man ja grundsätzlich immer, da sie die nutzung betrift. VPN kann nur die IP verschleiern und die Zuordnung zu einer Person erschweren. Wärend eine lokale installation theoretisch auf den gesamten PC zugreifen kann, gilt das nicht für den Webclient.

Mein Arbeitgeber hat mich z.B. mit Vor- und Nachnamen bei M$ registriert. Somit ist eine Zuordnung hier eh nicht schwierig.

DerEremit
Geschrieben von DerEremit am 15. Dezember 2021 um 08:59

Beruflich nutzte ich den Rechner und die Software die mir gestellt wird. Da mag ich Teams vielleicht nicht mögen, aber das ist der Standard. Als Anwender kann ich schon gar nicht irgendwelche andere Lösungen nutzen. Wenn ich frei entscheiden kann sieht die Sache schon wieder anders. Aber wenn ich mit verschieden zusammenarbeiten mußt du dich auch wieder auf eine Lösung einigen. Aber schon zu lesen das es außerhalb Teams auch was gibt.

Lioh
Geschrieben von Lioh am 15. Dezember 2021 um 09:16

Einigen kann man sich nur, wenn alle Beteiligten die Hintergründe genau kennen. Auch im Unternehmensbereich gibt es genügend Lösungen ohne unerwünschte Datenerfassung. Teams, Slack und Co. sind halt einfach zugänglich und man vertraut den grossen Riesen blindlings.

Max
Geschrieben von Max am 15. Dezember 2021 um 11:13

Hatte auch lange x2go im Einsatz, meistens, um nur auf eine CentOS VM im eigenen Heimnetzwerk grafisch zuzugreifen. Leider gab es immer wieder Probleme, Abbrüche und kürzlich einen fiesen Bug mit einem Ryzen-Prozessor und dessen Vega-Grafikeinheit.

Bin seitdem bei xpra angekommen. Der Vorteil: stateless, variabel können Anwendungen oder der ganze Desktop ge"streamt" werden, und ich kann frei über das Transportprotokoll entscheiden (also auch etwa unverschlüsselt im Heimnetzwerk). Bisher läuft es recht gut zwischen meiner CentOS-VM und meinem Arch-Laptop: https://wiki.archlinux.org/title/Xpra

Lioh
Geschrieben von Lioh am 15. Dezember 2021 um 11:19

Klingt spannend, danke für den Hinweis, Max.

Sjoerd
Geschrieben von Sjoerd am 19. Dezember 2021 um 00:04

Guten Abend,

ich benutze immer gerne DW Service als alternative zu Teamviewer. Ich bin da sehr zufrieden mit. Man kann auf der Desktop zugriff bekommen, man kann da aber auch direkt zugriff auf ein Shell und Bestanden, Ordner bekommen.