Remote Desktop: Gnome-Remote-Desktop ersetzen

Der Ursprung dieser Artikelserie war der Versuch, per Remote-Desktop auf mein TerraPad zuzugreifen, so daß ich in die laufende Desktopsession eingreifen kann. Da es sich um ein Touchgerät handelt läuft der Gnome Desktop und der bietet dafür genau die richtige Funktion, direkt integriert, per Einstellungen aktivierbar, super komfortabel aber leider völlig disfunktional und somit komplett unbrauchbar 🙁

Remote Desktop: Gnome-Remote-Desktop ersetzen

Falls Ihr den auch ausprobiert habt und es nicht ging, gibt es dafür zwei mögliche Gründe: Entweder Ihr habt eine Auto-Login-Desktopsession, da es da keine Logindaten gibt, kann man die im Remotezugriff nicht abfragen laut Fedora Gnome Maintainer, oder Ihr bekommt trotz richtiger Logindaten keine Authentifizierung hin, dann habt Ihr das gleiche Problem wie ich.

Netter Versuch Gnome, aber…

Das geht alles viel besser als mit Eurer Bastellösung die irgendeine FreeRDP Liblösung benutzt, die leider nicht richtig funktioniert. Ironischerweise kann der Shadow-CLI Server von FreeRDP die ganze Sache sofort richtig, man muß ihn halt nur starten 🙂 Dabei löst er nämlich gleich beide Probleme, denn er macht den Auth gegen die Passwd und nicht in irgendeiner komischen Gnomeenklave.

Damit ist es dann auch egal, ob man einen Autologin hatte oder nicht. Als Sicherheitsmaßnahme kann man nur als der laufende User einloggen, also der, dem der Desktop gehört. Alles andere wäre auch unschön unsicher.

Und so geht es

wir brauchen:

sudo dnf install freerdp-server

und dann bauen wir uns einen kleinen Systemd.Service und können das starten. Dazu legen die Datei an ~/.config/systemd/user/shadow-remote-desktop.service :

[Unit]
Description=Shadow RDP Service
DefaultDependencies=no

[Service]
ExecStart=/usr/bin/freerdp-shadow-cli +auth
Restart=always
WorkingDirectory=%h
Environment=DISPLAY=:0
Type=simple
TimeoutStartSec=10

[Install]
WantedBy=default.target

dann müssen wir Gnome aufhalten, so Ihr denn Gnome einsetzt. Bei Cinnamon oder anderen Desktops ohne integrierte Lösung brauch Ihr das natürlich nicht machen 😉

systemctl –user stop gnome-remote-desktop.service
systemctl –user disable gnome-remote-desktop.service
systemctl –user mask gnome-remote-desktop.service

jetzt noch starten:

systemctl –user start shadow-remote-desktop.service

und das war es. Fertig. Keine dummen Fehlermeldungen mehr, läuft direkt mit Remmina und XFreeRDP als Klienten, einfach perfekt.

Ihr könnt den Dienst übrigens auch allen Usern auf dem System einrichten, dann braucht Ihr im Service Abschnitt noch den Eintrag: „User=%i“ und die Servicedatei muß systemweit installiert sein, z.B. hier /usr/lib/systemd/user/ .

Kleine Erklärung zur Datei und was Ihr ggf. ändern müßt

+auth“ damit wird die Authentifizierung erzwungen. Ohne die Anweisung könnte jeder in den Desktop rein, daß wollt Ihr nicht mal zu hause im LAN haben.

DISPLAY=:0“ ist das Defaultdisplay Eures Desktops. BEI MIR ist das aber :1 , keine Ahnung wieso. Wenn es also bei Euch nicht auf Anhieb startet, dann schaut doch mal ins Terminal rein, ob Eure DISPLAY Variable auch wirklich :0 ist. Einfach „echo $DISPLAY“ eingehen, dann wisst Ihr es.

Falls Ihr Wayland benutzt

Kann ich Euch leider nicht garantieren, daß es geht. Das müßt Ihr ausprobieren.

Einführung:

Remote Desktop: Einführung

Teil 1:

Remote Desktop: eigene Desktopsession mit XRDP

Remote Desktop: eigene Desktopsession mit XRDP

Im ersten Teil der Remote-Desktop Serie geht es um XRDP. Damit kann ein entfernter Benutzer eine eigenständige Desktopsession zum Server aufbauen. Andere Benutzer des gleichen Servers können parallel dazu eine eigene Verbindung aufbauen, ohne das sich die Benutzer in die Quere kommen. Allerdings darf ein User nur einmal eingeloggt sein.

