Arch Linux

Dateien beim Boot von entschluesselter Partition nicht lesbar

IndoctriNation

Hallo Forum!

Ich bin vor drei Tagen von openSUSE auf Arch umgestiegen. Ich habe ohne Ahnung von Kofigurationsdateien angefangen und mittlerweile habe ich das System wegen der genialen Wiki schon einigermassen im Griff 🙂
Obwohl es bei der xorg.conf noch ein bisschen happert, wie man sieht.

Ich habe meine /home, /tmp und swap verschluesselt, um eine Balance zwischen Leistung und Sicherheit herzustellen. / ist nicht verschluesselt.
Ich wuerde nun gerne /tmp ueber einen Keyfile entschluesseln lassen, welchen ich in /home/foo/keyfile gespeichert habe. /home entschluessele ich ueber meine Passphrase.

Ich habe mit "crypsetup luksAddKey" einen Key hinzugefuegt, welcher durchaus funktioniert.

$cryptsetup luksOpen --key-file /home/foo/keyfile /dev/sdb4 tmp
$key slot 1 unlocked.

ich trage nun folgendes in meine crypptab ein:

# NAME SOURCE DEVICE PASSWORD OPTIONS
home /dev/disk/by-uuid/cebf42e1-c0db-42f5-b580-750ae1686a08 ASK
tmp /dev/disk/by-uuid/ef4c6718-2877-4789-a067-cd18a8c7f6f8 /home/foo/keyfile
swap /dev/sdb3 SWAP -c aes-xts-plain -h whirlpool -s 512

und versuche zu booten. hierbei erscheint folgende fehlermeldung:

ok tmp..Command failed:Error opening key file:No such file or directory
failed swap..creating swapspace..ok

..und ich werde gebeten, das root-passwort fuer eine Rettungsshell einzugeben, um dann nach einem remount von / meine crypttab wieder zurueckzusetzen. steht statt dem keyfile bei tmp "ASK", geht wieder alles wie gewohnt.
Da /home im crypptab als erstes steht, sollte es auch zuerst gemountet sein. Ich verstehe nicht, weshalb die Datei fuer dm-crypt nicht lesbar zu sein scheint.

Hier meine Hooks in mkinitcpio.conf:

HOOKS="base udev autodetect pata sata keymap encrypt filesystems"

Sonst habe ich nichts eingetragen.

Ich wuerde mich sehr freuen, wenn mir jemand helfen koennte. Sonst muesste ich auf ein deutlich kuerzeres Passwort umsteigen, was ich ungern tun wuerde.
Google und FoSu habe ich in Deutscher wie in Englischer Sprache bemueht, leider ohne Ergebnis.

Viele Gruesse,
IndoctriNation

PS.: Ich habe mich bei der konfiguration meines Systems im allgemeinen an
http://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt
gehalten.

Weltio

Hast du eine PS/2-Tasteratur?
Geht es, wenn du temporär ein Keyfile für Home erstellst, es gangbar (sprich zum Schlüssel) machst und auf dieses in der crypttab verweist?

IndoctriNation

Weltio schrieb Hast du eine PS/2-Tasteratur?
Geht es, wenn du temporär ein Keyfile für Home erstellst, es gangbar (sprich zum Schlüssel) machst und auf dieses in der crypttab verweist?

Nein, sie hängt am USB.

Ich habe es gerade ausprobiert. Ich habe unter /crypto/keyfile, also im unverschlüsselten root, die keyfile gespeichert. DM-Crypt kann diese lesen und /home wird entschlüsselt.
Denk Keyfile für /tmp habe ich wieder unter /home gespeichert, dieser wird aber mit der gleichen Fehlermeldung, er wäre nicht auffindbar, zurückgewiesen.

bort

IndoctriNation schrieb Nein, sie hängt am USB.

Dann sollte bei dir ein usbinput oder usb in der HOOKS zeile deiner /etc/mkinitcpio.conf stehen. Und dort noch vor encrypt.
Hoffe das hilft dir.

Hier noch ein bisschen Lesestoff. 😉
-bort

