Von Remotearbeitsplatzlösungen hat bestimmt sicher jeder schon mal etwas gehört. Die Technik dafür ist in der Regel auf VNC aufgebaut und trägt viele Namen: AnyDesk, Teamviewer, RDP oder auch direkt VNC.

RemoteDesktopProtocol

Wenn es bei VNC eher um die rudimentären Funktionen der Bildübertragung geht, so daß auf zwei Monitoren das Gleiche zu sehen ist, kann man sich mit RDP, Teamviewer und Anydesk auch als ein Benutzer auf einem anderen PC anmelden.

Unter Windows nutzt man dazu das RemoteDesktopProtocol ( RDP ) und genau das kann man auch mit Linux nutzen. RDP ist in der Lage die Verbindung mit TLS zu verschlüsseln, was einen großen Vorteil hat, wenn man das quer durchs Internet benutzt. Es ist allerdings eine schlechte Idee, den RDP Port frei ins Netz zu stellen. Die Windows RDP Serverversion ist in der Vergangenheit mehrfach erfolgreich Ziel von Angreifern geworden, daher empfehle ich für Linux ohnehin, daß man den Port über SSH tunnelt.

Das geht ganz leicht:

ssh -C -L 127.0.0.1:3389:RDPSERVERIP:3389 username@sshgateway

Der Linux Client – XFreeRDP

Die Verbindung zu einem RDP Server aufzubauen ist ganz leicht, wenn man XFreeRDP benutzt. Analog zu dem SSH Tunnel oben, hier die dafür nötige Syntax:

xfreerdp /v:127.0.0.1 /u:username /p:Passwort /size:1920×1020

Die erste Frage wird jetzt wohl sein, wieso 1920×1020. Das ist leicht, weil das als Fensterversion genau in einen FullHD Monitor mit Cinnamon paßt 😉 Wer aber die volle Erfahrung haben will, der kann auch einen Parameter für Fullscreen angeben:

xfreerdp /v:127.0.0.1 /u:username /p:Passwort /size:1920×1080 /f

Wer darüber Videos ansehen und/oder Skypen will, der muß zwei Dinge haben: einen Server der das anbietet und folgende Parameter:

xfreerdp /v:127.0.0.1 /u:username /p:Passwort /size:1920×1080 /f  /microphone:sys:alsa /sound:sys:alsa /compression-level:2

Aber erwartet da jetzt nicht zu viel. Bei Tests gab es da leichte Bandbreitenprobleme über DSL.

Die nächste Frage dürfte sein, wieso man das in die Konsole hacken soll. Sagen wir es mal so, die meisten getesteten DesktopUIs waren nicht wirklich brauchbar. Ich empfehle Euch ohnehin für eine zügige Verbindung ein Desktopfile pro Verbindung:

[Desktop Entry]
Version=1.0
Name=Arbeitsplatz2
GenericName=RemoteTool
Comment=FreeRPD Client
Exec=xfreerdp /v:127.0.0.1 /u:username /p:Passwort /size:1920×1080 /f  /microphone:sys:alsa /sound:sys:alsa /compression-level:2
Icon=/home/username/.local/share/icons/freerdp.svg
Terminal=false
Type=Application
StartupNotify=false
Categories=Network;
Keywords=Arbeitsplatz;rdp;freerdp;internet;
X-Desktop-File-Install-Version=0.21
Name[de_DE]=Arbeitsplatz2

Wenn es noch ein automatischer Tunnel sein soll, müßt Ihr ein Shellscript schreiben und das aufrufen. Ab hier könnt Ihr auf einen beliebigen Windows oder Linux RDP Server zugreifen.

XRDP – Der RDP Server

Kommen wir zum schwierigen Teil der Aktion: Der eigene Server.

Eigentlich es ziemlich einfach, nur die Details sind ein Problem. XRDP ist glücklicherweise bei Fedora dabei. Installiert bekommt man es also einfach mit :

sudo dnf install xrdp

zum Starten ist auch nicht viel nötig:

sudo systemctl start xrdp

Aber Ton versucht man vergebens zu aktivieren, denn die nötigen Pulseaudiomodule liegen dem Programm bei Fedora seit einiger Zeit nicht mehr bei. Ich habe versucht die für Fedora 30 zu kompilieren, keine Chance.

