© Andy Dean / 123rf.com

Systemd bietet in Form von Homed eine Komponente, die das Umziehen des eigenen Home-Verzeichnisses einfach ermöglichen soll. Mittlerweile lassen sich Lösungen auf Basis von TPM, FIDO2 oder PKCS#12 einsetzen, um die gespeicherten Dateien abzusichern. Wie das funktioniert, zeigt dieser Artikel.

“Home, sweet home” heißt es im Englischen, und die deutsche Entsprechung “zu Hause ist es am schönsten” spiegelt in etwa dasselbe Gefühl wieder, das wohl jeder kennt: So sehr man sich auf den Urlaub freut und so sehr man darauf hinfiebert – ein paar Wochen später ist man dann doch ganz froh, mal wieder im eigenen Bett zu liegen.

In der IT ist es prinzipiell ähnlich: Hier versinnbildlicht das eigene Zuhause das Home-Verzeichnis (»~«), in dem neben den eigenen Daten auch die Konfigurationsdateien für die genutzten Programme lagern. Dazu gehört beispielsweise das eigene Google-Chrome-Profil oder jenes für Firefox; dazu gehört aber auch die Konfiguration für GTK, die dem installierten XFCE-Desktop das Look and Feel nach den eigenen Präferenzen verpasst. Daneben liegen im persönlichen Verzeichnis auch die Mails von Thunderbird, die eigenen Musiksammlungen und die eigenen Fotos. Wie das eigene Haus oder die eigene Wohnung ist in der Regel der persönliche Ordner eines Linux-Systems ebenfalls ein geliebtes Zuhause.

Hier geht sie allerdings los, die Malaise: Wer nicht nur auf einem Linux-System unterwegs ist, sondern mehrere Computer nutzt, findet seine persönlichen Dateien nicht auf all diesen Geräten. Und es ist gar nicht so trivial, dieses Problems Herr zu werden: Das Synchronisieren per Rsync etwa bedingt, dass es zwischen den Systemen eine funktionierende Netzwerkverbindung gibt. Ein Firmen-Laptop, der ins VPN eingewählt sein muss, um überhaupt eine Internet-Verbindung zu bekommen, erfüllt diese Bedingung schon mal nicht, hier guckt der Nutzer also zwangsläufig in die Röhre.

Kein neues Problem

Die Frage, was Anwender tun können, um ihr Home-Directory effizient mit einer Vielzahl von Systemen zu teilen, ist nicht neu. Seit Jahrzehnten haben sich am Markt immer wieder neue Lösungen auf Basis verschiedenster Ansätze versucht. Mal kamen geteilte Speicher wie NFS zum Einsatz, dann wieder Synchronisationslösungen wie Rsync. Und zwischenzeitlich gab es auch die Idee, das Problem per Samba zu erschlagen und Linux wie Domänenclients unter Windows zu betrachten. Wirkliche Durchdringung am Markt haben all diese Ansätze aber nicht erreicht.

Poettering schafft Abhilfe

Systemd-Chef Lennart Poettering war es schließlich, der sich eine Lösung aus den Fingern sog, die auf aktuellen Systemen funktioniert und im Hintergrund auf Systemd setzt. Homed heißt das Produkt wenig originell, doch anders als der Name suggeriert, soll Homed endlich dafür sorgen, dass Anwender ihr Home-Directory als externes Laufwerk (Abbildung 1) von Rechner A zu Rechner B und weiter zu Rechner C mitnehmen können, ohne in irgendwelche Scherereien zu laufen.

Abbildung 1: M2-SSDs sind so klein und leicht, dass sich auch größere Mengen an Daten heute problemlos hin und her verschieben lassen. Das macht Home-Verzeichnisse möglich, die nicht auf ein System beschränkt sind.

Das Ganze funktioniert höchst sicher und supereffizient: Verschlüsselung mit Mehrfaktorauthentifizierung ist ebenso Teil des Gesamtpakets (Abbildung 2) wie das dynamische Anlegen von Nutzern. Dieser Artikel stellt Homed vor und geht auf seine technischen Detail sein. Zuvor schadet es aber nicht, sich mit den konkreten Problemen zu beschäftigen, die Homed löst – denn das trägt in elementarer Art und Weise zum Verständnis bei, wie Homed funktioniert.

Abbildung 2: Verschlüsselung und Login mittels TPM-Modul unterstützt Homed zwar nicht, PKCS#11 sowie FIDO2 lassen sich aber nutzen. Quelle: HowTo-Geek