IndoctriNation

bort schrieb
Dann sollte bei dir ein usbinput oder usb in der HOOKS zeile deiner /etc/mkinitcpio.conf stehen. Und dort noch vor encrypt.

Danke für den aufmerksamen blick!
Die Tastatur funktionierte aber auch vorher. An meinem kleineren, zweiten Problem, das die deutsche keymap nämlich nicht geladen wird, hat sich auch nichts geändert.
Ich habe auch wieder versucht, in /etc/crypttab wieder einen keyfile auf /home für /tmp einzutragen, aber dies schlägt mit der gleichen Fehlermeldung fehl..

MfG

Weltio

IndoctriNation schrieb Denk Keyfile für /tmp habe ich wieder unter /home gespeichert, dieser wird aber mit der gleichen Fehlermeldung, er wäre nicht auffindbar, zurückgewiesen.

Was passiert, wenn beide Platten dasselbe Keyfile benutzen?

IndoctriNation

Weltio schrieb
IndoctriNation schrieb Denk Keyfile für /tmp habe ich wieder unter /home gespeichert, dieser wird aber mit der gleichen Fehlermeldung, er wäre nicht auffindbar, zurückgewiesen.

Was passiert, wenn beide Platten dasselbe Keyfile benutzen?

Habs gerade ausprobiert, das funktioniert. Dauert komischerweise ziemlich lang, funktioniert aber.
Die Datei lag auf /crypto, also auf der unverschlüsselten /-partition, und davon zu entschlüsseln macht keine probleme..

Weltio

Ich habe mal eine Frage:

If the field is not present or the password is set to none, the password has to be manually entered during system boot.

Wieso steht bei dir ASK? Woher hast du das?
Versuch das doch mal, anstelle des ASKs.

IndoctriNation

Weltio schrieb Wieso steht bei dir ASK? Woher hast du das?
Versuch das doch mal, anstelle des ASKs.

Bei mir steht in /etc/crypttab:

# Each PASSWORD field can be an absolute pathname to a key file (starting
# with a slash, recommended) or a literal string that will be used as
# a passphrase. To use special characters in the passphrase, surround it
# by quotes, the usual bash quoting rules apply.
# There are two special keywords that cannot be used as passphrases:
# - ASK ask for a passphrase on boot
# - SWAP use a random key and create a swapspace afterwards

Ich habe zur besseren verständlichkeit des Files einfach ASK stehen, ich bin Neuling 😉
Die Eingabeaufforderung für die Passwörter funktioniert ja ohne Probleme..

Ich hab im enlischen Forum neulich diesen Thread gefunden:
unlock multiple volumes by one password on boot
Der Thread ist 5 Tage alt, ich hab auch davor gegooglet..

bender02 schriebThe thing is that at that point of initscripts, the only mounted partition is the root partition.

I have more-less the same setup that you want (unencrypted root, multiple encrypted partitions, want to enter only one password on boot). What I've done is that I modified the rc.sysinit initscript in a way that just before it tries to unlock the encrypted partitions, it mounts (luks encrypted, so asks for a password) a small loop partition (stored as a file in /etc) with keys to the other partitions; and after unlocking it unmounts it.

Ich denke, dies ist die Lösung für mein Problem? Ich habe noch 2 Fragen zur Anwendung für den geposteten Patch für rc.sysinit:

1. Muss ich noch etwas ändern außer "KEYSFILE" und "MOUNTPOINT" in den beiden skripten (/etc/mountkeys und /etc/umountkeys)?
2. Was muss ich in /etc/crypttab eintragen?

Im Thread wird auch erwähnt:

bender02 schriebNote that no error checking is done; also every update of initscripts overwrites rc.sysinit, so another patching is necessary.

Ließe sich das nicht automatisieren, ohne im pacman.conf NoUpgrade = etc/rc.sysinit einzutragen?
Kann es irgendwann passieren, das mir der Patch meine rc.sysinit zerschießt?

Entschuldigt diesen Katalog an Fragen, aber so tief habe ich noch nie in ein GNU/Linux eingegriffen.. <lost>