Fedora: Ubuntu knockt Fedora aus dem Secure-Boot

Die Schlagzeile hat was, oder?  😀

Fedora: Ubuntu knockt Fedora aus dem Secure-Boot

Der Releasetermin für Fedora 33 wackelt, da kurzfristig einer neuer Blocker dazu bekommen ist. Ubuntu hat offensichtlich etwas voreilig eine aktuelle Revocationliste für Bootloader ins EFI-Bios verteilt und damit Fedora 33 Beta unbrauchbar gemacht. Um dem Bug zu begegnen, muß man natürlich erst einmal Ubuntu installiert oder laufen gehabt haben und dann Fedora booten wollen.

5. shim https://bugzilla.redhat.com/show_bug.cgi?id=1883609 NEW
Secure Boot fails to boot F33 Beta image

It appears that Ubuntu has pushed a Secure Boot revocation list early, so people who have previously installed Ubtunu will not be able to boot Fedora. This is accepted as a FESCo blocker.

Nachlesen kann man das auf Bugzilla.

Nicht ganz unüblich dürfte das bei Menschen sein, die sich gerade durch diverse Livedisks durchtesten, auf der Suche nach Ihrem zukünftigen Lieblingsbetriebssystems.

Da es auch mein Problem mit dem Bootvorgang auf dem Tablet betrifft, habe ich da natürlich Hoffnungen. Was mir gerade so einfällt: Wo ist eigentlich der Sinn von Secure-Boot, wenn man das im Bios einfach abschalten kann?

In anderen Fedora News

DoT oder DNS-over-TLS kommt wohl doch erst mit Fedora 34. Nicht aufgegriffen wurden auch die anhaltenden pcscd & RDP Probleme mit Gnome, oder der Umstand, daß man mit Fedora keine Screencasts in Videokonferenzen machen kann 🙁  Kommt alles ein bisschen spät für die Deadline, schon klar, war aber mit Sicherheit schon so, als F33 intern das erste mal durchkompilierte.

Von der Geary Front, vorgestellt im letzten BS-LUG Meeting, gibt es auch eine neue Entwicklung: Ein bereits vor Monaten eingereichter Bugreport über einen Formatierungsfehler bei in Antworten erzeugten Daten wie „ER/SIE schrieb am …. um .. das folgende…“ sind allesamt falsch lokalisiert. Als Zeitzone kommt UTC+0 und als Format „english“ zum Einsatz, was bei einer rein Deutschen Konversation per Email mit dem Satz endete: „Das hast Du doch nie vor 2 Stunden geschrieben!“ 🙂 Da ist jetzt neue Bewegung rein gekommen, da der Hauptmaintainer langsam versteht, daß es sich nicht um ein Übersetzungsproblem handelt, sondern um ein Lokalisierungsproblem. Solche Jobs übernehmen Betriebssystembibliotheken normalerweise für einen, aber man muß die natürlich richtig füttern 😉

 

Windows Netzwerke topologisieren – Linuxstyle

Wenn wir in einem Firmennetz den PCs per DHCP IPs zuweisen, dann kennt nur der DHCP Server die aktuelle Zuordnung aller von Ihm verwalteten Addresseranges und die kann sich dynamisch ändern. Also brauchen wir eine Methode wie wir eine aktuelle Übersicht bekommen.

Windows Netzwerke topologisieren – Linuxstyle

Oh ja.. endlich mal was ohne Corona schreiben, wie ich das vermisst habe 😀

Wir brauchen:

Einen Linux PC
NMAP Scanner
GREP, SED, AWK
nmblookup

nmblookup bekommt man für Fedora im Paket „samba-client“ und nmap natürlich im Paket „nmap„, wer hätte es gedacht 😉

Wir nehmen jetzt mal an, daß wir nur ein Netz haben: 192.168.1.0/24 und, daß Windows RDP offen hat, damit man da auch Remote drauf kann. RDP hat den Port 3389. Das hat den Vorteil, daß wir nur die PCs mit Port 3389 finden müssen:

nmap -n -sS -p 3389 192.168.1.0/24

das sieht dann so aus:

Nmap scan report for 192.168.1.24
Host is up (0.00040s latency).
PORT STATE SERVICE
3389/tcp open ms-wbt-server
MAC Address: A2:54:20:26:3D:7F (Unkown)

Aus der Ausgabe brauchen wir nur die mit offenen RDP Ports, also filtern wir nach „open“, es sei denn, Ihr habt eine Installation bei der das eingedeutscht wurde. Da müßt Ihr selbst ran 😉