Woran es bisher scheiterte

Die Idee des portablen Home-Verzeichnisses setzt ein paar Dinge voraus, die unter Linux oder generell POSIX-artigen Betriebssystemen nicht unbedingt üblich sind. Da ist zunächst das Problem der Benutzerverwaltung. Wer auf seinem eigenen System als Benutzer Martin unterwegs ist, wird diesen Benutzernamen auch andernorts verwenden wollen, wenn er sein mobiles Home-Directory nutzt. Nun ist es freilich nicht so, dass auf sämtlichen Linux-Systemen dieser Welt ein Benutzerzugang mit passendem Namen vorkonfiguriert wäre, der nur darauf wartet, dass jemand die SSD mit dem passenden Home-Directory einsteckt. Das Anlegen eines passenden Benutzers muss stattdessen explizit passieren. Zunächst muss auf einem System also ein Benutzerzugang entstehen; erkennt das System danach, dass für den jeweiligen Anwender ein mobiles Home-Directory vorhanden ist, bindet es dieses ein. Schon hier sieht Systemd sich einer Herausforderung gegenüber – denn vor Homed hatte es in der Benutzerverwaltung des Systems nichts zu suchen. Nun aber muss es Benutzer und Gruppen anlegen können.

Das Ganze muss auch in die andere Richtung funktionieren. Stellt man sich etwa öffentlich zugängliche Systeme vor, die für die Benutzung durch mehrere Menschen mit portablem Home-Verzeichnis vorgesehen sind, wird schnell klar: Die angelegten Benutzerzugänge müssen sich, sobald der Anwender sich abmeldet und das Speicherlaufwerk entfernt, durch das System auch wieder löschen lassen. Denn nicht deaktivierbare Benutzerzugänge sind nicht nur nutzlos, sie sind auch gefährlich: Es wäre nicht das erste Mal in der IT-Geschichte, dass ein alter, vergessener Account zum Einsatz in einem Angriffsszenario kommt.

Das leidige Thema User-IDs

Noch ein Faktor spielt bei dynamisch genutzten Home-Verzeichnissen eine große Rolle, nämlich der Faktor der User-IDs. Der steht allerdings in engem Zusammenhang mit dem Faktor der Benutzernamen. Auf der Systemebene von Linux ist der Benutzername effektiv ja nur die für Menschen besser lesbare Variante der User-ID, die dem jeweiligen Account auf der Systemebene zugeordnet ist. Wenn das System nun einen Benutzer dynamisch anlegen soll, nachdem ein Speicherlaufwerk in einen USB-Slot des Gehäuses gesteckt wurde, legt dieser Vorgang implizit also auch eine User-ID an.

Anhand der User-ID (und parallel dazu der Gruppen-ID) definiert ein Linux-System allerdings diverse Parameter für jede einzelne Datei – etwa wem diese gehört und wer Zugriff darauf erhält. Und diese Informationen sind im Dateisystem abgelegt, also auch auf dem USB-Stick oder der SSD, die ein portables Home-Verzeichnis enthält. Stöpselt der Anwender also eine SSD ein, sollte die UID des Benutzers auf dem System besser zu den Inhalten auf dem USB-Stick passen. Ist das ab Werk nicht der Fall, muss es einen Mechanismus geben, der diesen Umstand korrigiert. Andernfalls würde der Zugriff auf die Dateien auf dem Speicherlaufwerk ständig durch fehlende Berechtigungen fehlschlagen.

Verschlüsselung ist Pflicht

Hinzu kommt eine Notwendigkeit, die viele Benutzer bis heute erstaunlicherweise noch immer nicht auf dem Schirm haben: die Verschlüsselung des Laufwerks. Bei vielen PCs und sicherlich bei den allermeisten beruflich genutzten Geräten übersteigt der Wert der auf der Maschine gespeicherten Daten den der Hardware deutlich. Selbst ein top ausgestattetes Thinkpad schlägt mit “nur” guten 4000 Euro brutto zu Buche. Lagert auf dem Gerät jedoch der Bauplan für eine innovative Maschine oder die aktuelle Steuererklärung des eigenen Unternehmens und es gerät in falsche Hände, ist Holland in Not: Der durch Industriespionage und Rufschädigung hervorgerufene Schaden übersteigt den Wert der Hardware dann gern um ein Vielfaches.

