cryptsetup-luks und Passwortabfragen beim booten

[jsbx]

Hallo,
vor kurzem habe ich mein neu installiertes System verschlüsselt, wie hier [1] beschrieben.
Was ich allerdings nicht wollte, war die keyfile-Variante, die das hochfahren nur mit eingestecktem usb-Stick ermöglichen sollte.

Ich habe die Partitionen /var /tmp /home /daten und swap gesondert verschlüsselt - und muss nun beim booten also 5 Passwörter eingeben. Nicht sehr praktikabel das Ganze.

Um dies zu umgehen, versuchte ich ein initrd-skript zu installieren, und folgte der Anleitung hier [2] mit dem kleinen Zusatz hier [3], der das einmal eingegebene Passwort per echo-Befehl an die weiteren verschlüsselten Partitionen übergeben sollte.
Bei dieser Methode allerdings ging die Passwort-Abfrage immer schief - ich denke mal, dass das an der zu diesem Startzeitpunkt noch falsch geladenen keymap lag, und er meine Sonderzeichen nicht wie gewollt interpretiert hat. Leider war es mir aus irgendwelchen Gründen auch nicht möglich, eine andere keymap zu laden...

Keyfiles habe ich auch generiert, die liegen nun auf der ersten verschlüsselten Partition, /var - aber darauf greift er beim booten ja nicht zu - da die zur Zeit der Passwortabfragen noch verschlüsselt ist. Die Keyfiles auf einer unverschlüsselten Partition abzulegen machte ja irgendwie keinen Sinn. Ich weiss nur nicht, wie ich erst /var komplett einbinde, damit dann die keys benutzt werden können.

Meine Frage also: Hat jemand eine kleine einfache Anleitung parat, mit der ich die verschiedenen Partitionen auch mit einer Passworteingabe beim Bootvorgang einbinden kann? Oder auch einfach nur eine andere Keymap laden kann - das Skript schien mir nämlich recht einleuchtend zu sein.
Im Netz finde ich immer nur die usb-Variante, und in einer Mailingliste wurde mir nur geantwortet: Ja, das geht. Aber wie?

Gestern habe ich was zu boot.cryptmap [4] gefunden - denke aber mal, dass dieses Suse -Skript einige Änderungen benötigt, um auch unter Debian zu laufen?

Ich benutze gerade Debian etch mit 2.6.16-2-amd64-k8 Kernel und
cryptsetup-luks 1.0.4-rc2

[1] http://www.debian-administration.org/articles/428
[2] https://help.ubuntu.com/community/EncryptedFilesystem
[3] http://ubuntuforums.org/showthread.php?t=199824&page=3
[4] http://linuxinfoserver.de/forums/showthread.php?p=1315692

[dvd666]

ich habe letztens gelesen, dass man bei der erstellung eines passwortes (weis den befahl nicht mehr genau) auch einfach eine beliebige datei angeben kann. wenn du das so machst, kannst du sicherlich auch einfacher deinen stick benutzen, ohne echo und pipes etc.

[jsbx]

naja, das Problem ist ja gerade, dass ich eben keinen usb-stick benutzen möchte... Ich habe einfach nur 5 Partitionen, die verschlüsselt sind - alle mit der gleichen Passphrase. Irgendwie würde ich gerne das Passwort nur ein einziges Mal eingeben müssen, statt 5 Mal...

Es bräuchte ein funktionierendes initrd-script o.ä. - ich habe leider bisher keines für Debian gefunden... Dabei muss es - denke ich - doch Menschen mit ähnlicher Konfiguration geben?!

Dankbar für alle Tips:
jsbx.

[dvd666]

wahrscheinlich sind es auch andere festplatten, oder?
sonst koenntest du auch komplett /dev/hda verschluesseln anstatt /dev/hda1, 2, 3 etc.
hmm, oder? ich meine das muesste gehen, oder irre ich mich da?

bei mir wird die platte eingebunden wenn ich mich einlogge, das geht mit pam mount, denke da muesstest du mal nachlesen!
es gab da mal einen ct artikel, kannst dich nochmal melden wenn du genauere infos haben willst ;)

