Systemd-homed ermöglicht, das eigene Home-Verzeichnis nahtlos auf mehreren Rechnern zu nutzen. Dabei gilt es allerdings einige Rahmenbedingungen zu beachten.

“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 & 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 auch der persönliche Ordner eines Linux-Systems ein geliebtes Zuhause.

Hier geht sie allerdings los, die Malaise: Wer nicht nur ein einzelnes Linux-System nutzt, sondern mehrere, der findet seine persönlichen Dateien nicht auf all diesen Geräten. Es ist gar nicht so trivial, dieses Problems Herr zu werden: Das Synchronisieren per Rsync etwa setzt voraus, 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 schaut der Nutzer also zwangsläufig in die Röhre.

Die Frage, was Anwender tun können, um ihr Home-Directory effizient auf 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änen-Clients unter Windows zu betrachten. Wirklich durchgesetzt hat sich aber keiner dieser Ansätze.

Poettering hilft

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 die Komponente wenig originell und soll endlich dafür sorgen, dass Anwender ihr Home-Directory auf einem externen Laufwerk (Abbildung 1) von Rechner A zu Rechner B und weiter zu Rechner C mitnehmen können, ohne in irgendwelche Probleme zu laufen.

Abbildung 1: M2-SSDs sind so klein und leicht, dass sich damit auch größere Mengen an Daten problemlos hin und her schieben 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 Details ein. Es schadet aber nicht, sich vorab 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: Eine Verschlüsselung und ein Login mittels TPM-Modul unterstützt Homed zwar nicht, PKCS#11 sowie FIDO2 lassen sich aber nutzen. Quelle: HowTo-Geek

Benutzerverwaltung

Die Idee des portablen Home-Verzeichnisses setzt ein paar Dinge voraus, die unter Linux oder generell POSIX-artigen Betriebssystemen nicht unbedingt üblich sind. Das beginnt bei der Benutzerverwaltung. Wer auf seinem eigenen System als Benutzer martin unterwegs ist, möchte diesen Benutzernamen auch andernorts verwenden, wenn er sein mobiles Home-Directory nutzt. Nun ist freilich nicht auf sämtlichen Linux-Systemen dieser Welt ein Benutzerzugang mit passendem Namen vorkonfiguriert, der nur darauf wartet, dass jemand die SSD mit dem entsprechenden Home-Directory einsteckt. Das Anlegen eines passenden Benutzers muss stattdessen explizit erfolgen. Erkennt das System danach, dass es für den fraglichen Anwender ein mobiles Home-Directory gibt, 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 hat es Benutzer und Gruppen anzulegen. 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 Anwender mit portablem Home-Verzeichnis vorgesehen sind, wird schnell klar: Das System muss die angelegten Benutzerzugänge auch wieder löschen können, sobald der Anwender sich abmeldet und das Speicherlaufwerk entfernt. Nicht deaktivierbare Benutzerzugänge sind nicht nur nutzlos, sondern auch gefährlich: Es wäre nicht das erste Mal in der IT-Geschichte, dass ein alter, vergessener Account in einem Angriffsszenario zum Einsatz kommt.

Benutzerkennung

Noch ein Faktor spielt bei dynamisch genutzten Home-Verzeichnissen eine große Rolle: die User-IDs. Sie stehen in engem Zusammenhang mit dem Benutzernamen. Auf der Systemebene von Linux fungiert der Benutzername ja nur als für Menschen besser lesbare Variante der User-ID zum jeweiligen Account. Soll das System nun einen Benutzer dynamisch anlegen, nachdem ein Speicherlaufwerk in einen USB-Slot des Gehäuses gesteckt wurde, erzeugt dieser Vorgang implizit also auch eine User-ID.

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. Diese Informationen liegen im Dateisystem, also auch auf dem USB-Stick oder der SSD, die ein portables Home-Verzeichnis enthalten. 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üsselungspflicht

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. Lagern auf dem Gerät jedoch wichtige persönliche oder berufliche Daten und es gerät in falsche Hände, ist Holland in Not. Die Hardware lässt sich wieder beschaffen, die Daten oft aber nur schwer oder gar nicht.