Remote Desktop: eigene Desktopsession mit XRDP

Da es sich bei der Lösung um eine eigenständige Desktopumgebung abseits vom Monitor handelt, gibt es hier keine Probleme mit Waylanddesktops. XRDP bietet eine Xorg Verbindung ohne GPU Support an, was die Auswahl der eigentlichen Desktopumgebung einschränkt.

Die Installation

Debian & Ubuntu:

sudo apt-get update && sudo apt-get upgrade && sudo apt install xrdp

Fedora:

sudo dnf install xrdp-selinux xrdp

Die Desktopumgebung

Jetzt müssen wir uns für eine Desktopumgebung entscheiden, weil es bei RDP leider keine Vorauswahl seitens des Clienten gibt. Es bieten sich GPU unabhängige Desktops wie GNOME oder XFCE4 an. Zum Glück ist das total einfach:

echo „gnome“ > ~/.xsession

oder

echo „xfce4-session“ > ~/.xsession

Dies muß jeder Benutzer selbst machen oder durch den Superuseraccount regel lassen. Was nicht funktioniert ist Cinnamon, soweit ich das bisher erlebt habe.

Die Firewall öffnen

Da sich die eingesetzten Firewalls pro Distribution stark unterscheiden, hier einige Vorschläge:

Debian & Ubuntu: sudo ufw allow 3389/tcp
Fedora: sudo firewall-cmd –permanent –add-port=3389/tcp
IP-Tables: sudo iptables -A INPUT -j ACCEPT -m tcp -p tcp –dport 3389

Von Fedora abgesehen, müßtet Ihr die Regeln permanent hinzufügen z.B. also in /etc/sysconfig/iptables eintragen.

XRDP Starten

In einer Idealen Welt, würde man nun „systemctl enable –now xrdp“ ausführen und es geht. Da leben wir aber nicht 🙂

In /etc/xrdp/sesman.ini müßtet Ihr sicherstellen, daß folgendes so drinsteht:

[Xorg]
; Specify the path of non-suid Xorg executable. It might differ depending
; on your distribution and version. Find out the appropriate path for your
; environment. The typical path is known as follows:
;
; Fedora 26 or later : param=/usr/libexec/Xorg
; Debian 9 or later : param=/usr/lib/xorg/Xorg
; Ubuntu 16.04 or later : param=/usr/lib/xorg/Xorg
; Arch Linux : param=/usr/lib/Xorg
; CentOS 7 : param=/usr/bin/Xorg or param=Xorg
; CentOS 8 : param=/usr/libexec/Xorg
; FreeBSD (from 2022Q4) : param=/usr/local/libexec/Xorg
;
param=/usr/libexec/Xorg
; Leave the rest parameters as-is unless you understand what will happen.
param=-config
param=xrdp/xorg.conf
param=-noreset
param=-nolisten
param=tcp
param=-logfile
param=.xorgxrdp.%s.log

[Xvnc]
param=Xvnc
param=-bs
param=-nolisten
param=tcp
param=-localhost
param=-dpi
param=96

Damit erklärt sich auch, wieso es kein Waylandproblem mit XRDP gibt, es wird ja nicht benutzt 😉

Jetzt können wir das starten: systemctl enable –now xrdp

Mein Tip

… Ja, ich bin alt, ich schreibe Tip noch einem p :þ… können wir dann? Mein Tip für Euch: enabled es nicht per se.

Ihr könnt den Server auf 127.0.0.1 binden lassen, dann kommt Ihr nur per SSH-Tunnel oder lokal drauf. Letzteres wäre für ein „REMOTE“ Desktoptool ja eigentlich völlig unsinnig, aber es gibt Spezialfälle:

Wenn man z.B. Desktopprogramme für Spezialuser, wie einen spezialisierten Online-Bankingaccount, benutzen möchte, dann kann man sich per RDP einfach einloggen ohne den Benutzer wechseln zu müssen. Das kann z.b. auch nützlich sein, wenn man eine kleine Linux Internetshow betreibt und mit einem Nicht-Admin-User mal was zeigen will oder auch, um als Root mit einem Desktoptool etwas zu machen. Möglichkeiten dies zu verwenden gibt es viele.