nmap -n -sS -p 3389 192.168.1.0/24 | grep -B 3 open

Jetzt habe ich dem ersten grep nach „open“ gesagt, es soll auch die 3 Zeilen vor dem Treffer ausgeben. Dies ist wichtig, weil da die IP drin steht. Als nächstes  filter wir auf die IP Zeile:

nmap -n -sS -p 3389 192.168.1.0/24 | grep -B 3 open | grep „scan report“

und werfen alles außer der IP weg:

nmap -n -sS -p 3389 192.168.1.0/24 | grep -B 3 open | grep „scan report“ | sed -e „s/^.*for //g“

Diese Ausgabe müssen wir um den eigentlichen Befehl so erweitern, daß wir die Informationen vom PC bekommen und das geht mit „nmblookup -A <ip>“:

nmap -n -sS -p 3389 192.168.1.0/24 | grep -B 3 open | grep „scan report“ | sed -e „s/^.*for //g“ | awk ‚{print „nmblookup -A „$1;}’|bash

..Das Ergebnis der Mühe wert..

Das Ergebnis sieht dann so aus:

Looking up status of 192.168.1.2
W10-HEIST <00> – B <ACTIVE>
MOVIE <00> – <GROUP> B <ACTIVE>
W10-HEIST <20> – B <ACTIVE>

MAC Address = 52-54-00-48-D1-17

Looking up status of 192.168.1.87
No reply from 192.168.1.9

Looking up status of 192.168.1.188
AUTOCAD02 <00> – B <ACTIVE>
AUTOCAD02 <20> – B <ACTIVE>
INGENIEURE <00> – <GROUP> B <ACTIVE>

MAC Address = 90-1B-0E-53-5E-07

Jetzt habe ich die IP, den Namen, die Arbeitsgruppe und die Macaddresse von jedem Windows PC mit RDP. Jederzeit aktualisierbar. Live 🙂

Das war Teil 1 der Aufgabe, denn für den Fall, für den ich das so gemacht habe, war das das gewünschte Ergebnis. Wir können aber noch mehr machen. Wir haben die IP und die MAC eines PCs.

Was wäre, wenn man damit die Topologie ermitteln könnte?

Vorweg: Es gibt andere Methoden, z.b. snmp Abfragen am Switch und Router, die sind etabliert und funktionieren. Allerdings ist son snmpwalk abhängig davon was die einzelnen Geräte anbieten, da muß man einiges an Zeit reinstecken, wenn man das selbst bauen will.

Zeit ist aber das richtige Stichwort 🙂 Pakete laufen im Netz abhängig von der Strecke zwischen den PCs unterschiedlich lange. Wie bekomme ich das raus? Richtig mit Ping:

# ping -c 20 192.168.1.25
PING 192.168.1.25 (192.168.1.25) 56(84) bytes of data.
64 bytes from 192.168.1.25: icmp_seq=1 ttl=64 time=0.215 ms
64 bytes from 192.168.1.25: icmp_seq=2 ttl=64 time=0.195 ms
64 bytes from 192.168.1.25: icmp_seq=3 ttl=64 time=0.209 ms
64 bytes from 192.168.1.25: icmp_seq=4 ttl=64 time=0.204 ms
64 bytes from 192.168.1.25: icmp_seq=5 ttl=64 time=0.166 ms
64 bytes from 192.168.1.25: icmp_seq=6 ttl=64 time=0.204 ms
64 bytes from 192.168.1.25: icmp_seq=7 ttl=64 time=0.253 ms
64 bytes from 192.168.1.25: icmp_seq=8 ttl=64 time=0.158 ms
64 bytes from 192.168.1.25: icmp_seq=9 ttl=64 time=0.200 ms
64 bytes from 192.168.1.25: icmp_seq=10 ttl=64 time=0.184 ms
64 bytes from 192.168.1.25: icmp_seq=11 ttl=64 time=0.199 ms
64 bytes from 192.168.1.25: icmp_seq=12 ttl=64 time=0.249 ms
64 bytes from 192.168.1.25: icmp_seq=13 ttl=64 time=0.264 ms
64 bytes from 192.168.1.25: icmp_seq=14 ttl=64 time=0.225 ms
64 bytes from 192.168.1.25: icmp_seq=15 ttl=64 time=0.297 ms
64 bytes from 192.168.1.25: icmp_seq=16 ttl=64 time=0.255 ms
64 bytes from 192.168.1.25: icmp_seq=17 ttl=64 time=0.290 ms
64 bytes from 192.168.1.25: icmp_seq=18 ttl=64 time=0.328 ms
64 bytes from 192.168.1.25: icmp_seq=19 ttl=64 time=0.212 ms
64 bytes from 192.168.1.25: icmp_seq=20 ttl=64 time=0.229 ms