Die Hersteller haben das längst erkannt. Microsoft etwa bietet Bitlocker an, um sämtliche Speichergeräte eines 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 man ein NVMe- oder SSD-Laufwerk ebenfalls verschlüsselt, 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 das kann sich kaum jemand merken. Nützlicher ist die Verschlüsselung mittels Zertifikat oder die Zugangskontrolle mittels mehrerer Faktoren, etwa FIDO2, in Ergänzung zum Passwort. 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. Wenn man jedoch diesen technischen Aufwand schon betreibt, um das Gerät zu verschlüsseln, dann kann man das genutzte Token auch gleich verwenden, um die Anmeldung des Anwenders am System abzuwickeln.

Mobile Home-Verzeichnisse sind zwar 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

Möchten Sie transportable Home-Verzeichnisse mit Homed ausprobieren, brauchen Sie dazu nicht viel. Die gängigen Desktop-Distributionen bringen Homed samt und sonders bereits mit. Eine hinreichend aktuelle Systemd-Version umfasst automatisch Homed, und die Werkzeuge Homectl [1] und Userdbctl [2] sollten auf dem System vorhanden sein. Homectl legt dabei Benutzer an, bei Userdbctl handelt es sich um ein Abfragewerkzeug.

Bei Exoten wie Raspberry Pi OS gestaltet sich die Situation nicht ganz so unkompliziert. Hier dienen oft ältere Systeme wie Debian GNU/Linux 10 “Buster” als Fundament, Homed liegt höchstens in einer veralteten und damit nicht zufriedenstellenden Version bei. Immerhin liegt mittlerweile Debian GNU/Linux 11 alias “Bullseye” vor, es besteht also auch für solche Systeme Hoffnung auf ein baldiges Update.

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. Damit wäre das Home-Verzeichnis sogar an öffentlichen Terminals verfügbar, die Homed unterstützen. Eben diesen Ansatz ließen die Entwickler aber ganz bewusst beiseite. Homed wartet stattdessen darauf, dass der Anwender den Account anlegt, etwa mittels homectl create martin. Das setzt freilich die Rechte des Systemadministrators root voraus. Homed bedient also 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 User-IDs hantieren

Homed mogelt sich beim Anlegen und Löschen von Benutzerkonten an den bestehenden Mechanismen wie /etc/passwd und /etc/group vorbei. Stattdessen klinkt es sich über ein separates PAM-Modul in die dynamische Authentifizierung ein und ergänzt so das bestehende Anmeldesystem.

Wenn Sie Homed also auf mehreren Systemen zum Verwalten eines zentralen Home-Verzeichnisses nutzen möchten, können Sie über die Parameter für Homectl zum Beispiel die User-IDs beeinflussen. Auf diese Weise stellen Sie also am besten selbst sicher, dass auf allen teilnehmenden Systemen die User-IDs der fraglichen Accounts übereinstimmen. Anderenfalls verwendet Homed notgedrungen einen kruden Hack, um Ordnung zu schaffen: Es fährt dann einfach nach der Anmeldung mit Chown einmal über das komplette Home-Directory und ändert dabei die Berechtigungen für die Inhalte auf die User- und Group-ID, die der Benutzer auf dem System eben hat.

Nehmen wir an, die User-ID des Anwenders martin soll auf allen Systemen 2000 lauten. Der Befehl aus Listing 1 legt den Anwender entsprechend an und steuert gleich noch ein paar Hintergrundinformationen bei. Nach dem Ausführen 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 per Befehl festgelegte.

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

Das löst aber nicht die Probleme im Hinblick auf das persönliche Verzeichnis des Anwenders: Das legt Homed zwar an und verschlüsselt es auch per LUKS [3]. Mobil ist es dadurch jedoch noch lange nicht. Wenn Sie nichts anderes festlegen, erstellt Homed zwar ein verschlüsseltes Home-Directory per LUKS und ein Loop-Device in /home/Benutzer.homedir/. Letzteres hängt es jedoch erst dann nach /home/Benutzer/ ein, wenn der zugehörige Anwender sich erfolgreich am System angemeldet hat.