Im Normalfall sollte man sich von außen auch nicht direkt per RDP einloggen können, sondern immer über einen sicheren SSH Tunnel gehen, denn RDP authentifiziert gegen PAM und das benutzt im Vergleich zu OpenSSH-Schlüsseln, schwache Passwörter als Schutz. Da ist ein OpenSSH-Schlüssel jederzeit vorzuziehen.

Vermeiden lässt sich eine direkte Erreichbarkeit nicht, wenn man im Netz einen Server betreibt, der für Benutzer per RDP erreichbar sein muß. XRDP kann hier insofern für etwas Sicherheit sorgen, wenn Rootzugriffe verboten sind. Aber auch im Netz kann ich allen Beteiligten nur dazu raten, z.b. auf VPNs zu setzen oder einen SSH-Tunnel zu nutzen. Bei den ganzen Kriminellen da draußen, muß man wirklich jede Schutzschicht aktivieren, die geht.

Remote Desktop: Einführung

Von Remote Desktop Lösungen für Linux habt Ihr schon gehört: man startet ein Programm auf dem PC den man kontrollieren will und eins auf dem PC mit dem man auf den ersten PC drauf möchte, um diesen aus der Ferne zu steuern. Da gibt es jetzt schon min. zwei verschiedene Ansätze wie ein Benutzer das nutzen möchte.

Remote Desktop: Einführung

In dieser Artikelserie geht es um verschiedene Arten einen Remote-Desktop-Service mit VNC und RDP zu nutzen.

Zunächst müssen wir mal unterscheiden, wie ein Benutzer den Remote-Desktop nutzen will: als Spiegel der aktuelle eingeloggten Desktopsession oder als eigenständige Desktopsession.

Der Spiegel meint, daß ich mich die laufende Desktopsitzung einklinken kann. Das machen VNC, Teamviewer, Anydesk, RustDesk und Windows RDP so. Wir können aber auch eine eigene Desktopsession bekommen, die nichts mit dem zu tun hat, was auf dem Monitor zusehen ist. Das wird z.b. von XenDesktop und XRDP gemacht, wobei XenDesktop die lokale GPU benutzt um von den Grafikfähigkeiten des Clientens zu profitieren, wenn das geht. Da sich das aber an professionelle Benutzer wendet, werde ich auf XenDesktop nicht näher eingehen.

Da es jetzt nicht nur das eine Programm gibt, mit dem man das gewünscht erreichen kann, könnt Ihr Euch vorstellen, daß ich hier nicht ins Detail jeder dieser Lösungen gehen kann.Eine Sache können wir aber vorher schon besprechen.

Xorg gegen Wayland

Die meisten Remote Lösungen funktionieren nur mit Xorg vernünftig. Bei einer Waylandsession wird sehr oft nur ein schwarzer Bildschirm zu sehen sein. Das liegt daran, daß Wayland das Capturen von Bildinhalten als Sicherheitslücke einstuft und es daher nicht erlaubt. Das hindert aber Anwendungen nicht daran, auch mit Wayland zu funktionieren z.B. RustDesk kann das schon. Da geht es eher darum, daß nicht eine zufällig ausgeführte App den Bildschirm mitschneidet, sondern nur Apps, die das auch „dürfen“ z.B. FireFox,Chromium usw.

Hinweis: Ich werde nur dann auf Wayland hinweisen, wenn ich weiß, daß es geht. Ansonsten nehmt einfach an, daß es nur mit Xorg funktioniert. Ferner kommt es natürlich auch darauf an, welche Version von Wayland Eure Distro gerade bereitstellt. Das Ergebnis kann sich also jederzeit durch Updates ändern.

Im ersten Teil der Serie, schauen wir uns „XRDP“ an. „XRDP“ ist die anspruchsvollste Lösung, da erstmal einiges an Setup nötig ist um ein Ergebnis zu bekommen. Der Teil kommt dann in einigen Tagen zu Euch.

Der Universalclient: Remmina

In Vorbereitung des Artikels könnt Ihr Euch schon einmal Remmina als RDP/VNC Clienten installieren. Das ist ein Superprogramm, wenn man sehr viele Remiteverbindungen managen muß. Es kann auch SSL Tunnel benutzen um durch die Firewalls zu gelangen und hat myriaden von Einstellungen für Euch. Besser geht es wohl unter Linux nicht 🙂

 

Tip: Wer von Euch einen Vorabblick auf diese Serie haben möchte, kommt am besten am 4.4. zu Linux am Dienstag