— 192.168.1.25 ping statistics —
20 packets transmitted, 20 received, 0% packet loss, time 19360ms
rtt min/avg/max/mdev = 0.158/0.226/0.328/0.047 ms

Wenn wir also statt nmblookup ping einbauen, können wir jeden dieser Pcs messen:

nmap -n -sS -p 3389 192.168.1.0/24 | grep -B 3 open | grep „scan report“ | sed -e „s/^.*for //g“ | awk ‚{print „ping -c 20 „$1;}’|bash | grep -E „(statistics|rtt)“ | sed -e „s/— //g“ -e „s/ ping.*$//g“ -e „s/rtt //“ -e „s/\/max\/mdev = /:/g“ -e „s/\//:/g“ | awk -F „:“ ‚{print $1″=“$3″ „$2″=“$4;}‘ | sed -e „s/= =//“

da kommt sowas bei raus:

192.168.1.21
min=0.624 avg=0.851

Wert ermittelt, jetzt muß er bewertet werden..

Jetzt kann man sich überlegen, inwieweit Ihr dem MIN Wert traut, denn der ist stark vom Netzwerkverkehr abhängig, wo hingegen avg so etwas bedingt ausbügelt. Man sollte die Messung zu verschiedenen Zeiten wiederholen und dann die Ergebnisse zusammenrechnen. Für diese Prinzipdarstellung reichts auch erstmal so 😉

Wir können aus den MIN-Daten folgendes ermitteln: Alle PCs mit der gleichen Antwortzeit sind gleich weit weg, oder der antwortende PC ist ne alte Krücke 😉 Gleich weit weg bedeutet in Wirklichkeit: diese PCs könnten in einem Zimmer stehen, aber die könnten auch in verschiedenen Zimmern stehen, die über gleich lange Kabel angeschlossen sind. Das ist der Knackpunkt.

Üblich ist, daß im Serverraum ein Patchfeld ist, von dem die Kabel in die einzelnen Regionen des Gebäudes abzweigen. Der Vorteil dabei ist der Datendurchsatz und das man PortSense benutzen kann, der Nachteil, daß viel mehr Kabel gezogen werden, als nötig wären.

Datenaustausch in einem Netzwerk

Jetzt überlegen wir mal, welchen Test wir noch machen können… hmm.. IP.. Name… MACAdressse… MACAdresse… hey, wir haben eine MACAdresse vom PC direkt.. vergleichen wir die doch mal mit dem was im Arptable steht 😀

Erstmal erklären: Der Datenaustausch findet in einem Netz nicht zwischen IPs statt, sondern zwischen MAC Adressen. Das sind die Adressen der Netzwerkkarten die da zum Einsatz kommen. Haben wir eine direkte Verbindung zu dem Austauschpartner, hat die IP im Arpcache die gleiche Macadresse wie die per nmblookup mitgeteilt wurde. Im ARP Cache, erreichbar über den Befehl apr, bekommen wir die für die Kommunikation zur IP genutzte Mac auf dieser Seite der Verbindung:

Looking up status of 192.168.1.51

MAC Address = B1-6E-FF-D3-42-B4

# arp |grep 1.51
192.168.1.51 ether b1:6e:ff:d3:42:b4 C eth0

Ist da aber ein anderes Gerät dazwischen ( z.B. Router ), dann hat das Arpcache bei uns eine andere MAC als das Gerät uns per nmblookup mitgeteilt hat. Hinweis: Switche geben Ihre eigenen MAcs nicht preis, die sind transparent was das betrifft. Ein Router könnte jetzt also ein Netzumsetzer, eine Bridge, Tunnel oder ähnliches sein:

Looking up status of 192.168.1.51

MAC Address = B1-6E-FF-D3-42-B4

# arp |grep 1.51
192.168.1.51 ether  A0:43:3d:3A:13:45 C eth0

Wenn man jetzt also mehrere IPs mit der gleichen MAC hat, weiß man, daß die zusammen auf entweder einer Hardware laufen, dann wären die Pingzeiten alle gleich, oder die laufen alle durch einen Router/Tunnel und haben unterschiedliche Laufzeiten, dann stehen die hinter dem Router an verschiedenen Stellen.

