Nach LAAAANGER Zeit mal wieder etwas von mir. Ich bin immer noch auf Debian unterwegs
Ich bin auf ein Problem bei der Erstellung von intramfs gestoßen.
Ich versuche mich inzwischen mit Proxmox, welches auf Debian Bookworm aufbaut. Und weil ich Proxmox hauptsächlich für eine lokale Nextcloud betreiben möchte, hätte ich gerne das darunterliegende Dateisystem bzw. die ganze Partition mit cryptsetup/LUKS verschlüsselt.
Das ganze soll aber eine Headless Kiste werden (kleines NAS aus einem Zimablade) also weder Monitor noch Tastatur dran... und im Keller, wegen des Lärms der sich drehenden Platten, wohnen.
Damit man seine Partitionen mit LUKS verschlüsseln kann, muss ja eine Tastatur und Bildschirm haben... damit man das Passwort eingeben kann. ODER man baut in die initramfs einen kleinen ssh-Server (dropbear) ein, auf den man sich zur Eingabe des Passwortes per ssh-client verbindet. ODER man verwendet tang/clive.
Also hab ich mit mit der Dropbear-Geschichte auseinandergesetzt und festgestellt, dass das auf einem puren Debian Bookworm ausgezeichnet klappt.
In dieser Anleitung ist alles drin, was man dazu braucht
https://www.cyberciti.biz/security/how- ... -in-linux/
Auf einer Installation mit dem Proxmox-Iso klappt das aber nicht. Es gibt nur "no route to host", wenn ich mich im LAN auf die Kiste beim Booten zu dropbear verbinden möchte. Shice. Warum?
Also wurde ich im Proxmox-Forum auf tang/clive hingewiesen.
Das ist auch eine tolle Sache, die man hier sowohl lesen als auch eine Demo samt Einrichtung in einem Video (alles auf Englisch) studieren kann
https://www.ogselfhosting.com/index.php ... an-server/
kurz zusammengefasst:
man hat am besten mehrere (mindestens zwei) Tang-Server. Einen im LAN, einen irgendwo Remote übers Internet verfügbar. Tang macht nix anderes als einen JWT auszuspucken. Fertig. Ein systemd-socket hört auf einem zu konfigurierenden Port, und wenn man dann
Code: Alles auswählen
curl http://tang-server/advClive hingegen sitzt am Client der die Verschlüsselte Platte entschlüsseln muss.
Man hat eine Verschlüsselte Platte samt Passwort dazu. Dann kann man clive anweisen, dass es von einem oder mehreren Tang-Servern einen Token abholt (man kann auch sagen, dass 3 von 5 Tang-servern erreichbar sein müssen, oder alle) daraus eine Passphrase zusammenbaut und diese dann LUKS in einem Slot hinterlegt.
Will man die Platte nun aufsperren, so reicht ein Mountbefehl und über die fstab und crypttab springt clive an, holt sich die geforderte Anzahl weiterer Token der Tang-Server, rekonstruiert das cryptsetup-Passwort und schließt die Platte automatisch auf. Ich muss keines eintippen.
Hat man einen Tang-Server zu hause und einen z.b. beim Hetzner public verfügbar, dann kann das NAS (oder der Laptop) ohne weitere Eingabe des LUKS-Passwortes starten und die Platte entschlüsseln.
Stiehl jetzt jemand den Laptop, oder entwendet das NAS, so ist zwar der öffentliche TANG-Server beim Booten erreichbar, der aus dem LAN aber nicht... die Platte wird nicht automatisch aufgesperrt.
Bin ich mit meinem Laptop irgendwo unterwegs, so muss ich das Passwort eintippen beim Booten... So what. Mache ich bisher ja auch.
Aber jetzt kommts.
Ich hab sowohl Dropbear als erstes manuell eingerichtet und konnte mittels SSH-Zugriff während des Bootvorganges die Platte aufsperren. Der Bootvorgang setzte fort danach.
Mit Proxmox ging das aber nicht, wie schon oben beschrieben.
Tang/clive klappte mit Proxmox, wenn ich nur den öffentlich erreichbaren Server konfiguriert hatte... aber den lokalen tang-server konnte ich nicht erreichen...
Und so stieß ich auf das zugrundeliegende Problem.
Für Clive rät der Autor im oben verlinkten selfhosting-Beitrag einen Fix für Debian 11+12 als Hook in die erstellung der Initramfs einzubauen der den nameserver 1.1.1.1 in die /etc/resolv.conf der initramfs einträgt.
Das hab ich ohne weiter darüber nachzudenken eingebaut.
Aber das führte im Endeffekt dazu, dass ich zwar den Remote Tang-Server aus der initram fand, den lokalen aber nicht. (Hat LANG gedauert, bis ich das debugged habe).
Das Zugrundeliegende Problem ist, dass die initramfs-tools keinerlei Nameserver Informationen verarbeiten. Es wird das/die Interface mit IP, Gateway, Netmask konfiguriert. Es wird sogar ein allfälliger Nameserver in der Ausgabe am Prompt angezeigt... aber es wird keine /etc/resolv.conf erzeugt. Damit gibts keine Namensauflösung.
In beiden oben verlinkten Anleitungen wird dazu geraten, eine fixe IP-Adresse über einen IP= Eintrag in /etc/initramfs-tools/initramfs.config zu konfigurieren...
Die Syntax dieses Eintrags folgt exakt jener, die man auch grub bei der Kernel-Konfiguration mitgeben kann (nur IP ist im Gegensatz zur Grub-Zeile groß geschrieben).
Diese IP= Konfiguration kommt aus der NFS-Welt. Die braucht man, um ein NFS-Volume für das Homeverzeichnis z.B. mounten zu können.
Und man kann hier auch DNS-IP-Adressen konfigurieren. Aber die Debian initramfs-tools ignorieren diese Felder.
Man kann aber auch dhcp das ganze erledigen lassen. Das Interface wird zwar mit dem IPV4DNS0-Eintrag in /run/net-<nic>.conf angelegt, aber keine /etc/resolv.conf erzeugt.
Jetzt habe ich für meinen Anwendungsfall die Datei vi /usr/share/initramfs-tools/scripts/functions gepatched, damit sie mir die /etc/resolv.conf in der Initram anlegt, damit auch lokale tang-server auflösbar werden.
Den Eintrag aus dem curl-Hook zum setzen von 1.1.1.1 als nameserver in der initramfs vom obigen Link hab ich wieder entfernt.
Der Patch ist ganz einfach.
in scripts/functions die funktion "configure_networking" suchen und ganz am Ende, nachdem die /run/net-*.conf gesourced werden und vor der schließenden geschwungenen Klammer folgende 3 Zeilen einfügen:
Code: Alles auswählen
[ -n "${IPV4DNS0:-}" ] && echo "nameserver ${IPV4DNS0}" >> /etc/resolv.conf
[ -n "${IPV4DNS1:-}" ] && echo "nameserver ${IPV4DNS1}" >> /etc/resolv.conf
[ -n "${DNSDOMAIN:-}" ] && echo "search ${DNSDOMAIN}" >> /etc/resolv.confWas mich aber echt wundert... warum machen das die initramfs-tools von Debian nicht von Haus aus?
Dieser Hack muss bei jedem Update dann nämlich nachgezogen werden
Ich werd da wohl einen Bugreport bei Debian einwerfen...
lg Jakob