Passwörter sind eine unsichere Angelegenheit. Deshalb gab es in den vergangenen Jahren viele Versuche, Passwörter zu ersetzen oder sicherer zu machen. Einer dieser Versuche, ist der Ansatz mit einem physischen zweiten Faktor zu arbeiten. Dank systemd lässt sich das nun einfacher denn je für Linux Verschlüsselung nutzen.
Die Erkenntnis, dass Passwörter unsicher sind, gehört inzwischen zum Standardsatz, mit dem man jeden Artikel dazu einleiten muss. Firmen arbeiten deshalb mit biometrischen Verfahren und vielen anderen Ansätzen. Ich persönlich schätze meinen YubiKey sehr, aber leider unterstützen den noch viel zu wenige Dienste.
Dank der tollen Entwickler im systemd-Umfeld, die stetig daran arbeiten, neue Funktionen für Linux zur Verfügung zu stellen, kann man nun aber einen FIDO-Stick wie YubiKey (Alternativen wie Nitrokey gehen natürlich auch) sehr einfach nutzen, um vollständig mit LUKS verschlüsselte Linux-Systeme zu sichern. Das geht für Arch Linux und Debian schon länger, war aber ein ziemliches „gefrickel“ und ist ein tolles Beispiel dafür, wie systemd Sachen einfach besser umsetzt und auf solidere Füße stellt. Die Funktionsweise ähnelt der Entsperrung von LUKS-gesicherten Systemen mittels TPM.
Einrichtung
Im Folgenden zeige ich die Einrichtung unter openSUSE. Sie funktioniert für openSUSE Tumbleweed und Leap 15.4. Das Verfahren dürfte aber für jede Distribution funktionieren, die systemd nutzt und keine Sonderlocken verfolgt. Arch Linux hat sie kürzlich in archinstall integriert.
Die Voraussetzung ist aktuell ein Partitionslayout mit einem vollständig verschlüsselten LUKS-System (egal, ob Root-Partition und Home-Partition getrennt sind) und eine unverschlüsselte Boot-Partiton. Der LUKS-Container muss dem LUKS2-Standard folgen. Bestehende SUSE-Installationen müssen daher erst auf LUKS2 konvertiert werden. Neue Installationen können mit der Startoption YAST_LUKS2_AVAILABLE=1 direkt als LUKS2 angelegt werden.
Nach der Umsetzung der Anleitung benötigt man für jeden Systemstart den eingesteckten YubiKey. Es gibt keinen automatischen Fallback-Mechanismus.
Zuerst ist ein Paket nachzuinstallieren. Je nach Setup ist es möglicherweise schon installiert (z. B. als Abhängigkeit von KeePassXC).
# zypper install libfido2-1Code-Sprache: PHP (php)Nun steckt man den YubiKey ein. Mit folgendem Befehl führt man die Integration des YubiKey als Schlüssel für LUKS aus.
# systemd-cryptenroll --fido2-device=auto /dev/<LUKS-DEVICE>Code-Sprache: HTML, XML (xml)Das Laufwerk ist natürlich anzupassen. In der Regel muss man mit dem bisherigen LUKS-Passwort bestätigen. Der YubiKey wird dann in den nächsten freien Key-Slot geschrieben.
Anschließend ist noch die /etc/crypttab zu bearbeiten und fido2-device=auto am Ende zu ergänzen. Das Ergebnis sieht dann in etwa wie folgt aus:
cr-auto-1 /dev/<LUKS-Device> none x-initrd.attach,fido2-device=autoCode-Sprache: HTML, XML (xml)Nun noch mittels dracut den initramfs neu erstellen.
# dracut -fCode-Sprache: PHP (php)Bei einem Neustart wartet das System nun auf die Betätigung des YubiKey. Mangels Implementierung in Plymouth gibt es keinen grafischen Hinweis dazu auf dem Bildschirm, aber der YubiKey blinkt und zeigt dadurch an, dass eine Interaktion notwendig ist.
Sitze jetzt seit einer Woche immer wieder vor dem Artikel und überlege, ob ich mich traue. Da ich mehrere Sticks habe, würde ich alle einrichten,
Ich muss auch noch mal schauen, wie ich die zweite Festplatte für /home verschlüsselt habe. Die wird durch das Login entschlüsselt. Vielleicht stelle ich die dann mit um.
Ich kann für openSUSE nichts schlechtes berichten. Für andere Distributionen verbürge ich mich natürlich nicht. Zwar müsste systemd überall identisch sein, aber weiß schon, was manche Distributionen da verbastelt haben.
Ob und wie das für eine separate Festplatte für /home außerhalb von LVM funktioniert, kann ich nicht sagen. So ein Setup habe ich nicht zum testen.
Moin Gerrit, danke für die Informationen! Eine Aussage ist mir jedoch nicht ganz klar.
„““
Nach der Umsetzung der Anleitung benötigt man für jeden Systemstart den eingesteckten YubiKey. Es gibt keinen automatischen Fallback-Mechanismus.
„““
Der vorher schon existierende Key bleibt doch erstmal erhalten, oder? Also wieso genau kann ich das System dann damit nicht mehr entsperren?
Viele Grüße
Das System ruft diesen Key aber standardmäßig nicht ab, wenn kein YubiKey vorhanden ist.