Andere Ergebiskombinationen

Jetzt gibts noch die Kombi, daß die Laufzeit für einige IP gleich ist, die Mac auch, aber die Mac noch bei anderen IPs auftaucht, die andere Laufzeiten haben, dann sind die IPs mit gleicher Laufzeit auch auf einer anderen Hardware hinter so einem Router platziert und der Rest steht irgendwo anders.

Wenn man nur von einem Standort aus scannt, bekommt man möglicherweise einen falschen Eindruck, weil wir die „Welt“ nur zweidimensional sehen. Wenn unserer erstes Zwischengerät seine MAC anzeigt, könnten da noch einige andere hinter liegen, die wir nicht mehr sehen können. Deswegen ist eine automatische Topologie zumindest mit dieser simplen Methode hier, bei komplexen Setups nicht ausreichend genau.

Das war natürlich jetzt nur eine theoretische Überlegung, ich hatte ja gesagt, daß es da etablierte Methoden gibt. Wann könnte das also noch mal wichtig sein? z.B. wenn man mit LAHA Audio zeitgleich ans Ziel streamen will: Multi-Netzwerk-Lautsprecher mit Linux

Hier wäre, wenn wir es schon eingebaut hätten, die Laufzeit eine wichtige Komponente, damit die Streams alle zeitgleich zu hören sind. Vielleicht baue ich das ja mal ein. Ich habe gerade erst AndroidStudio wieder zum Leben erwecken können 😀

Anmerkungen:

Alle MACs sind frei erfunden. Je nach Aufgabenstellung kann man auch andere Ports als Scankriterium für Nmap oder gleich einen PING-Scan benutzen. NMAP gibt u.U. einen aufgelösten Domainnamen zurück:

Starting Nmap 7.80 ( https://nmap.org ) at 2020-08-19 13:14 CEST
Nmap scan report for android-501a417bc9ee518.fritz.box (192.168.0.39)
Host is up (0.090s latency).

PORT STATE SERVICE
445/tcp closed microsoft-ds
MAC Address: 6C:F1:76:2D:3B:AA (Samsung Electronics)

da müßt Ihr die SED Anweisungen entsprechend ändern oder nmap die „-n“ Option verpassen, sonst passieren skurille Dinge :DD

 

XRDP und der schwarze Bildschirm

Die Leser von RemoteDesktop mit XRDP & XFreeRDP haben vielleicht noch im Kopf, daß RDP mit Linux mit Cinnamon einen schwarzen Bildschirm produziert hat, weil Cinnamon scheinbar viel mit Hardwarebeschleunigung arbeitet. Darum geht es heute nicht 😀

XRDP und der schwarze Bildschirm

Ein Phänomen beim Ausprobieren von RDP mit Linux war, daß auf einem Linuxrechner die Desktopsession nicht zwangsläufig weiter lief, wenn die Verbindung vom Clienten gekappt wurde. Wenn man mit RDP arbeitet, gibt es vier Gründe wieso eine Sitzung getrennt wird:

Netzwerkausfall: Verbindung unterbrochen
Sitzungsende: Benutzer loggt aus
Updates: Windows rebootet
WTF!: Der Benutzer fährt den RemotePC runter, statt sich abzumelden.

In den Fällen, wo die Verbindung gekappt wird, kann man normal weiter arbeiten, wenn man die Verbindung durch einen Reconnect wieder herstellt. Bei Windows klappt das bis lang ohne Probleme, weswegen sich viele einfach gar nicht „abmelden“ sondern einfach den RDP Clienten beenden, ohne sich auszuloggen.

Jetzt versucht das Kunststück mal bei einem XRDP Server 🙂 Das kann funktionieren, habe ich heute erst erlebt, aber meistens geht es nicht. Man sieht nur einen schwarzen Bildschirm, wenn es überhaupt funktioniert mit der erneuten Verbindung.

Nicht Remote, Nicht Lokal

Jetzt haben wir die kuriose Situation, daß wir per Remote nicht mehr in den PC kommen, und sich am Bildschirm einloggen als der Benutzer geht auch nicht. Zumindest ich habe keinen gleichzeitig lokalen wie remote Login geschafft, wenn man von SSH absieht.

Was macht man jetzt?

Es bleibt leider nur eins zu tun: per SSH einloggen und alles terminieren, was nicht im Screen läuft. Letzteres werde ich bei den jetzt folgenden Anweisungen nicht beachten, weil das ein von Euch selbst verursachter Spezialfall ist 😉

Erstmal sondieren:

{benutzername}“ bitte als ganzes mit Euren Benutzernamen austauschen, die {} gehören zum Platzhalter.

sudo ps auxf | grep ^{benutzername} | awk ‚{print „kill -9 „$2“;# „$0;}‘

Das sieht erst einmal wüst aus, ist aber nur die normale Ausgabe aller Prozesse die vom Benutzer gestartet wurden. Das Kill vorne ist schon für die nächste Aktion vorbereitet und Ihr sollt eigentlich nur kurz prüfen, ob da a) auch immer eine PID steht (Prozess-ID) b) was alles gekillt würde.

