[Gelöst] LUKS Partition & Neuinstallation

switcher51 · 16 Okt. 2009

Wie erreiche ich, dass für dev/sda4 beim Hochfahren nach dem Passwort gefragt wird?

Hier helfen Einträge in /etc/crypttab:

Code:

cr_sda4 /dev/sda4 none luks

(vgl. man crypttab)
und in /etc/fstab:

Code:

/dev/mapper/cr_sda4  /mnt/home reiserfs defaults 0 2

Dadurch wird beim Boot die Partition entschlüsselt (und dabei wg. "none" nach dem Passwort gefragt) und eingebunden. (Falls der File System Type nicht "reiserfs" ist muss das entsprechend ersetzt werden).

Muss ich ein neues Benutzerkonto erstellen und da das in dev/sda4 enthaltene Verzeichnis als home-Verzeichnis eintragen?

Die Benutzer sind mit der Neuinstallation neu angelegt worden - oder?
Es existieren nun also pro Benutzer 1 altes Home-Verzeichnis und 1 neues Home-Verzeichnis. Aus den beiden Verzeichnissen ist nun ein aktuelles zu machen. Dazu müssen beide Verzeichnisse an unterschiedlichen Stellen gemountet werden. (Also z.B. das Crypto-Device (s.o.) vorübergehend auf /mnt/home mounten.) Beim Abgleich der Verzeichnisse müssen die Unterverzeichnisse mit vom Benutzer eingebrachten Daten vom alten ins neue Home-Verz. kopiert werden. Die systemrelevanten (meist versteckten Dateien) sollten nicht überschrieben werden. (Ggf. gibt es Ausnahmen z.B. ".profile", ".bashrc", ...) Ich brauche nicht zu erwähnen, dass vor der Aktion eine Datensicherung Sinn macht. Nach der Aktion kann das Crypto-Device auf /home gemountet werden. Hierzu ist /etc/fstab entsprechend anzupassen:

Code:

/dev/mapper/cr_sda4  /home reiserfs defaults 0 2

neophyte · 6 Nov. 2009

switcher51 schrieb:
Ich brauche nicht zu erwähnen, dass vor der Aktion eine Datensicherung Sinn macht.

Möchte neue Daten von dev/sda4 auf dev/sdb1 übertragen.

Wie öffne ich das auf /media/Iomega\ HDD/mnt gespeicherte verschlüsselte Verzeichnis sda4?

Es geht nicht mit z.B:

Code:

cryptsetup luksOpen /media/Iomega\ HDD/mnt cr_sda4

Gibt Fehlermeldung:
Command failed: Can not access device

josef-wien · 6 Nov. 2009

Wenn nichts umstrukturiert wurde, ist /dev/sda4 Deine verschlüsselte Home-Partition und /dev/sdb1 enthält eine Sicherungskopie davon in Form einer Image-Datei /media/Iomega\HDD/mnt/sda4.

Willst Du wirklich diese Sicherungskopie verändern? Üblicherweise verändert man Sicherungskopien nicht, sondern erstellt eine neue Sicherungskopie. Bei Platzbedarf muß die bisherige Sicherungskopie vorher gelöschet werden.

neophyte · 14 Nov. 2009

josef-wien schrieb:
Wenn nichts umstrukturiert wurde, ist /dev/sda4 Deine verschlüsselte Home-Partition und /dev/sdb1 enthält eine Sicherungskopie davon in Form einer Image-Datei /media/Iomega\HDD/mnt/sda4.

Willst Du wirklich diese Sicherungskopie verändern? Üblicherweise verändert man Sicherungskopien nicht, sondern erstellt eine neue Sicherungskopie. Bei Platzbedarf muß die bisherige Sicherungskopie vorher gelöschet werden.

Neue Sicherungskopie ist erstellt.

Dieses Image lässt sich also nicht auf /dev/sdb1 öffnen und muss auf /dev/sda4 zurück kopiert werden damit das darin enthaltenen verschlüsselte Homeverzeichnis geöffnet werden kann?

Funktioniert das auch nach einer Neuinstallation von openSUSE 11.2 mit einer vergrößerten Partition auf die das Image kopiert wird?

josef-wien · 14 Nov. 2009

Du kannst die Image-Datei als "loop device" ins Dateisystem einhängen und dann ganz normal lesen bzw. schreiben. Da Du verschlüsselt hast, könnte ich die notwendigen Schritte nur raten, und das unterlasse ich lieber.

Wenn Du die Größe von /dev/sda4 änderst, würde ich das Image nicht zurückkopieren.

neophyte · 21 Dez. 2009