Die Hersteller haben das längst erkannt; Microsoft etwa bietet Bitlocker an, um sämtliche Speicher-Geräte von PCs im Hintergrund vollautomatisch zu verschlüsseln. Apple stößt mit FileVault in dasselbe Horn, und auch die gängigen Linux-Distributionen setzen mittlerweile vor allem auf Desktops auf flächendeckende Verschlüsselung der Datenträger. Da liegt es auf der Hand, dass ein NVMe- oder SSD-Laufwerk ebenfalls verschlüsselt zu sein hat, wenn es das Gros der wichtigsten Informationen des eigenen Lebens enthält.

Wie aber lässt sich sichere Verschlüsselung mobiler Geräte gut erreichen, wenn der Computer drumherum fehlt? Ein 64 Stellen langes Passwort bietet zwar einige Sicherheit, doch sind 32 oder gar 64 Zeichen lange Passwörter kein probates Mittel, weil sie sich niemand merken kann. Nützlicher ist die Verschlüsselung mittels Zertifikat oder die Zugangskontrolle mittels mehrerer Faktoren, etwa FIDO2, in Ergänzung zum Passwort. Denn so fließen die Daten selbst dann nicht ungewollt ab, wenn Stick und Passwort einem Dritten in die Hände fallen, nicht jedoch der zweite Authentifizierungsfaktor. Allerdings: Wenn man diesen technischen Aufwand schon betreibt, um das Gerät zu verschlüsseln, dann kann man das genutzte Token gleich auch verwenden, um die Anmeldung des Anwenders am System abzuwickeln.

Schnell wird klar: Mobile Home-Verzeichnisse sind eine tolle Idee und scheinen sich in der Theorie simpel implementieren zu lassen. Beschäftigt man sich allerdings im Detail mit den technischen Herausforderungen des Prinzips, tritt schnell Ernüchterung ein. Die Systemd-Entwickler stellen in Form von Homed eine Lösung vor, die zumindest von sich behauptet, die beschriebenen Herausforderungen anzugehen. Wie tut sie das im Detail, wie profitiert der Anwender davon, und wo liegen die Grenzen des Systems?

Mit Homed loslegen

Wer transportable Home-Verzeichnisse mit Homed ausprobieren möchte, braucht dazu nicht viel. Zumindest die verschiedenen Desktop-Distributionen sind hinlänglich aktuell, um Homed samt und sonders zu inkludieren. Bei Exoten wie Raspberry Pi OS gestaltet sich die Situation möglicherweise nicht ganz so leicht. Hier dienen oft ältere Systeme wie Debian GNU/Linux “Buster” als Fundament, Homed liegt höchstens in einer veralteten und mithin nicht zufriedenstellenden Version bei. Immerhin ist Debian GNU/Linux 11 alias “Bullseye” mittlerweile erschienen; die Hoffnung auf ein baldiges Update besteht also auch für solche Systeme.

Eine hinreichend aktuelle Systemd-Version umfasst automatisch Homed, und die Werkzeuge Homectl [1] und Userdbctl sollten auf dem System vorhanden sein. Homectl legt dabei Benutzer an, Userdbctl ist ein Abfragewerkzeug. Damit steht auch fest: Systemd geht nicht den Weg, anhand eingesteckter Geräte automatisch den Benutzernamen zu finden. Theoretisch wäre ja durchaus denkbar, dass Homed einen passenden Benutzerzugang anlegt, sobald man ein Device einsteckt. Das würde die völlige Flexibilisierung des Home-Verzeichnisses bedeuten, weil es dann sogar an öffentlichen Terminals verfügbar wäre, die Homed unterstützen. Eben diesen Ansatz gehen die Entwickler aber ganz bewusst nicht. Homed wartet stattdessen darauf, dass der Anwender den Account anlegt, etwa mittels »homectl create martin«. Das setzt freilich die Rechte des Systemadministrators root voraus. Schnell wird klar: Homed bedient vorrangig Einsatzszenarien, bei denen der Nutzer wirklich nur sein persönliches Verzeichnis zwischen mehreren Systemen teilt. Über die hat er dann aber jeweils die volle Hoheit.

Mit Benutzer-IDs hantieren