kill kann einem Prozess sagen, daß er sich selbst beenden soll, daß er sich neustarten sollen oder wenn der Prozess unreaktiv aka. tod ist, diesen hart beenden (-9 Option).

Wenn Ihr das geprüft habt, dann könnt Ihr loslegen:

sudo ps auxf | grep ^{benutzername} | awk ‚{print „kill -9 „$2;}‘| bash

Ihr dürft natürlich gern darauf vertrauen, daß es schon alles richtig ist und es gleich beenden, aber wenn was schief geht, nicht im Kommentarblock ausheulen 😉

Bitte beachten:

Wenn man per SSH als der besagte Benutzer eingeloggt ist um sich seine Desktopsession zu terminieren, die Befehle oben betreffen auch die SSH Session! d.h. Ihr kickt Euch selbst dabei raus. Nicht wundern, das ist völlig normal. Daher ggf. noch mal einloggen und prüfen, ob auch wirklich alles weg ist, was weg sein sollte.

Das Problem läßt sich elegant durch einen ROOT Login vermeiden, weil wenn der das macht, trifft es ihn nicht. Aber da root auch Prozesse von sich selbst wegkillen könnte, müßt Ihr gerade bei so brutalen Kommandos die in der Shell zusammengestrickt sind extrem sorgsam sein.

Die Erklär-Sektion

farblich nochmal genau aufgeschlüsselt, was da gemacht wird:

sudo ps auxf | grep ^{benutzername} | awk{print „kill -9 „$2;}‚| bash

sudo                  führt ps als Root aus, was Begrenzungen aller Art bei der Ausgabe verhindert.
                      Kann aber weg gelassen werden.
ps                    "Prozesslist"
auxf                  listet alle Prozesse mit PID Username und Kommando auf.
grep                  filter die Ausgabe von ps nach...
^benutzername         allen Zeilen die mit dem Benutzernamen beginnen, das ^ ist wichtig dabei.
awk                   zerlegt die gefilterten Ausgaben in einzelne Spalten und ordnet die neu an.
{print "kill -9 "$2;} die neue Anordnung des Inhalts von Spalte 2 ( der PID )
bash                  führt die mit print zusammengebaute neue Anweisung "kill -9 PID" aus, 
                      wobei PID dann der Inhalt von Spalte 2 der Prozessliste ist.

Man erwischt so alle laufenden Prozesse des Users, egal wann, egal wieviele es sind.

RemoteDesktop mit XRDP & XFreeRDP

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.

Ein GNOME Remotearbeitsplatz mit laufendem VideoUnter 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 🙂

Linux Praxis: Remote Desktop Protokoll

Da ich kürzlich Gelegenheit bekam per Fernwartung in einer Firma mit Windowsclienten zu arbeiten, möchte ich Euch viel unnötiges Gesuche darüber ersparen, was geht und was nicht geht.

Windows 10 und RDP

Zunächst einmal, es geht um Windows 10 und dessen RDP Service. Das man den nicht einfach ins Netz exponieren kann, weil der PC sonst binnen Sekunden gehackt wird, sollte jedem spätestens seit BlueKeep und dessen Nachfolger, der sich gleich wurmartig fortpflanzen konnte, klar sein.

Wie macht man das jetzt, wenn man keine teure Firewalllösung einkaufen möchte, die dann vielleicht selbst zur ungepatchten Schwachstelle wird ( so wie die F5 ) oder nicht schnell genug die Signaturen aktualisiert?

Linux ist die Rettung

Man nehme ein gescheites Linux (Centos LTS mit Autoupdate würde reichen), und stellt es ins Intranet. Der SSH Port wird über DSL-Router nach außen exponiert, idealerweise nicht Port 22, was die Anzahl der Scans reduziert, und fail2ban-ed dann noch gleich die BruteForceangriffe weg 😉 . Das man den Zugriff nur per >=4K-SSH-Schlüssel und nicht mehr per PAM ( Passwort ) zulässt dürfte selbstverständlich sein, oder muß ich das extra erwähnen? 🙂