[minimike]

Hi

Ich habe mir eine Ramdisk gebastelt. Ich boote von Ramdisk in dem wie bei einer Initrd das System entschlüsselt wird. Vorher wird ein Raid1 mittels mdadm aktiviert, dann entschlüsselt und jetzt starte ich auf dem verschlüsselten Raid einen LVM. Auf dem LVM ist mein eigendliches System für / und weitere Dateisystem für /usr und Co. Wenn man vergrössern oder verkleinern will braucht man nicht Partitionieren und das geht sogar mit ext3 live. Ich habe es nicht probiert da ich anfangs alles mit reiserfs eingerichtet hatte aber man kann mit ext2/3 ohne zweites System oder grosser Fummelei seine Dateisysteme während des Betriebes vergrössern oder verkleinern. Mittlerweile habe ich aber alles auf ext3 umgestellt weil mich reiserfs nicht überzeugen konnte. Nachteil um alle Vorteile von LVM zu nutzen bleiben als Dateisysteme eigendlich nur ext2/3, reiser4 oder reiserfs zur Auswahl. XFS lässt sich nur Vergrössern aber nicht wieder verkleinern. zu JFS habe ich nichts gefunden und reiser4 ist noch nicht fertig im Kernel.
Weitere verschlüsselte LVM's starte ich dann per Initscript vom verschlüsselten System aus. Der Bequemlichkeit halber mit Keyfiles damit man kein Passwort eintippen muss

Das hatte mir beim basteln ungemein geholfen denn das lieferte mir die Denkansätze wie ich sowas realisieren könnte
http://tuxmobil.de/samsung_x20_linux_lvm_encryption.html

https://knecht.homelinux.net/phpBB2/viewtopic.php?t=697

Übrigens man kann in die Ramdisk auch Treibermodule ablegen und mit insmod ( in der linuxrc ) automatisiert laden. Somit ist ein eigens erstellter Kernel "Zeitverschwendung"

[d1keue]

Hallo,

habe mit dem boot.cryptmap - Script sehr gute Erfahrungen gemacht. Sehr wichtig ist bei dieser Verschlüsselungs Geschichte auch, daß beim Shutdown die entsprechenden eingebundenen Loop-Devices (Verschlüsselte Container) und Device-Mapper Partitionen auch wieder korrekt 'unmounted' werden. Diese Vorgänge werden über eine Crypttab-Datei gesteuert.
Ich habe auf meinem System zwei Partitionen und zwei Container verschlüsselt.
Das Password-Problem in der initial Bootphase (Falsche Keyboard Map) kann man auch umgehen, wenn für die verschlüsselung zwei Passwörter verwendet werden (Z statt Y bzw. umgekehrt)

D.h. Deine Link
http://linuxinfoserver.de/forums/showthread.php?p=1315692
ist eine gute Wahl, wenn Dein System das 'init.d'-Konzept verwendet.

Gruss ..

[jsbx]

D.h. Deine Link
http://linuxinfoserver.de/forums/showthread.php?p=1315692
ist eine gute Wahl, wenn Dein System das 'init.d'-Konzept verwendet.
Gruss ..

Muss ich das aber nicht für Debian umschreiben?
Das auf der Seite erwähnte boot.localfs bspw. gibt es bei mir nicht - und leider habe ich auch keine Ahnung, welche Datei bei mir das Äquivalent dazu sein soll... /etc/init.d/mountall.sh evtl....?

jsbx.

[jsbx]

wahrscheinlich sind es auch andere festplatten, oder?
sonst koenntest du auch komplett /dev/hda verschluesseln anstatt /dev/hda1, 2, 3 etc.
hmm, oder? ich meine das muesste gehen, oder irre ich mich da?


es sind 2 Platten, ja. Allerdings sind die verschlpüsselten Partitionen /home /var und /tmp auf einer Platte... Das Wurzelverzeichnis und /boot sind hier nicht verschlüsselt...

[d1keue]