switcher51 schrieb:
Die Benutzer sind mit der Neuinstallation neu angelegt worden - oder?
Es existieren nun also pro Benutzer 1 altes Home-Verzeichnis und 1 neues Home-Verzeichnis. Aus den beiden Verzeichnissen ist nun ein aktuelles zu machen. Dazu müssen beide Verzeichnisse an unterschiedlichen Stellen gemountet werden. (Also z.B. das Crypto-Device (s.o.) vorübergehend auf /mnt/home mounten.) Beim Abgleich der Verzeichnisse müssen die Unterverzeichnisse mit vom Benutzer eingebrachten Daten vom alten ins neue Home-Verz. kopiert werden. Die systemrelevanten (meist versteckten Dateien) sollten nicht überschrieben werden. (Ggf. gibt es Ausnahmen z.B. ".profile", ".bashrc", ...) Ich brauche nicht zu erwähnen, dass vor der Aktion eine Datensicherung Sinn macht. Nach der Aktion kann das Crypto-Device auf /home gemountet werden. Hierzu ist /etc/fstab entsprechend anzupassen:

Code:

/dev/mapper/cr_sda4 /home reiserfs defaults 0 2

Sicherungskopie ist erstellt und Verzeichnisse sind abgeglichen.

Eintrag von:

Code:

/dev/mapper/cr_sda4  /home reiserfs defaults 0 2

in /etc/fstab ist erfolgt.

Beim Booten wird das Passwort nicht mehr abgefragt.

Gibt Fehlermeldung:

Error on stat () /dev/mapper/cr_sda4: No such file or directory
Bootsplash: Status on console 0 changed to on
Failed to open the device "/dev/mapper/cr_sda4" no such file or directory

System fordert root login und "repair manually".

Wie gehe ich da vor?

switcher51 · 21 Dez. 2009

wegen der langen Zeit habe ich die Details nicht mehr parat.
Vorgehen:
1. fraglich Zeile aus /etc/fstab entfernen oder auf noauto stellen
2. nach dem reboot das richtige device ermitteln und manuell mounten
3. /etc/fstab entsprechend präparieren

Ist denn luksOpen gelaufen, d.h. hat /etc/crypttab funktioniert?
Der zitierte Fehler sagt mir eher das Gegenteil!

neophyte · 28 Dez. 2009

switcher51 schrieb:
wegen der langen Zeit habe ich die Details nicht mehr parat.
Vorgehen:
1. fraglich Zeile aus /etc/fstab entfernen oder auf noauto stellen
2. nach dem reboot das richtige device ermitteln und manuell mounten
3. /etc/fstab entsprechend präparieren

Zu 1) Wie geht das mit der Kommandozeile, die nach dem root Passwort "repair manually" fordert?
Zu 2) Vermutlich sind die verschlüsselten Partitionen gemeint:
dev/sda2 (Swap)
dev/sda4 (Homeverzeichnis)
Zu 3) Wie präparieren?

switcher51 schrieb:
Ist denn luksOpen gelaufen, d.h. hat /etc/crypttab funktioniert?
Der zitierte Fehler sagt mir eher das Gegenteil!

Es wird nicht mehr automatisch beim Booten nach den Passwörtern gefragt.
Wie repariere ich /etc/crypttab mittels Kommandozeile?

switcher51 · 28 Dez. 2009

Wie geht das mit der Kommandozeile, die nach dem root Passwort "repair manually" fordert?

