Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
bastieh schrieb:
https://wiki.debianforum.de/Cryptsetup_mit_systemd_und_Schl%C3%BCssel_auf_externem_USB-Stick Das decrypt-derived-Script ist aber derzeit wohl nicht vernünftig zu ersetzen.
Hab das nur überflogen - aber das klingt doch nach einer zweiten Lösung? Man befüllt die alten Dateien ähnlich wie immer (leicht angepasst), systemd generiert daraus nach Anstupsen bestimmte Systemd-Dateien, welche man nach /etc kopieren muss. Fertig. Oder? Nachträglich willkommen!
|
u1000
Anmeldungsdatum: 2. Oktober 2011
Beiträge: 1850
|
keyscript= parameter funktioniert nicht mit systemd (Ubuntu 15.04) :/
Es gibt auch eine "einfache" Lösung: Schreibe die keyscript Befehle in die rc.local, ebenso die zugehörigen mount Befehle oder swapon... Die weiteren Festplatten oder Swap wird dann eben "einen Moment später" automatisch eingebunden. Viele Grüße u1000
|
koebln
Anmeldungsdatum: 23. März 2013
Beiträge: 22
Wohnort: Berlin
|
Vielen Dank für den Hinweis von Rome, dass das Öffnen der verschlüsselten Partitionen durch Verwendung des gleichen Schlüssels und entsprechender Konfiguration in /etc/crypttab wieder zum Laufen zu bringen ist. Das war mal wieder ein echter Tiefschlag, als nach dem Upgrade auf die Ubuntu 15.04 keine /home-Partition mehr gemountet wurde. Den Hinweis "gleiches Passwort für verschiedene Zwecke vermeiden" kann ich in diesem Zusammenhang nicht unterstützen, denn die Alternative bedeutet "Passwörter in Klartextdateien", was mindestens genauso schlimm ist. Bleibt zu hoffen, das die sinnvolle und sichere Lösung "Passwortableitung" auch mit systemd wieder bereitgestellt wird. Und das dieser schlimme Fehler nicht zu viele Ubuntu-User vertreibt. Viele Grüße
|
Benno-007
Anmeldungsdatum: 28. August 2007
Beiträge: 29240
Wohnort: Germany
|
Achtung, laut systemd-Baustelle geht auch rc.local nur nach einigen Kniffen wieder, die dort nicht komplett dokumentiert sind.
|
Happy_Penguin
Anmeldungsdatum: 23. Januar 2011
Beiträge: 583
|
Rome schrieb: Die Lösung bei mir war, alle Partitionen ganz normal mit dem gleichen Passwort zu verschlüsseln (also ohne Keyscript). Meine crypttab sieht danach so aus: ....
Irgendwie klingt das sehr ähnlich, wie das Verfahren über pam-mount: "Außerdem ist es möglich mittels eines extra PAM-Plugins ein LUKS-Gerät automatisch beim Login einzuhängen, wenn einer der LUKS-Schlüssel identisch mit dem Anmeldepasswort ist." (Zitiert aus LUKS, beispielhaft beschrieben in Daten verschlüsseln (Abschnitt „luks“)) Dabei stehen die Einträge allerdings in /etc/security/pam_mount.conf.xml und nicht in /etc/crypttab.
|
u1000
Anmeldungsdatum: 2. Oktober 2011
Beiträge: 1850
|
tehownt schrieb: http://lists.freedesktop.org/archives/systemd-devel/2014-July/021418.html
und
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618862 keyscript= parameter funktioniert nicht mit systemd (Ubuntu 15.04) :/
Nachdem ich neulich 2 Rechner auch von 14.10 –> 15.04 upgedatet habe, stelle ich fest: bei mit tritt das Problem nicht auf: Nach Eingabe des Passwortes für die root Partition wird dannach per "keyscript" die swap Partition enschlüsselt. Anscheinend passiert beides noch bevor systemd startet? Ich verwende das Verfahren ohne LVM (System verschlüsseln/Schlüsselableitung). Kann ich irgendwo herausfinden, warum es bei mir geht, um dem TE zu helfen? Viele Grüße u1000
|
frostschutz
Anmeldungsdatum: 18. November 2010
Beiträge: 7657
|
u1000 schrieb: Kann ich irgendwo herausfinden, warum es bei mir geht, um dem TE zu helfen?
Einen alten Kernel bootest du nicht zufällig? Dann würde systemd evtl. erst nach dem kernel/initramfs/entschlüsseln gestartet werden. bastieh schrieb: Außerdem ist es selten eine gute Idee, ein und dasselbe Passwort für verschiedene Zwecke zu verwenden.
Das ist aber genau das was die Schlüsselableitung macht. ☺ Wenn man das jetzt nicht mehr braucht - ist das eigentlich ein Gewinn. Die Schlüsselableitung ist jedenfalls komplizierter als einfach überall das gleiche Passwort zu setzen.
|
u1000
Anmeldungsdatum: 2. Oktober 2011
Beiträge: 1850
|
frostschutz schrieb: Einen alten Kernel bootest du nicht zufällig? Dann würde systemd evtl. erst nach dem kernel/initramfs/entschlüsseln gestartet werden.
$ uname -a
Linux l21 3.19.0-18-generic #18-Ubuntu SMP Tue May 19 18:31:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ ps -p1
PID TTY TIME CMD
1 ? 00:00:01 systemd
$ cat /etc/crypttab
root UUID=xxxx none luks
swap UUID=yyyy root luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived
$ cat /etc/fstab
UUID=zzzz /boot ext4 defaults 0 2
/dev/mapper/root / btrfs defaults,subvol=@ 0 1
/dev/mapper/root /home btrfs defaults,subvol=@home,noatime,nodiratime,compress 0 2
/dev/mapper/swap none swap sw 0 0
...
$dmesg
...
[ 2.661370] input: DualPoint Stick as /devices/platform/i8042/serio1/input/input7
[ 2.692345] input: AlpsPS/2 ALPS DualPoint TouchPad as /devices/platform/i8042/serio1/input/input6
[ 4.196101] floppy0: no floppy controllers found
<--Passwort Eingabe-->
[ 40.345021] random: nonblocking pool is initialized
[ 51.752032] raid6: sse2x1 3802 MB/s
[ 51.820023] raid6: sse2x2 4013 MB/s
[ 51.888016] raid6: sse2x4 6658 MB/s
[ 51.888029] raid6: using algorithm sse2x4 (6658 MB/s)
[ 51.888034] raid6: using ssse3x2 recovery algorithm
[ 51.889656] xor: measuring software checksum speed
[ 51.928009] prefetch64-sse: 9254.000 MB/sec
[ 51.968009] generic_sse: 8200.000 MB/sec
[ 51.968022] xor: using function: prefetch64-sse (9254.000 MB/sec)
[ 51.984551] Btrfs loaded
[ 52.269803] BTRFS: device fsid xxxx devid 1 transid 18388 /dev/mapper/root
[ 52.277869] BTRFS info (device dm-0): disk space caching is enabled
[ 53.966792] systemd[1]: Inserted module 'autofs4'
[ 54.072249] systemd[1]: systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN)
[ 54.072416] systemd[1]: Detected architecture x86-64.
[ 54.125435] systemd[1]: Set hostname to <l21>.
[ 56.480225] systemd[1]: [/run/systemd/generator/systemd-cryptsetup@swap.service:13] Failed to add required mount for, ignoring: root
[ 57.354957] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
...
[ 63.783097] Adding 5240828k swap on /dev/mapper/swap. Priority:-1 extents:1 across:5240828k FS
...
$ mount
/dev/mapper/root on / type btrfs (rw,relatime,space_cache)
/dev/mapper/root on /home type btrfs (rw,noatime,nodiratime,space_cache)
/dev/sda1 on /boot type ext4 (rw,relatime,data=ordered)
...
$ swapon
NAME TYPE SIZE USED PRIO
/dev/dm-1 partition 5G 0B -1 Im dmesg sieht man tatsächlich von systemd einen Fehler für swap, wenige Sekunden später ist dann swap doch bereit... Viele Grüße u1000
|
aldor
Anmeldungsdatum: 14. Februar 2007
Beiträge: 204
Wohnort: Heidelberg
|
frostschutz schrieb: bastieh schrieb: Außerdem ist es selten eine gute Idee, ein und dasselbe Passwort für verschiedene Zwecke zu verwenden.
Das ist aber genau das was die Schlüsselableitung macht. ☺
Solange es sich um ein paar wenige Festplatten handelt, die an einem Ort sind, zu einem System gehören und nicht eine systematische Geheimhaltungshierarchie („Platte für allgemeines Privates“, „Platte für strengstens geheime Daten“, …) darstellen, halte ich es für völlig vertretbar, das selbe Passwort zu nehmen. Generell ist der Einwand von frostschutz (sorry, natürlich haben beide recht, aber ich meinte:) bastieh aber wichtig: Bevor man ein Passwort mehrfach verwendet, sollte man sich genau überlegen, welches Risiko besteht, dass es an einer Stelle kompromittiert und für andere Dinge missbraucht werden könnte. Und welcher Schaden damit verbunden wäre. Bei allem was man online macht ist das Risiko potentiell riesig.
Wenn man das jetzt nicht mehr braucht - ist das eigentlich ein Gewinn. Die Schlüsselableitung ist jedenfalls komplizierter als einfach überall das gleiche Passwort zu setzen.
Komplizierter wird es, wenn man auch externe Platten hinzunimmt, die im laufenden Betrieb angeschlossen werden. Da scheint es auch Probleme zu geben, auch wenn das nicht direkt mit dem keyscript-Parameter zu tun hat. Jedenfalls hab ich es nicht geschafft, die Schlüsselableitung unter Vivid Vervet mit udev oder cron-jobs zu automatisieren. Von Hand in der Shell absetzen geht, aber dann kann ich mir die Ableitung auch sparen und einfach nochmal die Passphrase eintippen.
|
u1000
Anmeldungsdatum: 2. Oktober 2011
Beiträge: 1850
|
Ich habe mir nochmal mein funktionierendes System (Lubuntu 15.04 + Luks + systemd + BTRFS) angeschaut: Ich kann kein Problem mit systemd erkennen: Die root Entschlüsslung per /etc/crypttab wird aus der initramfs heraus gestartet: /usr/share/initramfs-tools/scripts/local-top/cryptroot. systemd als Prozess 1 wird doch erst dannach gestartet, wenn initramfs fertig ist? Das zeigen mir auch die Meldungen beim Systemstart (noplymouth). ...
Jun 21 14:31:21 l21 systemd-journal[339]: Runtime journal is using 4.9M (max allowed 39.5M, trying to leave 59.2M free of 389.7M available → current limit 39.5M).
Jun 21 14:31:21 l21 systemd-journal[339]: Runtime journal is using 4.9M (max allowed 39.5M, trying to leave 59.2M free of 389.7M available → current limit 39.5M).
Jun 21 14:31:21 l21 kernel: random: systemd-udevd urandom read with 12 bits of entropy available
Jun 21 14:31:21 l21 systemd[1]: Inserted module 'autofs4'
Jun 21 14:31:21 l21 systemd[1]: systemd 219 running in system mode. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN)
Jun 21 14:31:21 l21 systemd[1]: Detected architecture x86-64.
...
Das ist die erste Zeile mit system im "sudo journalctl -b | egrep systemd" - die root und swap Entschlüsselung geschieht definitv vorher. Ich kann das Problem vom TE daher weder nachvollziehen, noch verstehen. Oder liegt es an dem BTRFS? Kann systemd mit ext4 ggf. schon früher "übernehmen"? Viele Grüße u1000
|
aldor
Anmeldungsdatum: 14. Februar 2007
Beiträge: 204
Wohnort: Heidelberg
|
Hallo! u1000 schrieb: Ich habe mir nochmal mein funktionierendes System (Lubuntu 15.04 + Luks + systemd + BTRFS) angeschaut: Ich kann kein Problem mit systemd erkennen: Die root Entschlüsslung per /etc/crypttab wird aus der initramfs heraus gestartet: /usr/share/initramfs-tools/scripts/local-top/cryptroot. systemd als Prozess 1 wird doch erst dannach gestartet, wenn initramfs fertig ist? […] Das ist die erste Zeile mit system im "sudo journalctl -b | egrep systemd" - die root und swap Entschlüsselung geschieht definitv vorher. Ich kann das Problem vom TE daher weder nachvollziehen, noch verstehen. Oder liegt es an dem BTRFS? Kann systemd mit ext4 ggf. schon früher "übernehmen"?
Das Problem tritt nur auf, wenn man versucht, eine zweite Partition mit Schlüsselableitung automatisch zu entschlüsseln. Solange alle Partitionen physikalisch auf ein und der selben Platte liegen, ist es einfacher diese mit LVM ein eine LUKS-verschlüsselte Partition reinzupacken. Dann gibt es kein Problem. Nur wer aus Angst vor LVM oder wegen physikalische getrennter Festplatten automatische Schlüsselableitung verwendet, muss mit Problemen rechnen.
|
u1000
Anmeldungsdatum: 2. Oktober 2011
Beiträge: 1850
|
aldor schrieb: Das Problem tritt nur auf, wenn man versucht, eine zweite Partition mit Schlüsselableitung automatisch zu entschlüsseln.
Bei mir ja eben nicht: $ cat /etc/crypttab
root UUID=xxxxxxxxxxxx none luks
swap UUID=yyyyyyyyyyyy root luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived Und funktioniert bestens! Meldung nach Eingabe des Passwortes:
cryptsetup root set up successfull
cryptsetup swap set up successfull P.S. ich bin an dem Problem sehr interesssiert, da ich verstehen möchte, was dem TE passiert ist - nicht dass mir das beim nächsten Ubuntu Update dann auch blüht... ☺ Ich habe übrigens auch wie der TE auf 15.04 upgedated - keine Neuinstallation. Viele Grüße u1000
|
aldor
Anmeldungsdatum: 14. Februar 2007
Beiträge: 204
Wohnort: Heidelberg
|
u1000 schrieb: aldor schrieb: Das Problem tritt nur auf, wenn man versucht, eine zweite Partition mit Schlüsselableitung automatisch zu entschlüsseln.
Bei mir ja eben nicht: $ cat /etc/crypttab
root UUID=xxxxxxxxxxxx none luks
swap UUID=yyyyyyyyyyyy root luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived Und funktioniert bestens! Meldung nach Eingabe des Passwortes:
cryptsetup root set up successfull
cryptsetup swap set up successfull
Hm. Interessant. Oben in der Diskussion sind mehrere Quellen verlinkt, aus denen hervorgeht, dass es (zumindest zum damaligen Zeitpunkt) nicht funktionieren dürfte und dass auch seitens systemd nicht vorgesehen war, das in absehbarer Zeit zu ändern. Entweder an der Haltung hat sich was geändert und die Updates sind schon bei Ubuntu eingeflossen. Oder bei Deinem Upgrade wurde nicht richtig auf systemd umgestellt. Eine mögliche andere Erklärung hätte ich auch noch: Hast Du für swap auch noch eine zweite Passphrase gesetzt? Ist die vielleicht mit der von root identisch? Dann könnte es auch passieren, dass beide Partitionen in einem Rutsch entsperrt werden. Ich selber habe Schlüsselableitung mit /etc/crypttab nie getestet. Bei mir standen zwei Neuinstallationen, an auf Rechnern die jeweils genau eine interne Platte haben. Ich habe viel gelesen und diskutiert – mit dem Ergebnis, dass in dieser Situation einfach der Weg über LVM die Methode der Wahl. Das würde ich auch für Neuinstallationen jedem empfehlen. Allerdings habe ich auch eine externe Backup-Festplatte, die ebenfalls mit LUKS verschlüsselt sein soll. Da nicht garantiert ist, dass die Platte beim Systemstart vorhanden ist, wollte ich hierfür zwar Schlüsselableitung verwenden, aber nicht über /etc/crypttab sondern mit udev oder cron. Obwohl alles geklappt hat, wenn man es manuell im Terminal eingegeben hat, wollte es ums Verrecken nicht mit cron oder udev gehen. Die üblichen Verdächtigen (siehe CRON → Häufige-Fehler) waren es nicht. Ob dieses Verhalten irgendetwas mit dem ursprünglichen Problem dieses Threads zu tun hat, kann ich leider nicht sagen. Ich habe mich schlussendlich für einen in einer nur für root lesbaren Datei hinterlegten Schlüssel auf der ersten verschlüsselten Festplatte entschieden. Übrigens: wenn Du neben der root-Partition nur noch eine swap-Partition verschlüsseln musst, könntest Du gegebenenfalls auch mit Einmal-Schlüsseln arbeiten. (Ich kann Dir aber nicht sagen, wie man das einrichtet.)
|
u1000
Anmeldungsdatum: 2. Oktober 2011
Beiträge: 1850
|
aldor schrieb: Oder bei Deinem Upgrade wurde nicht richtig auf systemd umgestellt.
nöö, sieht nicht dannach aus:
$ ps -p1
PID TTY TIME CMD
1 ? 00:00:01 systemd
Habe ausserdem einen weiteren Rechner bei dem keyscript ebenso funktioniert.
Eine mögliche andere Erklärung hätte ich auch noch: Hast Du für swap auch noch eine zweite Passphrase gesetzt?
nein, sowohl root und swap haben nur einen Keyslot.
Ist die vielleicht mit der von root identisch? Dann könnte es auch passieren, dass beide Partitionen in einem Rutsch entsperrt werden.
Gerade nochmal getestet: auch nein: swap läst sich nicht mit dem root-luks Passwort öffnen. Viele Grüße u1000
|
syscon-hh
Anmeldungsdatum: 8. Oktober 2005
Beiträge: 10220
|
bastieh schrieb: Nur geht es hier ursächlich darum, dass nach dem Update auf Ubuntu 15.04 die keyscripts nicht mehr funktionieren. Das hat unter anderem auch zur Folge, dass mehrere Anleitungen aus dem Wiki hier nicht mehr auf die neueste Version von Ubuntu anwendbar sind.
Wir haben das Problem jetzt mal unter Xenial Xerus weiter untersucht und sind dort auch zu einer Lösung gekommen, wie man mehrere Partitionen unter systemd mit einer Eingabe einbinden kann.
Wäre schön wenn das mal unabhängig von uns getestet wird. gruß syscon-hh
|