Das ist bei Homed grundsätzlich Programm: Das persönliche Verzeichnis eines Anwenders bleibt nur so lange im Zugriff, wie der Benutzer angemeldet ist. Sobald die letzte Login-Session des Benutzers erlischt, hängt Systemd dessen Home-Verzeichnis automatisch aus. Es wieder in Betrieb zu nehmen erfordert zwingend einen erneuten Anmeldevorgang.

Wirklich mobil

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 Ihnen hier einen großen Teil der Arbeit ab, indem es LUKS im Hintergrund nach Ihren Vorgaben konfiguriert, ohne dass Sie mit den LUKS-Werkzeugen selbst unmittelbar in Kontakt kommen. Entsprechend genügt auch die Angabe eines passenden Parameters für Homectl, um das durch Homed angelegte Benutzerverzeichnis eben nicht lokal abzuladen, sondern auf einem USB-Stick. Ein Beispiel zeigt Listing 2. Den Teil hinter --image-path müssen Sie anpassen, um den USB-Stick wie hier über seine eindeutige Geräte-ID zu referenzieren.

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

Homed kümmert sich um den gesamten administrativen Aufwand: Es löscht zunächst alle vorhandenen Dateien vom USB-Stick, legt darauf eine Partitionstabelle an und erstellt ein per LUKS verschlüsseltes Gerät. Das 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 zugehörigen USB-Stick stöpselt der Anwender dann einfach ab und nimmt ihn mit zu einem anderen Gerät. Meldet er sich dort an einem von Homed verwalteten Account an, erkennt Homed das Home-Verzeichnis anhand des verwendeten USB-Sticks und aktiviert es automatisch.

PKCS, Tokens und mehr

Der in den Beispielen angelegte Benutzer martin hat allerdings noch ein Problem: Er kann sich gar nicht erst einloggen, weil ihm ein Passwort dazu fehlt und auch keine alternative Anmeldemethode spezifiziert wurde.

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 dürfte darin bestehen, das jeweilige Authentifizierungsgerät mit der passenden Option beim Anlegen des Anwenders im Homed zu kombinieren. Das liegt aber ausnahmsweise einmal nicht an Systemd selbst, sondern an der Vielzahl von Standards und Optionen, die es für diese Aufgabe gibt.

Die beiden bekanntesten Vertreter der Kryptoschlüssel dürften PKCS#11 und FIDO2 sein. Den PKCS#11-Standard kennt man vor allem von klassischen Smartcards (Abbildung 3), aber auch ältere YubiKeys [4] nutzen ihn (Abbildung 4). Soll ein solches Token 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 hilft dabei: Das Kommando homectl --pkcs11-token-uri=list zeigt eine Liste aller verfügbaren Geräte an. Damit der Befehl das jeweilige Device findet, muss es zum Zeitpunkt des Aufrufs freilich eingehängt sein.

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

Abbildung 4: Ältere YubiKeys nutzen ältere Versionen von Authentifizierungstokens. Quelle: YubiKey

Nutzen Sie stattdessen einen Authentifizierer nach FIDO2-Standard (Abbildung 5), brauchen Sie den Parameter --fido2-device=. Auch er unterstützt das Schlüsselwort list, das eine Liste der verfügbaren Geräte samt ihrer URI im System zutage fördert. Steht nur ein einziges passendes Gerät zur Verfügung, funktioniert auch das Schlüsselwort auto.

Abbildung 5: Auch modernere FIDO2-Token lassen sich an Homed anbinden. Quelle: Feitian

Geben Sie beim Anlegen des Nutzers so wie in Listing 3 den passenden Parameter an, entsperrt der entsprechende Krypto-Key anschließend den Account samt Home-Verzeichnis. Der auf diese Weise angelegte Nutzer hat also ein persönliches Verzeichnis auf einem USB-Stick und meldet sich am System per Authentifizierungsgerät an.

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

# ykman piv reset
# ykman piv generate-key -m RSA4096:*9d pubkey.pm
# ykman piv generate-certificate --subject "Homed" 9d pubkey.pem
# rm pubkey.pem