Wenn man Linux auch als Desktop hat, ist es jetzt ganz leicht den RDP Port des Windowszielrechners im Intranet auf 127.0.0.1 zu forwarden:

ssh -C -L 3389:192.168.178.33:3389 root@externe.dsl.ip

Kleiner Pro Tip: „-C“ nicht vergessen, dann komprimiert SSH die Daten zusätzlich noch, was gerade bei langsamen Verbindungen von Vorteil sein wird. Durch SSH wird die Verbindung über das Netz komplett verschlüsselt.

Wie verbindet man sich jetzt zu seinem mit TLS gesicherten RDP Service?

Jetzt kommen wir zum eigentlichen Problem mit Linux als RDP Clienten: kaum ein RDP Client taugt was.

Die kurze Liste der RDP Clienten unter Fedora lautet: RDesktop, gnome-rdp aka Vinagre und freerdp

RDesktop und Vinagre kann man gleich löschen. Der RDP Client der Wahl ist FreeRDP! Das ist nämlich der einzige, der überhaupt funktioniert. Vinagre baut zwar eine Verbindung auf, liefert aber nur ein Schwarzbild ab => fail. RDesktop war nicht mal dazu in der Lage.

FreeRDP hat neue Optionen

Im Netz findet man z.b. im Ubuntu-Forum Hinweise wie man FreeRDP erzählt, wo es hin soll und wie groß der Bildschirm sein. Leider muß man das angeben, sonst gibt es die Defaultwindowssession mit 1280×1024 😀 Das hatten wir dann auf dem 3k Display vom meinem Surface Pro als kleines Icon irgendwo in der Ecke vom Bildschirm liegen 😉 Ok,ok, Icongröße hatte es nicht ganz, aber da FreeRDP nicht DPI-Scaleaware ist, mußte man halt eine Lupe benutzen.

FreeRDP scheint seine CLI-Optionen umstrukturiert zu haben und man muß statt mit „-“ mit „/“ arbeiten. Beispiel: /size:WxH. Ob die sich an die Windows-DOSshell anwanzen wollten, wer weiß …

Windows failed beim DPI-Scaling

Es bliebt einem nichts anderes übrig als FreeRDP zu sagen, wie groß das Fenster denn sein soll, damit man dann einen größeren Font im Windows einstellen kann. Ab da wird es dann peinlich für M$, denn das DPI-Scaling funktioniert nur bei realen Bildschirmen, nicht bei Remote-Zugriffen per RDP 😀 Allen Versuchen zum Trotz blieb das Fenster ohne DPI-Scaling, auch als Windows behauptet hat, es würde 500%! skalieren 😉 Lustigerweise warnt einen Windows, daß es kein Vergnügen sein wird, ein 500% skaliertes Windows zu benutzen. Ich wäre schon froh über 200% gewesen 😀

Wenn man auf dem Windowsystem jetzt mit Browsern arbeiten muß, ist die Lösung denkbar einfach: das Browserfenster zoomen. Bei richtigen Anwendungen geht das natürlich nicht, was das Arbeiten auf einem 3k-4K Display nicht gerade vergnüglich macht. Da hilft es nur einen kleineren Bildschirm zu benutzen. Für ein FullHD Display könnte die Anweisung an FreeRDP so lauten:

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

Damit ist das Fenster brauchbar in Cinnamon eingefasst. Da wir glücklicherweise zwei HighSpeed-DSL Anschlüsse nutzen, ist die Latenz der Pakete sehr niedrig und das Arbeiten ist (bislang) angenehm.

Windows ist in dem Szenario leider nicht das einzige Programm, das failed. FreeRDP müßte das Scaling eigentlich auch automatisch beachten. FreeRDP bietet als Optionen jetzt einen Scalingparameter an, leider funktioniert auch das nicht sofort.

xfreerdp /u:username /v:hostname /size:1920×1080 /scale:140 /scale-desktop:200

Obiges bringt dann die Lösung. Damit läßt sich der Desktop uns seine Anwendungen auch auf 3k/4K besser lesen. Offensichtlich muß man Windows erst von außen sagen, das es skalieren soll, interne Einstellungen zählen halt nicht.

Für FreeRDP gibt es übrigens noch die Rocket-GUI, so muß man nicht alles in der Bash machen. Allerdings ist das Programm recht simple und wird nicht allen Anforderungen an unser spezielles Problem gerecht.