Homed implementiert das Anlegen und Löschen von Anwendern an den bestehenden Mechanismen des Systems wie »/etc/passwd« und »/etc/group« vorbei. Stattdessen klinkt es sich per separatem PAM-Modul in die dynamische Authentifizierung ein und ergänzt das bestehende Anmeldesystem dadurch. Für den Administrator ist das eine wichtige Information,denn für ihn bedeutet das: Wenn er Homed auf mehreren Systemen zur Verwaltung eines zentralen Home-Verzeichnisses nutzen möchte, kann er über die Parameter für Homectl zum Beispiel die User-IDs beeinflussen. Auf diese Weise stellt er also selbst sicher, dass auf allen teilnehmenden Systemen die User-IDs der betroffenen Benutzer übereinstimmen – was ausdrücklich angeraten sei. Denn sonst verwendet Homed notgedrungen einen kruden Hack, um Ordnung zu schaffen: Es fährt dann einfach mit Chown nach der Anmeldung einmal über das komplette Home-Directory und ändert dessen Inhalte so auf die User-ID und Group-ID, die der Benutzer auf dem System eben hat.

Mal angenommen, die User-ID des Anwenders solle auf allen Systemen 2000 sein, so legt der folgende Befehl den Anwender entsprechend an – und steuert gleich noch ein paar Hintergrundinformationen bei:

$ homectl create martin --real-name="Martin Loschwitz" --uid=2000

Auch hiernach existiert auf dem System ein Benutzer martin, der Mitglied einer gleichnamigen Gruppe ist. Anders als zuvor hat er aber keine zufällig durch Homed ausgewählte UID, sondern eben die händisch festgelegte. Ungelöst sind aber immer noch die Probleme im Hinblick auf das persönliche Verzeichnis des Anwenders. Dieses hat Homed zwar angelegt und auch per LUKS verschlüsselt. Mobil ist es dadurch jedoch noch lange nicht.

Denn wenn der Anwender nichts anderes festlegt, erstellt Homed ein verschlüsseltes Home-Directory per LUKS und Loop-Device in »/home/Benutzer.homedir/« und hängt dieses nach »/home/Benutzer/« erst dann ein, wenn der Anwender sich erfolgreich am System angemeldet hat. Das ist bei Homed grundsätzlich Programm: Das persönliche Verzeichnis eines Anwenders ist nur im Zugriff, solange der Benutzer angemeldet ist. Sobald die letzte Login-Session des Benutzers erlischt, hängt Systemd das Verzeichnis mit den persönlichen Daten des Anwenders automatisch aus. Um es wieder in Betrieb zu nehmen, ist ein erneuter Anmeldevorgang zwingend notwendig.

Wirklich mobile Home-Verzeichnisse

Wer sich unter Linux schon einmal mit verschlüsselten Volumes befasst hat, weiß, dass die Arbeit mit LUKS & Co. nicht zwangsläufig angenehm ist. Homed nimmt dem Admin hier einen großen Teil der Arbeit ab, indem es LUKS im Hintergrund nach den Vorgaben des Admins konfiguriert – diesen mit den LUKS-Werkzeugen selbst jedoch nicht unmittelbar in Kontakt kommen lässt. Entsprechend ist es auch wieder nur eine Frage des richtigen Parameters für Homectl, das durch Homed angelegte Benutzerverzeichnis eben nicht lokal abzuladen, sondern auf einem USB-Stick.

Ausgehend vom zuvor genutzten Homectl-Kommando nutzt der folgende Befehl einen USB-Stick zur Ablage des persönlichen Verzeichnisses:

$ homectl create martin --real-name="Martin Loschwitz" --uid=2000 --image-path=/dev/disk/by-id/usb-SanDisk_Ultra_4C530000060908106243-0:0

Den Teil hinter »image-path« gilt es anzupassen, wenn man den USB-Stick wie im Beispiel über seine eindeutige Geräte-ID referenziert. Homed kümmert sich auch hier wieder um den gesamten administrativen Aufwand: Es löscht zunächst alle vorhandenen Dateien vom USB-Stick, legt auf diesem anschließend eine Partitionstabelle an und erstellt danach ein per LUKS verschlüsseltes Gerät. Und voilà – dieses ist nun in der Tat portabel: Loggt der Besitzer des Verzeichnisses sich aus dem System aus, sodass keine aktuelle Session mehr existiert, meldet Homed das LUKS-Gerät automatisch ab. Den USB-Stick, auf dem dieses residiert, stöpselt der Anwender dann einfach ab, nimmt ihn mit zu einem anderen Gerät, loggt sich dort mit einem von Homed verwalteten Account ein, und Homed kann das Home-Verzeichnis anhand des USB-Sticks erkennen und automatisch auf dem anderen System aktivieren.

