[Gelöst] Verschlüsselter Fileserver und weitere Platten

[rhHeini]

Passt wohl besser hierhin:

http://debianforum.de/forum/viewtopic.php?f=27&t=111176

Mfg rh

[rhHeini]

So, habe mal insserv drüber laufen lassen, hat nichts geholfen.

Mfg rh
____________________________

Update 4.6.09:
Wenn ich mich nicht irre liegt das Problem darin begraben dass der USB-Stick erst nach allen Platten attached wird, und damit um so später je mehr Platten dran hängen. Damit kann das Skript dass root entschlüsselt mit vielen Platten den Key nicht finden.

Ich hab mich mal über http://debianforum.de/forum/viewtopic.php?f=33&t=110745 nach http://wiki.debian.org/BootProcessSpeedup und von da nach https://www.debian-administration.org/articles/629 durchgehangelt. Laut meiner rcS.d wird erst udev, dann das usbfs gestartet.

Code: Alles auswählen

.....
lrwxrwxrwx  1 root root   14  1. Jun 23:00 S04udev -> ../init.d/udev
lrwxrwxrwx  1 root root   26  1. Jun 23:00 S05mountdevsubfs.sh -> ../init.d/mountdevsubfs.sh
......

Bringt es was die umzudrehen? Geht das überhaupt? Wenn ja, wie genau muss ich da vorgehen. Wäre meine erste Aktion in dem Directory.

Mfg rh

[rhHeini]

... und ich hab gerade insserv wieder runtergeschmissen.

Hat den Server so optimiert dass die fix vergebene IP weg war und ich über Netz nicht mehr ran kam. Hat vom Timing eh nix gebracht.

Beim Restore der Funktionalität hat mir wieder mal ein Thread aus dem Forum/Grundsatzfragen geholfen.

Trotzdem: hat keiner Tips wie ich Lenny dazu kriege einen USB-Stick gleich zu Anfang einzuhängen, so dass root trotz vieler Platten rechtzeitig entschlüsselt werden kann?.

Mfg rh

[schwedenmann]

Hallo

Möglicherweise hilft dir dieser Textausschnitt weiter

Wie normale Partitionen mit einem Schlüssel auf einem USB-Stick automatisch entsperrt werden können wurde oben schon erklärt. Um das bei der Root-Partition zu ermöglichen sind leider einige weitere Eingriffe möglich. So muss man sicherstellen daß die initrd die nötigen Treiber für den USB-Stick enthält. Außerdem funktioniert das automatische Mounten des Sticks über CRYPTDISKS_MOUNT und die fstab nicht, da die dazu nötigen Informationen in der initrd nicht vorhanden sind.

Es gibt aber eine Alternative. In der crypttab kann man der Partition ein Keyscript zuweisen, welches den Schlüssel besorgt und ihn ausgibt. Dieses Skript wird, sofern es in der crypttab eingetragen ist, automatisch in die initrd übernommen. Es muss alle zum Erlangen des Schlüssels notwendigen Schritte übernehmen, das beinhaltet das Laden der Treiber für den USB-Stick, das Anlegen eines Mountpunktes, das Mounten, die Ausgabe des Schlüssels und das Aushängen des USB-Sticks. Das Skript wird im laufenden Betrieb außer in der initrd nicht benötigt und kann zum Beispiel in /root angelegt werden. Meines sieht folgendermaßen aus:

#!/bin/sh
modprobe usb-storage 1>&2 #Kernelmodul für den USB-Stick laden
sleep 5 #5 Sekunden warten damit der Stick bereit ist
mkdir /usb 1>&2 #Mountpunkt anlegen
mount -t vfat -o ro,umask=077 /dev/sda1 /usb 1>&2 #Stick mounten
cat /usb/key #Schlüssel ausgeben
umount /usb 1>&2 #USB-Stick aushängen

Da cryptsetup den Schlüssel in der Standardausgabe des Skriptes erwartet, wird die Ausgabe aller anderen Programmaufrufe im Skript in die Fehlerausgabe umgelenkt (1>&2).

Außerdem muss noch sichergestellt werden, daß die initrd alle nötigen Treiber enthält. update-initramfs fügt automatisch die Module für USB-Speicher hinzu. Die Module für das auf vielen USB-Sticks verwendete FAT-Dateisystem muss man aber ausdrücklich anfordern. Dazu werden in der Datei /etc/initramfs-tools/modules folgende Zeilen hinzugefügt:

nls_cp437
nls_iso8859_1
vfat

Als vorletztes muss nun die crypttab angepasst werden:

# <target name> <source device> <key file> <options>
hda3_crypt /dev/hda3 none luks,keyscript=/root/keyscript