Nach der Eingabe des Root-Kennworts steht eine Kommandozeile zur Verfügung. (Notfalls kann mit Live-CD gestartet werden.) Nun mit dem Lieblingseditor /etc/fstab bearbeiten und die Einträge auskommentieren (# in 1. Spalte der Zeile), die zu Fehlern führen. Nun sollte das System wieder fehlerfrei (ohne die verschlüsselten Partitionen) starten.

Noch einmal den Stand der Dinge nachgefragt:
Wir hatten herausgefunden, dass /dev/sda2 die verschlüsselte swap-Partition und /dev/sda4 die verschlüsselte /home-partition ist - richtig?

Du kannst zur Probe noch einmal das verschlüsselte Home-Verzeichnis manuell öffnen:

cryptsetup luksOpen /dev/sda4 cr_sda4

Unter http://linux.die.net/man/5/crypttab kannst du die Syntax der crypttab nachlesen.
Eintrag entsprechend vornehmen:

Code:

cr_sda4   /dev/sda4   none

Überprüfe, dass /etc/init.d/cryptdisks existiert und in /etc/init.d/rc3.d verlinkt (2x) ist.
(siehe hierzu auch https://systemausfall.org/wikis/howto/CryptoPartitionHowTo)

Bei Neustart des Rechners sollte nun nach dem Kennwort der Partitionen gefragt werden.

Danach wird die Partition erst manuell und später per fstab eingebunden (siehe alter Eintrag in fstab).

Mit der SWAp-Partition kann analog verfahren werden - aber eins nach dem anderen - erst mal mit dem Home-Verzeichnis üben....

neophyte · 7 Jan. 2010

switcher51 schrieb:
Wie geht das mit der Kommandozeile, die nach dem root Passwort "repair manually" fordert?

Zum Vergrößern anklicken....

Nach der Eingabe des Root-Kennworts steht eine Kommandozeile zur Verfügung. (Notfalls kann mit Live-CD gestartet werden.) Nun mit dem Lieblingseditor /etc/fstab bearbeiten und die Einträge auskommentieren (# in 1. Spalte der Zeile), die zu Fehlern führen. Nun sollte das System wieder fehlerfrei (ohne die verschlüsselten Partitionen) starten.

Noch einmal den Stand der Dinge nachgefragt:
Wir hatten herausgefunden, dass /dev/sda2 die verschlüsselte swap-Partition und /dev/sda4 die verschlüsselte /home-partition ist - richtig?

Du kannst zur Probe noch einmal das verschlüsselte Home-Verzeichnis manuell öffnen:

cryptsetup luksOpen /dev/sda4 cr_sda4

Zum Vergrößern anklicken....

Unter http://linux.die.net/man/5/crypttab kannst du die Syntax der crypttab nachlesen.
Eintrag entsprechend vornehmen:

Code:

cr_sda4 /dev/sda4 none

Überprüfe, dass /etc/init.d/cryptdisks existiert und in /etc/init.d/rc3.d verlinkt (2x) ist.
(siehe hierzu auch https://systemausfall.org/wikis/howto/CryptoPartitionHowTo)

Bei Neustart des Rechners sollte nun nach dem Kennwort der Partitionen gefragt werden.

Danach wird die Partition erst manuell und später per fstab eingebunden (siehe alter Eintrag in fstab).

Mit der SWAp-Partition kann analog verfahren werden - aber eins nach dem anderen - erst mal mit dem Home-Verzeichnis üben....

In /etc/fstab habe ich /dev/sda2 und /dev/sda4 mit # auskommentiert. Jetzt wird beim Booten für beide verschlüsselten Partitionen nach dem Passwort gefragt. In Gnome kann neben dem Benutzer-Homeverzeichnis auch das Homeverzeichnis aus /dev/sda4 angesprochen werden.

/dev/sda2 ist die verschlüsselte Swap Partition.

Nicht auffindbar ist /etc/init.d/cryptdisks .
In /etc/init.d/rc3.d besteht dazu keine Verlinkung.

/etc/fstab

# /dev/mapper/cr_sda2 swap swap defaults 0 0
# /dev/mapper/cr_sda4 /home reiserfs defaults 0 2

/etc/crypttab

cr_sda2 /dev/disk/by-id/ata-FUJITSU_MHT2060AT_NN7BT4918FH6-part2 none swap
cr_sda4 /dev/sda4 none luks

Wo liegt der Fehler?

switcher51 · 9 Jan. 2010

Nicht auffindbar ist /etc/init.d/cryptdisks

Das scheint an der Distribution zu liegen. Da du aber beim Boot nach dem Passwort gefragt wirst, ist schon das Öffnen der verschlüsselten Partitionen geregelt. Es besteht hier also kein Handlungsbedarf mehr.

Es geht jetzt darum, die verschlüsselten Partitionen durch Eintrag in der /etc/fstab automatisch zu mounten.
Hierzu benötigen wir die Device-Namen. (Die Vermutung /dev/mapper/cr_sda4 ist wohl falsch!)
Da du die verschlüsselte Home-Partition manuell in Gnome mounten kannst, schlage ich folgendes Vorgehen vor:
1) manueller Mount in Gnome
2) Kommando "mount" in Konsole: zeigt wie die verschl. Partition eingebunden wird (insbesondere den Device-Namen)
3) Übertragung der mount-Parameter in die /etc/fstab
4) unmount mit Gnome oder "umount"
5) manueller Mount an der Konsole (als Test)
6) wenn das geklappt hat, kann der automatische Mount beim Booten getestet werden
Mit der Swap-Partition kann im Schritt 5 analog verfahren werden. (richtigen Device-Namen und swap einsetzen).

Falls es Schwierigkeiten gibt, benötige ich die folgenden Infomationen:
1) Output von "mount" in Schritt 2)
2) komplette /etc/fstab

neophyte · 10 Jan. 2010

switcher51 schrieb:
Falls es Schwierigkeiten gibt, benötige ich die folgenden Infomationen:
1) Output von "mount" in Schritt 2)
2) komplette /etc/fstab