Die Sache mit PKCS, Tokens & Co.

Ein Problem hat der Benutzer so, wie ihn die Beispiele im Artikel angelegt haben, noch: Er hat kein Passwort und auch keine alternative Anmeldemethode spezifiziert, sodass er sich schlechterdings gar nicht erst einloggen kann. Das muss sich ändern, und zum Glück bietet Systemd viel mehr Möglichkeiten als dumpfe Passwörter. Das Team rund um Lennart Poettering schöpft hier aus dem Vollen, und die größte Hürde für Admins dürfte darin bestehen, das jeweilige Authentifizierungsgerät mit der passenden Option beim Anlegen des Anwenders im Homed zu kombinieren. Das liegt aber ausnahmsweise mal nicht an Systemd selbst, sondern an der Vielzahl von Standards und ihren Optionen, die für diese Aufgabe am Markt bereits existieren.

Die beiden bekanntesten Vertreter der Kryptoschlüssel dürften PKCS#11 und FIDO2 sein. PKCS#11 ist der etwas andere Standard (Abbildung 3); ältere YubiKeys nutzen ihn, vor allem dürfte er aber von klassischen Smartcards her bekannt sein. Soll eine Smartcard (Abbildung 4) oder ein älterer YubiKey zum Einsatz kommen, um den Account zu entsperren, besteht die größte Herausforderung darin, den Pfad (also die URI) zum Gerät im System zu identifizieren. Homectl bietet aber immerhin einen Ausweg: »homectl –pkcs11-token-uri=list« zeigt eine Liste aller verfügbaren Geräte an. Damit der Befehl das jeweilige Device findet, muss dieses zum Zeitpunkt des Aufrufs freilich eingehängt sein.

Abbildung 3: Ältere Yubikeys nutzen ältere Versionen von Authentifizierungstokens. Quelle: Yubikey

Abbildung 4: PKCS#11-basierte Authentifizierung findet heute üblicherweise über echte Smartcards statt. Quelle: Cardomatic

Wer stattdessen einen Authentifizierer nach FIDO2-Standard nutzt (Abbildung 5), braucht den Parameter »–fido2-device=«. Auch dieser unterstützt das Schlüsselwort »list«, das eine Liste der verfügbaren Geräte samt ihrer URI im System zutage fördert. Zudem funktioniert das Schlüsselwort »auto«, wenn nur ein einziges, passendes Gerät zur Verfügung steht. Der gesamte Aufruf lautet dann:

$ homectl create martin --real-name="Martin Loschwitz"--uid=2000 --image-path=/dev/disk/by-id/usb-SanDisk_Ultra_4C530000060908106243-0:0 --fido2-device=auto

Abbildung 5: Auch modernere FIDO2-Token lassen sich an Homed anbinden. Gibt der Admin den passenden Parameter beim Anlegen des Nutzers an, entsperrt der FIDO2-Key anschließend den Account samt Home-Verzeichnis. Quelle: Feitian

Der auf diese Weise angelegte Nutzer hat ein persönliches Verzeichnis auf einem USB-Stick und meldet sich am System per Authentifizierungsgerät an.

Sonderfall PKCS#11

Wer PKCS-Anmeldung nutzen möchte, muss unbedingt daran, denken, dass vor der Konfiguration in Homed auch der YubiKey entsprechend vorzubereiten ist. Der Befehl »ykman« steht auf entsprechend vorbereiteten Systemen üblicherweise zur Verfügung. »ykman piv reset« löscht zunächst alte Schlüssel vom Gerät. »ykman piv generate-key -m RSA4096:*9d pubkey.pm« legt einen neuen Schlüssel an, gefolgt von »ykman piv generate-certificate –subject “Homed” 9d pubkey.pem«. Dieser Befehl wiederum generiert das passende Zertifikat zum Schlüssel und lädt es auf den YubiKey. »rm pubkey.pem« entfernt anschließend die Schlüsseldatei im Dateisystem. Danach lässt sich der Login wie beschrieben konfigurieren.

Auf Nummer sicher gehen