Bei Fedora 31 sieht die Sache ein klein bisschen anders aus. Hier ist bereits PulseAudio 13 im Einsatz, wo Fedora 30 noch 12 benutzt. Der F30 Build von PulseAudio 13 wurde aus einem unerklärlichen Grund in die Mülltonne verschoben, ich tippe mal darauf, daß nicht alle anderen Pakete mitziehen wollten oder konnten.

Da es auch Für PulseAudio 13 keine Fedora Module für XRDP gibt, müssen wir hier kreativ werden 🙂 Wir leihen es uns bei einer anderen Distribution aus:

wget http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/x86_64/RPMS.classic/pulseaudio-module-xrdp-0.4-alt1.x86_64.rpm
rpm -i ./pulseaudio-module-xrdp-0.4-alt1.x86_64.rpm

Jetzt kann Euer Fedora 31 auch den Sound liefern.

Die richtige Desktopwahl

So, Ihr habt Euren Server laufen und jetzt verbindet Ihr Euch mit XFreeRDP dahin. Ihr werdet jetzt abhängig von dem Desktopspin den Ihr installiert habt, entweder einen Erfolg vermelden können (GNOME) oder einen schwarzen Bildschirm sehen und nicht mehr ausloggen können (Cinnamon). Die anderen Desktops habe ich nicht ausprobiert, aber Gerüchten zufolge, sollen die durchweg „gehen“.

Um sicher zugehen, daß Ihr eine Umgebung bekommt, die auch läuft, legt Ihr im HOME vom Benutzer den Ihr einloggen wollt eine Datei namens .Xclients an, die „gnome-session“ als Inhalt und u+x als Dateiattribute hat:

echo „gnome-session“ > ~/.Xclients
chmod u+x ~/.Xclients

Voraussetzung ist, daß Gnome auch installiert ist. Falls das nicht der Fall ist, könnte das helfen:

dnf install gnome-desktop3

Da sollte der ganze Rattenschwanz an Abhängigkeiten kommen. Alternativ schreibt Ihr Euren Desktop in die Datei rein. Eine Liste mit passenden Anweisungen finden Ihr im Netz.

Wieso empfehle ich dann Gnome?

Weil das nicht über die fehlende Hardwarebeschleunigung meckert, wie andere Desktops das tun ( und dann nicht richtig funktionieren ). Außerdem ist die schlichte Deko des Desktops sehr hilfreich um Bandbreite einzusparen, was die Sache reaktiver macht. Im eigenen LAN ist das natürlich komplett egal.

Ich rate bei DSL Verbindungen dazu die Animationen des Desktops zu deaktivieren. Man kann das auch im XFreeRDP als Schalter mitteilen, aber direkt im Gnome ist es vermutlich „nachvollziehbarer“ für den Desktop.

Jetzt könnt Ihr loslegen.

Ein kleiner Sicherheitshinweis noch: Paßt bitte auf, daß Ihr nicht aus Versehen den Server runterfahrt, statt die Usersession zu beenden, daß kann sehr schmerzhaft werden 🙂 Gerade bei Gnome liegen die Funktionen dicht beisammen und aus Gewohnheit verklickt man sich da schnell. Also Obacht!

Android

Oh ja, es gibt auch eine Android XFreeRDP Clienten Version und je nach Eurem Android, kann die ggf. nur gebrochene Krypto. Wenn das der Fall ist, laßt es lieber, weil Eurer Tablet dann auch leistungsmäßig nicht ausreicht um das brauchbar zu benutzen. Falls Ihr diese lieb gemeinte Warnung ignorieren wollt, xrdp.ini ist Eure Anlaufstelle:

/etc/xrdp/xrdp.ini :

ssl_protocols=TLSv1, TLSv1.1, TLSv1.2, TLSv1.3v; set TLS cipher suites

Es dürfte klar sein, daß das im != Privaten Umfeld nicht eingesetzt werden darf, da Artikel 32 DSGVO das verbietet.

Dann wünsche ich jetzt allen Karnevalsfreunden unter Euch, die morgen zum Shoduvel nach Braunschweig kommen: Alles Gute in der Regenschlacht und verabschiede mich für heute 🙂