Muss ich das aber nicht für Debian umschreiben?
Das auf der Seite erwähnte boot.localfs bspw. gibt es bei mir nicht - und leider habe ich auch keine Ahnung, welche Datei bei mir das Äquivalent dazu sein soll... /etc/init.d/mountall.sh evtl....?

jsbx.
Hallo,
Leider kann ich Dir bei Debian nicht helfen. Grundsätzlich sollte aber ein dem 'boot.localfs'-Script entsprechendes Script zu finden sein. Ich bin aber der Meinung, daß das mitgelieferte Script 'install.sh' alle Checks und Einstellungen automatisch (nach Abfrage) durchführt.
Zitat:


.... Das Skript kann in den Bootprozess integriert werden, indem es in das Verzeichnis /etc/init.d kopiert wird. Um zu funktionieren, müssen lediglich zwei kleine Anpassungen an dem Skript, welches die lokalen Dateisysteme mountet, vorgenommen werden (s. u.). Das mitgelieferte Shell-Script „install.sh“ kann diese (und alle anderen) Installationsschritte automatisch durchführen.


Vieleicht solltest Du das Script einfach mal starten und anhand der Meldungen entscheiden, ob noch weitere Forschungen nötig werden ;).

Falls Fehlermeldungen kommen, bitte posten ..

Gruß
Dieter

[jsbx]

Hallo,
Vieleicht solltest Du das Script einfach mal starten und anhand der Meldungen entscheiden, ob noch weitere Forschungen nötig werden ;).


OK, hatte mich das bisher nicht so ohne weiteres getraut ;)
Und wie ich befürchtet hatte:



Error: The boot script boot.localfs was not found on your system.
This is critical because boot.cryptmap should be initiated before mounting
local file systems and this dependency is assumed to be set in this file.


Failed: Some requirements for configuring the system are not fulfilled.
You can still try to install manually.

Exiting due to error.

Vielleicht muss ich mich doch nach einer komplizierteren Variante umsehen... und mal obige Ramdisk-Vorschläge durchprobieren

[jsbx]

Für alle, die ein ähnliches Problem haben, hier meine kleine Lösung:

Wie oben beschrieben, habe ich /var /tmp /home /daten und swap auf jeweils einer eigenen verschlüsselten Partition, und musste also während des bootens fünf Passwörter eingeben...

Um das zu verhindern, generierte ich für alle Partitionen ausser /var ein keyfile:

root@wanted:~# head -c 2880 /dev/urandom | uuencode -m - | head -n 65 | tail -n 64 > /var/cryptkeys/home.key
root@wanted:~# cryptsetup luksAddKey /dev/hda7 /var/cryptkeys/home.key

Dann die /etc/crypttab angepasst:


var /dev/hda5 none luks
tmp /dev/hda6 /var/cryptkeys/tmp.key luks
home /dev/hda7 /var/cryptkeys/home.key luks
daten /dev/hda8 /var/cryptkeys/daten.key luks
swap /dev/hdb5 /var/cryptkeys/swap.key luks


anschliessend in /etc/fstab den mapper Eintrag für /var rausgenommen:


#/dev/mapper/var /var ext3 defaults 0 2
/dev/mapper/swap none swap sw 0 0
/dev/mapper/tmp /tmp ext3 defaults 0 2
/dev/mapper/home /home ext3 defaults 0 2
/dev/mapper/daten /daten ext3 defaults 0 2


dann ein skript (encrypt-luks) in /etc/init.d/ abgelegt:


#!/bin/bash
echo "Mounting encrypted partition /var..."
/sbin/cryptsetup luksOpen /dev/hda5 var
mount /dev/mapper/var /var


und einen symbolischen Link in /etc/rcS.d/ angelegt:

lrwxrwxrwx 1 root root S26encrypt-luks -> /etc/init.d/encrypt-luks

Und schon wird nach Neustart einmal für /var das Passwort abgefragt, und die anderen Partitionen werden durch Benutzung der keyfiles unter /var/cryptkeys gemountet.

Viel Spass damit wünscht
jsbx.

[dvd666]

hehe, auch eine methode ;)