Nun wird eine Kopie der alten initrd in /boot erstellt. Diese wird als Ersatz benötigt falls das Entsperren der Root-Partition nicht klappt. Dann kann nämlich das System nicht hochgefahren werden. Startet man neu und verlangt von grub, statt der neuen die alte initrd zu verwenden, kann man die Root-Partition wieder mit dem Passwort entsperren und nach dem Hochfahren den Fehler beheben. Das geht wesentlich schneller als die Benutzung einer Live-CD für diesen Zweck. Als letztes wird dann eine neue initrd erstellt:

sirius:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.18-4-k7

Nach einem Neustart wird cryptsetup nun versuchen, den Schlüssel vom USB-Stick einzulesen und damit die Root-Partition zu entsperren. Nachdem das erfolgt ist wird von der initrd zur Root-Partition gewechselt und das System wie gewohnt hochgefahren.

Quelle
http://www.andreas-janssen.de/cryptodisk.html


mfg
sachwedenmann

[rhHeini]

Danke, mehr oder weniger nach dem Papier hab ich den Server aufgesetzt, erst nur mit der Bootplatte. Da hat das astrein gefunzt.

Die ersten beiden zusätzlichen Platten reinhängen ging noch gut, ich musste nur den rootdelay-Parameter etwas vergrössern. Die Entschlüsselung hat nur gelegentlich mit 3 Platten nicht getan, das Timing scheint generel ein wenig zu schwanken.

Ab der vierten Plate geht aber nichts mehr, auch nicht mit 60s rootdelay. Das Problem scheint damit zusammenzuhängen dass der USB-Stick immer als letztes Device attached wird, die initrd scheint aber das Skript schon vorher zu starten, so dass bei fehlendem Stick keine Entschlüsselung mehr stattfindet.

Code: Alles auswählen

    .....
    lrwxrwxrwx  1 root root   14  1. Jun 23:00 S04udev -> ../init.d/udev
    lrwxrwxrwx  1 root root   26  1. Jun 23:00 S05mountdevsubfs.sh -> ../init.d/mountdevsubfs.sh
    ......

Bringt es was die umzudrehen? Geht das überhaupt? Wenn ja, wie genau muss ich da vorgehen. Wäre meine erste Aktion in dem Directory.

Hab die beiden mal umgedreht, und nach einigen Umwegen wieder alles zurückgedreht, bringt nichts ausser Nebeneffekten. Z.B. war das devpts weg, konnte mich über PuTTy nicht mehr einloggen (Server refused to allocate pty).

Hab halt weiter gesucht und bin auf udev gekommen. Die Schlüsselfrage ist jetzt wohl: kriege ich udev irgendwie dazu gleich nach dem Bootdevice den USB-Stick einzuhängen? Die Skripts in /etc/udev hab ich mir schon angesehen, hab aber keine Idee wo ich da was tun kann.

Mfg rh

[rhHeini]

Auauaua, totales Eigentor geschossen, !

Hatte zuletzt als 4te Platte immer eine SATA an einem Promise Sata300TX2 rangeklemmt. Im Bios kommt der Controller immer schön an 2ter Stelle nach dem SCSI-Raidcontroller.

Jetzt hab ich gemerkt dass die SATA-Platte vom Kernel immer als erste eingehängt wird, und nicht hinter der Bootplatte einsortiert wird. Damit kann der Rechner das root nicht mehr finden.

Grub bootet in beiden Fällen wunderbar von hd0,0, aber nach umstellen von fstab und crypttab von SDA auf uuid geht im Moment auch mal gar nichts wie gehofft, lande wieder in der busybox. Jetzt brauch ich mal ne Pause zum Nachdenken.
Hab ich jetzt das in "Setting up an encrypted Debian system" http://madduck.net/docs/cryptdisk/ beschriebene Problem? Heute abend geh ich da nicht mehr ran.

Mfg rh

[whisper]

Sorry, leicht off topic, aber ich wüsste gerne, warum man seinen Fileserver mit Key verschlüsselt.
Wenn der Server gestohlen wird, wird der Dieb nicht auch den Key mitnehmen, ist eine Passphrase da nicht sicherer?

[Danielx]

Wenn der Server gestohlen wird, wird der Dieb nicht auch den Key mitnehmen

Den USB-Stick entfernt man natürlich sofort nach dem Booten bzw. Entschlüsseln wieder vom Rechner.

Gruß,
Daniel

[rhHeini]

Muss wohl noch was mit den uuid's vermurkst haben. Nach einem kompletten systematischen Neuaufsetzen schnurrt die Mühle jetzt wunderbar.

Mfg rh