Nicht unter den Tisch fallen soll der Parameter »–recovery-key«, den Homectl ebenfalls kennt. Nahezu jeder, der sich schon mal ausgiebig mit Kryptographie befasst hat, weiß: Verliert man das Gerät zum Erzeugen von Tokens oder den ursprünglichen Key, kommt man an die Daten beim besten Willen nicht mehr heran. Es hat sich deshalb als gute Praxis herausgestellt, einen Notfallschlüssel zusammen mit dem Gerät zu erzeugen, den man an einem sicheren Ort lagert. Der Schlüssel muss unbedingt vor dem Zugriff durch Unbefugte geschützt werden, denn jeder, der ihn hat, kann das verschlüsselte Volume entschlüsseln. Es empfiehlt sich daher, den Schlüssel auf Papier ausgedruckt an einem sicheren Ort zu hinterlegen, etwa in einem Safe.

Indem der Anwender dem Befehl zum Anlegen des Nutzers den Parameter »–recovery-key=yes« anhängt, sorgt er jedenfalls dafür, dass Homed einen passenden Key automatisch anlegt. Dieser wird anschließend auf Bildschirm angezeigt und kann von dort kopiert werden.

Nutzer nachträglich verändern

Regelmäßig kommt es vor, dass beim initialen Anlegen eines Benutzers in Homed nicht alle Parameter genutzt worden sind, die eigentlich gewünscht werden. Wer zum Zeitpunkt des Aufsetzens eines Nutzers etwa noch keinen YubiKey oder keine Smartcard hat, kann diese freilich auch nicht verwenden. Die gute Nachricht ist, dass Homed das Hinzufügen von Details wie Entschlüsselungsgeräten und das nachträgliche Modifizieren von Details eines Accounts durchaus vorsieht. Hier kommt der Befehl »homectl update« ins Spiel.

Wer etwa die PKCS#11-basierte oder FIDO2-basierte Authentifizierung nachträglich für einen Account anschalten möchte, tut das mittels »homectl update martin –pkcs11-token-uri=auto« oder »homectl update martin –fido2-device=auto«. Gut zu erkennen: Die Befehle und Parameter sind dieselben wie beim einmaligen Einrichten des Nutzers. An neue Parameter braucht der Admin sich also nicht zu gewöhnen.

Die Grenzen des Prinzips

Es stellt sich heraus, dass Homed das Versprechen des mobilen Home-Verzeichnisses durchaus ernst nimmt und sinnvoll implementiert. Bei aller Euphorie über die Technik sollten Nutzer und Admins allerdings nicht vergessen, dass das Prinzip technischen Einschränkungen unterliegt, die auch Homed nicht mal eben so wegdefinieren kann.

Die relevanteste Einschränkung besteht dabei gar nicht auf Ebene von Homed, sondern auf Ebene der Anwendungen, die der Nutzer mit seinem portablen Verzeichnis verwendet. Das Home-Verzeichnis wird sich relativ fix mit Müll füllen, wenn der Anwender es auf unterschiedlichen Systemen mit unterschiedlichen Distributionen zum Einsatz bringt, weil dann die Konfigurationsdateien konkurrierende Einträge enthalten. Wer etwa auf dem einen System ein Ubuntu 18.04 und auf dem anderen ein Ubuntu 21.04 nutzt, findet in beiden Distributionen unterschiedliche KDE-Versionen. Stöpselt man das Home-Verzeichnis der KDE-Version aus Ubuntu 18.04 nun an den Rechner mit Ubuntu 21.04, wird KDE die alten Konfigurationsdateien finden und entsprechend konvertieren. Der Rückweg ist dann allerdings versperrt: KDE auf Ubuntu 18.04 kann mit der neuen Konfiguration nichts anfangen und legt im schlechtesten Fall eine komplett neue an.

Noch offensichtlicher werden die Probleme, wenn man sich unterschiedliche Systeme oder Distributionen vorstellt. Das Heimat-Verzeichnis von OpenSuse Leap wird kaum mit Raspbian harmonieren, wie es auf einem Raspberry Pi zum Einsatz kommt.

Wer entsprechende Kompatibilitätsprobleme vermeiden möchte, muss händisch dafür sorgen, dass die jeweiligen Dateien gar nicht erst im Home-Verzeichnis landen. Das hat den unschönen Nebeneffekt, dass man dann auf jedem System, an dem man sich anmeldet, erst wieder den eigenen Desktop konfigurieren muss. Alternativ kann man darauf achten, das geteilte Home-Verzeichnis nur auf Systemen zu nutzen, die im weitesten Sinne miteinander kompatibel sind. (jcb)