Nummer sicher

Nicht unter den Tisch fallen darf der Homectl-Parameter --recovery-key. Wie jeder weiß, der sich schon näher mit Kryptografie befasst hat: 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 zu erzeugen, den man an einem sicheren Ort lagert, um ihn dem Zugriff durch Unbefugte zu entziehen. Jeder, der diesen Key hat, kann das verschlüsselte Volume dechiffrieren. Es empfiehlt sich daher, den Schlüssel auf Papier ausgedruckt an einem sicheren Ort zu hinterlegen, etwa in einem Safe.

Indem Sie dem Befehl zum Anlegen des Nutzers den Parameter --recovery-key=yes anhängen, weisen Sie Homed an, automatisch einen passenden Key anzulegen. Den zeigt Homectl anschließend auf Bildschirm an, von wo Sie ihn kopieren können.

Nutzer verändern

Regelmäßig kommt es vor, dass man beim ersten Anlegen eines Benutzers in Homed nicht alle eigentlich gewünschten Parameter kennt. Wenn man zum Zeitpunkt des Aufsetzens etwa noch keinen YubiKey oder keine Smartcard besitzt, kann man sie auch nicht verwenden. Erfreulicherweise sieht Homed das Hinzufügen von Entschlüsselungsgeräten sowie das nachträgliche Modifizieren von Details eines Accounts durchaus vor. Hier kommt der Befehl homectl update ins Spiel. Mit den Befehlen aus Listing 5 beispielsweise lässt sich nachträglich eine PKCS#11- beziehungsweise FIDO2-basierte Authentifizierung nachträglich für einen Account anschalten. Die Befehle und Parameter sind dieselben wie beim einmaligen Einrichten des Nutzers.

# homectl update martin --pkcs11-token-uri=auto
# homectl update martin --fido2-device=auto

Grenzen des Prinzips

Homed nimmt das Versprechen des mobilen Home-Verzeichnisses durchaus ernst und implementiert es sinnvoll. Bei aller Euphorie über die Technik darf man allerdings nicht vergessen, dass das Prinzip technischen Beschränkungen unterliegt, die auch Homed nicht ohne Weiteres aufheben 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. Sobald Sie ihr Home-Verzeichnis auf Rechnern mit unterschiedlichen Distributionen oder Distributionsversionen verwenden, füllt es sich relativ fix mit Müll, weil dann die Konfigurationsdateien konkurrierende Einträge enthalten.

Nutzen Sie etwa auf dem einen System Ubuntu 18.04 und auf dem anderen Ubuntu 21.04, arbeiten Sie mit zwei unterschiedlichen KDE-Plasma-Versionen. Stöpseln Sie das Home-Verzeichnis mit der Version aus Ubuntu 18.04 nun an den Rechner mit Ubuntu 21.04 an, dann findet Plasma die alten Konfigurationsdateien und konvertiert sie entsprechend. Der Rückweg ist dann allerdings versperrt: Die Plasma-Version auf Ubuntu 18.04 kann mit der neuen Konfiguration nichts anfangen und legt im schlechtesten Fall eine komplett neue an. Noch offensichtlicher fallen die Probleme aus, wenn Sie auf den Rechnern unterschiedliche Desktop-Systeme oder gar verschiedene Distributionen einsetzen. Das Home-Verzeichnis von OpenSuse Leap wird kaum mit Pi OS harmonieren, wie es auf einem RasPi zum Einsatz kommt.

Wollen Sie entsprechende Kompatibilitätsprobleme vermeiden, müssen Sie händisch dafür sorgen, dass die jeweiligen Dateien gar nicht erst im Home-Verzeichnis landen. Das hat den unschönen Nebeneffekt, dass Sie dann auf jedem System, an dem Sie sich anmelden, erst wieder den eigenen Desktop konfigurieren müssen. Am besten beschränken Sie sich darauf, das geteilte Home-Verzeichnis nur auf Systemen zu nutzen, die im weitesten Sinn miteinander kompatibel sind. (jcb/jlu)