Sicher kannst du das selbe PW für alle verwenden.
Probier aber mal die bs=32 count=1 methode. Seitdem ich die jetzt habe kommt der oben erwähnte Fehler nicht meh - Wahrscheinlich war das keyfile einfach nur zu Groß.

Das hatte ich auch ausprobiert. Ich konnte die Platte ja auch von Hand über das Keyfile einhängen. Bloß halt automatisch beim Start mittels crypttab hat das irgendwie nicht funktioniert. Frag mich nicht wieso. Wenn es sicherheitstechnisch keinen Unterschied macht, dann werde ich jetzt als Übergangslösung einfach erstmal für die beiden Platten das gleiche Passwort verwenden. Dann muss ich mir mir wenigstens nur zwei Passwörter merken und drei beim Start eingeben.. Ist wohl immer noch die beste Lösung zur Zeit.
Falls hier noch jemand ne Idee hat, wäre ich über jede Anmerkung froh. Hab den Thread abonniert.

Jeldrik hat geschrieben:

Ich bin dem Fehler mal noch ein wenig auf die Schliche gekommen:
1. Ich meine beim Start (das geht echt alles sehr schnell und habe keinen Log von der Bildschirmausgabe gefunden…) erkannt zu haben, dass dort steht, er könne die key-files nicht finden.
2. Ich habe einmal die Partition von Hand mit dem key-file eingehängt und dort gab es keinerlei Probleme.

Hier nochmal meine Einträge in der crypttab:

home /dev/hda6 none luks,retry=1,cipher=aes-cbc-essiv:sha256
tmp /dev/hda7 /home/keys/tmp.key luks,cipher=aes-cbc-essiv:sha256
var /dev/hda8 /home/keys/var.key luks,cipher=aes-cbc-essiv:sha256

ähm, fehlt da zwischen home und keys nicht dein benutzername? oder hast du in /home ein extra verzeichnis keys angelegt?

wie man schon sagte, beim Sysstemstart die Partition wo Schlüßel ligt wurde noch nicht gemountet.
Ich habe die Daten-Patition und brauche nicht gleich beim start haben. Das kann man als boot-skript mit priorität 99 in V-boot eintragen.

Was ich gemacht habe mit meinem /tmp: Ich habe einfach ein tmpfs im Ram erstellt, das immer nur so groß ist wir tmp gerade braucht.
Vorteil: ist schnell, im Ram brauchts kaum Platz, und nach dem Runterfahren ist garantiert gelöscht, im Betriebszustand ist auch auf jedes verschlüsselte Laufwerk ein Zugriff drauf möglich, keine Passworteingabe notwendig.
Nachteil: ???
Man könnte evtl auch noch /var/tmp in /tmp reinmounten.
Nur so mal zum überlegen…

sicherlich ist auch eine Lösung. Braucht man dafür grosse RAM. Wenn man z.B. unter Gnome mit GUI grosse(1024MB) .gz-file anschauen will? Und dein RAM 1 GB. ist.
So viel ich weiss, wird die Daten in tmp entpackt, oder?

Ist mir noch nicht passiert.
Habe 1GB RAM drin, tmpfs, darf max 50% davon haben. Über 1 MB hab ich noch nicht in /tmp gesehen. Wie das beim entpacken läuft kann ich dir aber nicht sagen.

hallo,

ich habe eine verschlüsselte home-partition und wollte jetzt gerne noch das stammverzeichnis nachträglich verschlüsseln. beim vorgehen wie im wiki beschrieben kam der fehler

Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sda3 contains at least 258 sectors.
Failed to write to key storage.

bei dem verschlüsselungsschritt.

gleiche anzeige bei sudo cryptsetup -c aes-lrw-benbi -y -s 384 luksFormat /dev/sda3

habe vorher eigentlich alle relevanten module geladen.
woran könnte es noch liegen?

la_cuba hat geschrieben:

hallo,

ich habe eine verschlüsselte home-partition und wollte jetzt gerne noch das stammverzeichnis nachträglich verschlüsseln. beim vorgehen wie im wiki beschrieben kam der fehler

Failed to setup dm-crypt key mapping.
Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/sda3 contains at least 258 sectors.
Failed to write to key storage.

bei dem verschlüsselungsschritt.

gleiche anzeige bei sudo cryptsetup -c aes-lrw-benbi -y -s 384 luksFormat /dev/sda3

habe vorher eigentlich alle relevanten module geladen.
woran könnte es noch liegen?

hatte ich auch gleiche Fehler.
seitdem ich in /etc/modules
…
aes
sha256
..
eingetragen, läuf stabil.
Wenn du key-file benuzt, würde ich die Größe erhöhen.
Meine Meinung nach aes-cbc-essiv ist besser(stabiler) als aes-lrw-benbi .