zu 1)
# mount
/dev/sda3 on / type ext3 (rw,acl,user_xattr)
/proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
debugfs on /sys/kernel/debug type debugfs (rw)
udev on /dev type tmpfs (rw)
devpts on /dev/pts type devpts (rw,mode=0620,gid=5)
/dev/sda1 on /windows/C type fuseblk (rw,noexec,nosuid,nodev,allow_other,default_permissions,blksize=4096)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
securityfs on /sys/kernel/security type securityfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
gvfs-fuse-daemon on /home/neophyte/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=neophyte)
/dev/dm-1 on /media/disk-1 type reiserfs (rw,nosuid,nodev)

zu 2)
# /dev/mapper/cr_sda2 swap swap defaults 0 0
# /dev/mapper/dm-1 /home reiserfs defaults 0 2
/dev/disk/by-id/ata-FUJITSU_MHT2060AT_NN7BT4918FH6-part3 / ext3 acl,user_xattr 1 1
/dev/disk/by-id/ata-FUJITSU_MHT2060AT_NN7BT4918FH6-part1 /windows/C ntfs-3g users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs noauto 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0

switcher51 · 10 Jan. 2010

Wenn ich das richtig sehe, dann ist die letzte Zeile zu mount, die die verschl. Partition betrifft. Das Device heißt dann "/dev/dm-1" .
Damit ist /etc/fstab zu beaufschlagen, dh. statt "/dev/mapper/dm-1" muss es dort "/dev/dm-1" heißen:

Code:

/dev/dm-1 /home reiserfs defaults 0 2

(Ggf. kann die Zeile an der Stelle von defaults mit weiteren Parametern nach Wahl erweitert werden.)
Wie heißt das Device der verschl. SWAP-Partition? (Meine Vermutung: es könnte /dev/dm-0 sein.)
Die entsprechende Zeile in /etc/fstab wäre dann:

Code:

/dev/dm-0 swap swap defaults 0 0

neophyte · 12 Jan. 2010

switcher51 schrieb:
Wenn ich das richtig sehe, dann ist die letzte Zeile zu mount, die die verschl. Partition betrifft. Das Device heißt dann "/dev/dm-1" .
Damit ist /etc/fstab zu beaufschlagen, dh. statt "/dev/mapper/dm-1" muss es dort "/dev/dm-1" heißen:

Code:

/dev/dm-1 /home reiserfs defaults 0 2

(Ggf. kann die Zeile an der Stelle von defaults mit weiteren Parametern nach Wahl erweitert werden.)
Wie heißt das Device der verschl. SWAP-Partition? (Meine Vermutung: es könnte /dev/dm-0 sein.)
Die entsprechende Zeile in /etc/fstab wäre dann:

Code:

/dev/dm-0 swap swap defaults 0 0

Änderungen durchgeführt. Geht immer noch nicht. Gibt Fehlermeldung, dass /dev/dm-1 nicht existiert.

gropiuskalle · 13 Jan. 2010

Zwei kleine Einwürfe mit der Betonung darauf, dass ich mir jetzt nicht den ganzen thread durchgelesen habe.

1. Könnte man die ganze Angelegenheit nicht etwas entschlacken, indem man die Verschlüsselung der swap-Partition überdenkt? Irgendwie erkenne ich darin keinerlei Sinn... wenn mich nicht alles täuscht (was allerdings durchaus möglich wäre), ist es doch ohnehin nicht möglich, irgendetwas verwertbares aus einer swap-Partition zu lesen, nachdem ein System heruntergefahren wurde - und während des Betriebes kann auf eingebundene LUKS-verschlüsselte Partitionen ohnehin genau so zugegriffen werden wie auf eine unverschlüsselte.

2. Hier wurden verschiedene fstabs durchgekaut - vielleicht hilft es, wenn ich meinen (funktionierenden) Eintrag hier einfach mal poste.

Code:

/dev/mapper/cr_sdb1  /home/kalle/datenzwei ext4       acl,user_xattr,noauto 0 0

...falls nicht: einfach ignorieren.

neophyte · 14 Feb. 2010

gropiuskalle schrieb:
2. Hier wurden verschiedene fstabs durchgekaut - vielleicht hilft es, wenn ich meinen (funktionierenden) Eintrag hier einfach mal poste.

Code:

/dev/mapper/cr_sdb1 /home/kalle/datenzwei ext4 acl,user_xattr,noauto 0 0

...falls nicht: einfach ignorieren.

Funktioniert:

Code:

/dev/mapper/cr_sda4  /home   reiserfs   acl,user_xattr,noauto 0 0

Gelöst. Danke für eure Hilfe.