[gel.]luks: 3 x falsches Passwort, System danach unbenutzbar

[NAB]

Dann sollte man

Wenn du schon einen so guten Draht zu "man" hast, dass du für ihn sprechen kannst, dann sag ihm doch mal, dass er diesen Bug beheben soll.

Ansonsten wäre es hilfreich, wenn du den Thread liest, da geht es nämlich um Jessie, Systemd und um den Eintrag "swap" in der /etc/crypttab. Schön, falls das vielleicht irgendwo in Unstable behoben wäre... genau das könntest du testen und damit den Bugreport bereichern.

Der eigentliche "Bug" ist meiner Meinung nach, dass das Thema "Verschlüsselung" in Jessie eher stiefmütterlich behandelt wurde und es oberste Priorität hatte, Systemd noch irgendwie reinzuhämmern. Ich hoffe, das ändert sich in der Zukunft wieder.

[habakug]

Hallo!

Aus der Manpage von "crypttab":

[...]
The fourth field, if present, is a comma-delimited list of options.[...]
luks
Force LUKS mode. When this mode is used, the following options are
ignored since they are provided by the LUKS header on the device:
cipher=, hash=, size=.
[...]
swap
The encrypted block device will be used as a swap device, and will
be formatted accordingly after setting up the encrypted block
device, with mkswap(8). This option implies plain.

WARNING: Using the swap option will destroy the contents of the
named partition during every boot, so make sure the underlying
block device is specified correctly.
[...]

Das vierte Feld in der "crypttab" enthält eine durch Kommata getrennte Liste von Optionen. Ist die erste Option allerdings "luks", werden alle weiteren Optionen ignoriert, da sie im Luks-Header abgelegt werden. Deswegen würde der Eintrag

Code: Alles auswählen

sda3_crypt UUID=partition3 none luks,swap

auch bedeuten, daß der "swap" Eintrag ignoriert wird. @wanne hatte Recht, "swap" impliziert "plain". Damit der Anfangsbereich der swap-Partition nicht jedesmal die UUID oder das LABEL verliert (es wird ja "destroyt"), legt man am Anfang der Partition ein Dateisystem mit z.B. 1 Mb Grösse an, das einen Namen bekommt oder eine UUID, während die verschlüsselte swap mit einem Offset gemountet wird:

Code: Alles auswählen

sda3_crypt LABEL=partition3 none swap,offset=2048

Das ist hier z.B. beschrieben [1].
Einen Bug kann ich hier nicht erkennen, es sind wohl eher Verständnis und Bedienungsfehler.

Gruss, habakug

[1] https://wiki.archlinux.org/index.php/Dm ... encryption

[NAB]

Einen Bug kann ich hier nicht erkennen, es sind wohl eher Verständnis und Bedienungsfehler.

Ja, deinerseits, du hast die Distribution verwechselt (oder das Forum). Wir sind hier bei Debian Stable, nicht bei Arch, und wie die man page aussieht, kannst du dir hier angucken:
https://manpages.debian.org/cgi-bin/man ... &locale=en

[habakug]

Hallo!

O.K., man kann auch hier [1] debian-spezifisch nachlesen, wie das geht.

2. Encrypted swap partition(s)

Ich kann aber immer noch keinen Bug erkennen. Die Version in Jessie ist "1.6.6-5", in Stretch ind Sid ist "1.7.0-2". Die Manpages der beiden Versionen unterscheiden sich kaum ("fix typo") [2]. Ich habe hier eine Version "1.7.1" [3]. Da es dort keine Manpage für "crypttab" gibt habe ich nicht die Debian-Manpage verwendet, sondern die Manpage von Freedesktop [4].

Gruss, habakug

[1] https://github.com/lhost/pkg-cryptsetup ... DME.Debian
[2] http://anonscm.debian.org/viewvc/pkg-cr ... l?view=log
[3] https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/
[4] https://www.freedesktop.org/software/sy ... pttab.html

[NAB]

habe ich nicht die Debian-Manpage verwendet, sondern die Manpage von Freedesktop [4].

Das ist Systemd 229. Das soll gerade in Stretch sein. Da gibt's dann wohl den zusätzlichen Bug, dass die manpage in Stretch veraltet ist. Die sieht nämlich in der Tat ganz anders aus:
https://manpages.debian.org/cgi-bin/man ... &locale=en

Ich verstehe nicht, was das mit dem Thread hier zu tun hat. Hier geht's um Debian Jessie und Systemd 215.

[habakug]

Hallo!

Ich verstehe nicht, was das mit dem Thread hier zu tun hat. Hier geht's um Debian Jessie und Systemd 215.

Ich verstehe nicht was du von mir willst, soll ich mich verziehen?
Oder reden wir hier von der Handhabung von "cryptsetup", einem Programm, das keiner Distribution "gehört", die über den Inhalt von Manpages entscheidet. Man sollte sich vielleicht auch Konzepte zu Gemüte führen, die Debian nicht bereit hält.
Und dabei gute Laune behalten...

Gruss, habakug

[NAB]

Ich verstehe nicht was du von mir willst, soll ich mich verziehen?
Oder reden wir hier von der Handhabung von "cryptsetup", einem Programm, das keiner Distribution "gehört", die über den Inhalt von Manpages entscheidet.

Gibt's nur die beiden Optionen? Na, dann verzieh ich mich. Ich hab nämlich von der konkreten Version von Cryptsetup in Debian Jessie geredet.

Ob es angemessen ist, das Thema auf sämtliche Implementationen von cryptsetup, die irgendwo auf der Welt existieren mögen, auszudehnen, musst du entscheiden, das interessiert mich aber nicht die Bohne

[dirk11]

Das vierte Feld in der "crypttab" enthält eine durch Kommata getrennte Liste von Optionen. Ist die erste Option allerdings "luks", werden alle weiteren Optionen ignoriert, da sie im Luks-Header abgelegt werden. Deswegen würde der Eintrag

Code: Alles auswählen

sda3_crypt UUID=partition3 none luks,swap

auch bedeuten, daß der "swap" Eintrag ignoriert wird. @wanne hatte Recht, "swap" impliziert "plain". Damit der Anfangsbereich der swap-Partition nicht jedesmal die UUID oder das LABEL verliert (es wird ja "destroyt"), legt man am Anfang der Partition ein Dateisystem mit z.B. 1 Mb Grösse an, das einen Namen bekommt oder eine UUID, während die verschlüsselte swap mit einem Offset gemountet wird:

Code: Alles auswählen

sda3_crypt LABEL=partition3 none swap,offset=2048

Sorry, ehrlich gesagt verstehe ich gerade überhaupt nicht, was Du damit erklären willst.
Bei mir steht in der /etc/crypttab so etwas drin:

Code: Alles auswählen

sda3_crypt UUID=1234deef-1762-4ab1-cd68-555884428886 none luks
sda8_crypt UUID=83300000-6447-44ah-qwrt-123335345276d0 none luks,swap

Da wurde weder vom Installer noch von mir irgendein offset reingeschrieben, und das funktioniert tadellos (mit sysvinit).

[habakug]

Hallo!

Zu sysvinit kann und wollte ich jetzt nichts sagen, meine Hinweise bezogen sich auf Systeme mit systemd. Hier [1] aus einem Bug-Report einer anderen Distribution:

More info from the source code of systemd-cryptsetup:

else if (streq(option, "luks"))
arg_type = CRYPT_LUKS1;
...
} else if (STR_IN_SET(option, "plain", "swap", "tmp"))
arg_type = CRYPT_PLAIN;

so the swap argument overwrites the luks argument and resets the ecryption type to plain.
And indeed, when using
/lib/systemd/systemd-cryptsetup attach sda2_crypt /dev/sda2 none swap,luks,discard
(i.e. just change the order of the parameters, use swap,luks,discard instead of luks, swap, discard , as the ubuntu installer creates, it works and uses the luks partition correctly.

Entsprechend mein Vorschlag die Reihenfolge auf "swap,luks" zu ändern.
Bei deiner Variante wird die crypttab ja direkt gelesen und nicht wie bei Jessie und later von systemd-cryptsetup.

Gruss, habakug

[1] https://bugs.launchpad.net/ubuntu/+sour ... ug/1506139
[2] https://bugs.launchpad.net/ubuntu/+sour ... omments/11

[dirk11]

Das bestätigt doch nur, daß systemd scheiße ist. Mit welchem Recht fummelt der irgendwo dran rum und überschreibt irgendwas? Ich kann immer weniger nachvollziehen, wieso Debian diesen unausgereiften Müll für ein stable zugelassen hat.

[NAB]

Mit welchem Recht fummelt der irgendwo dran rum und überschreibt irgendwas?

Genau das frage ich mich eben auch. Zum einen ist das Parsing kaputt ... wenn du ein "swap" reinschreibst, übersieht er, dass du davor ein "luks" gesetzt hast, und fantasiert sich zusammen, du hättest da "plain" reingeschrieben, statt ne Fehlermeldung zu schmeißen. Der gleiche kaputte Sourcecode steht noch in der aktuellen Version von Systemd und der Patch aus dem Bugreport, den ich verlinkt habe, würde auch den reparieren.

Wenn du also dann dein Passwort eingibst, entschlüsselt er das Device "plain" mit Defaultoptionen, lässt ein mkswap drüberlaufen und schrottet dabei deinen LUKS-Header. Das erklärt soweit auch den Fall aus diesem Bugreport. Da ein Hibernate durch das "swap" eh nicht funktioniert, wär das auch nicht so schrecklich tragisch.

Bei debianoli liegt der Fall aber anders ... der gibt in der Initramdisk drei mal ein falsches Passwort an, danach wird wohl ins Rootsystem gebootet und Systemd versucht, das Device plain zu entschlüsseln, denn da steht ja "swap". Offensichtlich entschlüsselt es die Partition auch, denn es schrottet danach den LUKS-Header. Aber mit welchem Passwort zur Hölle? In der crypttab steht "none", Systemd müsste also fragen. Zaubert es das Passwort aus der Hosentasche? Haben wir hier auch noch ein Sicherheitsproblem neben dem kaputten Parsing?

Falls jemand dazu noch was weiß, bitte her damit!

[habakug]

Hallo!

Jetzt nochmal Butter bei die Fische und ein Test für Debian "Jessie" in der aktuellen Version. Ich erstelle hier nur ein verschlüsseltes swap-Device, die root-Partition bleibt unverschlüsselt.

Code: Alles auswählen

# cat /etc/debian_version 
8.4
# uname -a
Linux deb8v 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux

Die Software wird installiert:

Code: Alles auswählen

# apt-get install cryptsetup
[...]
cryptsetup-bin (2:1.6.6-5) wird eingerichtet ...
cryptsetup (2:1.6.6-5) wird eingerichtet ...
update-initramfs: deferring update (trigger activated)
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Trigger für systemd (215-17+deb8u4) werden verarbeitet ...
Trigger für initramfs-tools (0.120+deb8u1) werden verarbeitet ...
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64

Hier fällt auf, das da noch nicht angepasste init-Skripte rumhängen.
Der Inhalt der "fstab" vor den Änderungen:

Code: Alles auswählen

# cat /etc/fstab
UUID=57e41b29-16c5-4632-9737-bbef97e3b0f4 /               ext4    errors=remount-ro 0       1
# /boot/efi was on /dev/sda1 during installation
UUID=CAAA-CE53  /boot/efi       vfat    umask=0077      0       1
# swap was on /dev/sda3 during installation
UUID=46e550f5-4a5e-4fb9-9b07-1909e3bb978e none            swap    sw              0       0

...und danach der geänderte swap-Eintrag:

Code: Alles auswählen

# cat /etc/fstab
[...]
# swap was on /dev/sda3 during installation
# UUID=46e550f5-4a5e-4fb9-9b07-1909e3bb978e none            swap    sw              0       0
/dev/mapper/cryswap  none  swap  sw  0  0

Die bis jetzt leere "crypttab" erhält einen Eintrag:

Code: Alles auswählen

# cat /etc/crypttab
# <target name>	<source device>		<key file>	<options>
cryswap  /dev/sda3  /dev/urandom  swap,luks

Jetzt wird das initramfs noch aktualisiert und neu gestartet:

Code: Alles auswählen

# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
# reboot

Beim Booten wird nach Grub gleich nach einem Passwort gefragt. Drückt man die Eingabetaste geht es weiter. Es wird ein zweites Mal nach einem Passwort gefragt, geht aber auch weiter wenn man nichts macht. Das swap wird nicht eingerichtet. Fehler aus dem Log:

Code: Alles auswählen

Apr 22 13:32:37 deb8v systemd-cryptsetup[263]: Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/sda3.
Apr 22 13:32:37 deb8v kernel: device-mapper: uevent: version 1.0.3
Apr 22 13:32:37 deb8v kernel: device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com
Apr 22 13:32:37 deb8v kernel: sha256_ssse3: Using AVX optimized SHA-256 implementation
Apr 22 13:32:37 deb8v swapon[309]: swapon: /dev/mapper/cryswap: swapon failed: Das Argument ist ungültig
Apr 22 13:32:37 deb8v systemd[1]: dev-mapper-cryswap.swap swap process exited, code=exited status=255
Apr 22 13:32:37 deb8v systemd[1]: Failed to activate swap /dev/mapper/cryswap.
Apr 22 13:32:37 deb8v systemd[1]: Unit dev-mapper-cryswap.swap entered failed state.

Die Fehlermeldung "Das Argument ist ungültig" ist mehr oder weniger hilfreich . Also nochmal das cryptdevice von Hand starten:

Code: Alles auswählen

# cryptdisks_start cryswap
[....] Starting crypto disk...[....] cryswap: LUKS does not work with random dat[warnkey ... (warning).
[FAILap (invalid key)...failed.
# systemctl status cryptsetup.target
● cryptsetup.target - Encrypted Volumes
   Loaded: loaded (/lib/systemd/system/cryptsetup.target; static)
   Active: inactive (dead)
     Docs: man:systemd.special(7)

Apr 22 13:32:37 deb8v systemd[1]: Dependency failed for Encrypted Volumes.

Daher weht der Wind: LUKS läuft nicht mit dem "/dev/urandom"-Device. Dann probiere ich es mal mit einem Schlüssel und ändere die crypttab:

Code: Alles auswählen

# dd if=/dev/urandom of=/root/secret.key bs=512 skip=4 count=16
# chmod o-r secret.key
# vi /etc/crypttab
# <target name> <source device>         <key file>      <options>
cryswap  /dev/sda3  /root/secret.key  swap,noearly

Das kann man jetzt von Hand mal ausprobieren:

Code: Alles auswählen

# swapoff -a
# cryptdisks_start cryswap
# blkid
/dev/sda1: UUID="CAAA-CE53" TYPE="vfat" PARTUUID="eea2d2ca-55bb-4a4f-80bb-d1e3d1b244f3"
/dev/sda2: UUID="57e41b29-16c5-4632-9737-bbef97e3b0f4" TYPE="ext4" PARTUUID="00eba288-bd0d-4498-aa70-aa4aa394b8e7"
/dev/mapper/cryswap: UUID="268c2aee-0fe8-44aa-a092-0f9f55e3471e" TYPE="swap"
/dev/sda3: PARTUUID="49d29a1b-1091-4e7b-97c2-4e231a0ae232"
# cryptsetup status cryswap
/dev/mapper/cryswap is active.
  type:    PLAIN
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  device:  /dev/sda3
  offset:  0 sectors
  size:    4186112 sectors
  mode:    read/write
# reboot

Das funktioniert jetzt, auch nach einem Neustart.
Es gibt aber immer noch Fehlermeldungen:

Code: Alles auswählen

[...]
Apr 22 13:41:37 deb8v kernel: device-mapper: uevent: version 1.0.3
Apr 22 13:41:37 deb8v kernel: device-mapper: ioctl: 4.27.0-ioctl (2013-10-30) initialised: dm-devel@redhat.com
Apr 22 13:41:37 deb8v systemd-cryptsetup[225]: Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/sda3.
Apr 22 13:41:37 deb8v swapon[224]: swapon: /dev/sda3: read swap header failed
Apr 22 13:41:37 deb8v systemd[1]: dev-sda3.swap swap process exited, code=exited status=255
[...]
Apr 22 13:41:37 deb8v systemd[1]: Failed to activate swap Swap Partition.
Apr 22 13:41:37 deb8v systemd[1]: Dependency failed for Swap.
Apr 22 13:41:37 deb8v systemd[1]: Unit dev-sda3.swap entered failed state.
Apr 22 13:41:37 deb8v kernel: sha256_ssse3: Using AVX optimized SHA-256 implementation
Apr 22 13:41:37 deb8v swapon[305]: swapon: /dev/mapper/cryswap: swapon failed: Das Argument ist ungültig
Apr 22 13:41:37 deb8v systemd[1]: dev-mapper-cryswap.swap swap process exited, code=exited status=255
Apr 22 13:41:37 deb8v systemd[1]: Failed to activate swap /dev/mapper/cryswap.
Apr 22 13:41:37 deb8v systemd[1]: Unit dev-mapper-cryswap.swap entered failed state.
Apr 22 13:41:37 deb8v mkswap[304]: mkswap: /dev/mapper/cryswap: warning: wiping old swap signature.
Apr 22 13:41:37 deb8v mkswap[304]: Setting up swapspace version 1, size = 2093052 KiB
Apr 22 13:41:37 deb8v mkswap[304]: no label, UUID=ede435e4-77b0-400e-846d-822f1e20bd73
[...]
Apr 22 13:41:37 deb8v systemd-cryptsetup[225]: Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/sda3.
Apr 22 13:41:37 deb8v swapon[224]: swapon: /dev/sda3: read swap header failed
Apr 22 13:41:37 deb8v systemd[1]: dev-sda3.swap swap process exited, code=exited status=255
[...]
Apr 22 13:41:37 deb8v systemd[1]: Failed to activate swap Swap Partition.
Apr 22 13:41:37 deb8v systemd[1]: Dependency failed for Swap.

Unsinnigerweise wird das swapon auch für /dev/sda3 mehrmals ausgeführt, aber kein einziges mkswap auf diesem Device. In der Manpage von Debian gibt es den Parameter "noearly": "With this option the device is ignored during the first invocation of the cryptsetup init scripts.". Setzt man das in der crypttab ein gibt es im Log einen Fehler:

Code: Alles auswählen

Apr 22 13:49:21 deb8v systemd-cryptsetup[227]: Encountered unknown /etc/crypttab option 'noearly', ignoring.

Aha, die Realität hat sich ein Stück von dieser Manpage entfernt, das hatte ich mir schon gedacht. In den "anderen" Manpages, von systemd, gibt es diesen Parameter ja auch nicht mehr. Wir haben also eine Version systemd[215] und eine Manpage aus einer anderen Realität.

Gruss, habakug

[NAB]

Code: Alles auswählen

Apr 22 13:32:37 deb8v systemd-cryptsetup[263]: Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/sda3.

Wo mag systemd-crypsetup diese Parameter herhaben?

[habakug]

Hallo!

Das ist PLAIN in Default-Einstellungen, das von swap impliziert wird.

Code: Alles auswählen

# cryptsetup status cryswap
/dev/mapper/cryswap is active.
  type:    PLAIN
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  device:  /dev/sda3
  offset:  0 sectors
  size:    4186112 sectors
  mode:    read/write

Ich erkläre es nochmal anders. Wenn du in der crypttab die Optionen "luks,swap" oder "swap,luks" verwendest, wird mit zwei Geräten rumgefummelt. swap ist also immer PLAIN, wird nichts weiter angegeben defaultet es zu obigem ("A cipher with unpredictable IV values, such as "aes-cbc-essiv:sha256", is recommended."). Da kommt der systemd-cryptsetup-generatort wohl aus dem Tritt. Da der Debian-Installer scheinbar solche Einträge generiert hat, kommen jetzt nach und nach einige Systeme ins Schleudern. Ein anderes Problem sind Anleitungen im Netz, die lange nicht mehr geprüft wurden.

Gruss, habakug

[NAB]

Okay ... schreibe ich also "luks,swap", so übersieht er das "luks", schmeißt keine Fehlermeldung, öffnet das Device plain, fantasiert sich ein Passwort zusammen und schrottet den LUKS-Header mit einem "mkswap".

Schreibe ich hingegen "swap,luks", so übersieht er das "luks", schmeißt keine Fehlermeldung, öffnet das Device plain, fantasiert sich ein Passwort zusammen, übersieht danach das "swap" und führt daher auch kein "mkswap" aus. Danach fällt ihm das "swap" plötzlich wieder ein und er führt ein "swapon" durch, welches scheitert, da kein Swap-Header vorhanden ist. Das retten dann den LUKS-Header.

Und schreibe ich "swap,noearly", so öffnet er das Device plain mit einem Passwort, das er vielleicht aus deinem keyfile geholt hat, übersieht danach das "swap" und führt daher auch kein "mkswap" aus und vergissst völlig, dass er irgendwas mit Crypto machen soll. Plötzlich merkt er, dass er was vergessen hat und probiert erst ein Swapon auf der nackten Partition und dann auf dem entschlüsselten Container, welches beides fehlschlägt, da er kein mkswap durchgeführt hat. Dann kommt er endlich auf die rettende Idee, ein mkswap auf dem Cryptcontainer durchzuführen. Dann hat er aber auch schon wieder vergessen, dass er was mit Crypto macht und probiert ein Swapon auf der nackten Partition, welches wieder fehlschlägt.

Ist das so richtig?

[habakug]

Hallo!

Der fstab-Generator erzeugt diese Dateien:

Code: Alles auswählen

# dir=$(mktemp -d)
# SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/system-generators/systemd-fstab-generator "$dir" "$dir" "$dir"
Parsing /etc/fstab
Found entry what=/dev/disk/by-uuid/57e41b29-16c5-4632-9737-bbef97e3b0f4 where=/ type=ext4
Found entry what=/dev/disk/by-uuid/CAAA-CE53 where=/boot/efi type=vfat
Checking was requested for /dev/disk/by-uuid/CAAA-CE53, but fsck.vfat does not exist: No such file or directory
Found entry what=/dev/mapper/cryswap where=none type=swap
Found entry what=/dev/sr0 where=/media/cdrom0 type=udf,iso9660
# ls /tmp/tmp.uxSVkaa80S/
boot-efi.mount	dev-mapper-cryswap.swap  local-fs.target.requires  local-fs.target.wants  media-cdrom0.mount  -.mount  swap.target.wants
# egrep -r -e 'crys|sda3' /tmp/tmp.uxSVkaa80S/
/tmp/tmp.uxSVkaa80S/dev-mapper-cryswap.swap:What=/dev/mapper/cryswap

Der cryptsetup-Generator diese:

Code: Alles auswählen

# dir=$(mktemp -d)
# SYSTEMD_LOG_LEVEL=debug /usr/lib/systemd/system-generators/systemd-cryptsetup-generator "$dir" "$dir" "$dir"
# ls /tmp/tmp.agvx7Opnm5/
cryptsetup.target.requires	    dev-sda3.device.wants
dev-mapper-cryswap.device.d	    systemd-cryptsetup@cryswap.service
# ls /tmp/tmp.qaz3M8Op1h/
cryptsetup.target.requires  dev-mapper-cryswap.device.d  dev-mapper-cryswap.device.requires  dev-sda3.device.wants  systemd-cryptsetup@cryswap.service
root@deb8v:~# egrep -r -e 'crys|sda3' /tmp/tmp.qaz3M8Op1h/
/tmp/tmp.qaz3M8Op1h/systemd-cryptsetup@cryswap.service:BindsTo=dev-sda3.device
/tmp/tmp.qaz3M8Op1h/systemd-cryptsetup@cryswap.service:After=dev-sda3.device
/tmp/tmp.qaz3M8Op1h/systemd-cryptsetup@cryswap.service:ExecStart=/lib/systemd/systemd-cryptsetup attach 'cryswap' '/dev/sda3' '/root/secret.key' 'swap'
/tmp/tmp.qaz3M8Op1h/systemd-cryptsetup@cryswap.service:ExecStop=/lib/systemd/systemd-cryptsetup detach 'cryswap'
/tmp/tmp.qaz3M8Op1h/systemd-cryptsetup@cryswap.service:ExecStartPost=/sbin/mkswap '/dev/mapper/cryswap'

Bei hochgeschraubtem Loglevel kann man im journal folgendes für das erfolgreiche Anlegen der verschlüsselten swap sehen:

Code: Alles auswählen

# journalctl | grep -e 'crys'
Apr 22 21:18:11 deb8v systemd[1]: Installed new job systemd-cryptsetup@cryswap.service/start as 19
Apr 22 21:18:11 deb8v systemd[1]: Installed new job dev-mapper-cryswap.device/start as 20
Apr 22 21:18:11 deb8v systemd[1]: Installed new job dev-mapper-cryswap.swap/start as 21
Apr 22 21:18:11 deb8v systemd[1]: Expecting device dev-mapper-cryswap.device...
Apr 22 21:18:12 deb8v systemd[1]: Starting Cryptography Setup for cryswap...
Apr 22 21:18:12 deb8v systemd[1]: About to execute: /lib/systemd/systemd-cryptsetup attach cryswap /dev/sda3 /root/secret.key swap
Apr 22 21:18:12 deb8v systemd[1]: systemd-cryptsetup@cryswap.service changed dead -> start
Apr 22 21:18:12 deb8v systemd[277]: Executing: /lib/systemd/systemd-cryptsetup attach cryswap /dev/sda3 /root/secret.key swap
Apr 22 21:18:12 deb8v systemd[1]: Failed to send unit change signal for systemd-cryptsetup@cryswap.service: Transport endpoint is not connected
Apr 22 21:18:12 deb8v systemd[1]: Child 277 belongs to systemd-cryptsetup@cryswap.service
Apr 22 21:18:12 deb8v systemd[1]: systemd-cryptsetup@cryswap.service: main process exited, code=exited, status=0/SUCCESS
Apr 22 21:18:12 deb8v systemd[1]: About to execute: /sbin/mkswap /dev/mapper/cryswap
Apr 22 21:18:12 deb8v systemd[1]: systemd-cryptsetup@cryswap.service changed start -> start-post
Apr 22 21:18:12 deb8v systemd[1]: Failed to send unit change signal for systemd-cryptsetup@cryswap.service: Transport endpoint is not connected
Apr 22 21:18:12 deb8v systemd[1]: dev-mapper-cryswap.device changed dead -> plugged
Apr 22 21:18:12 deb8v systemd[1]: Job dev-mapper-cryswap.device/start finished, result=done
Apr 22 21:18:12 deb8v mkswap[311]: mkswap: /dev/mapper/cryswap: warning: wiping old swap signature.
Apr 22 21:18:12 deb8v systemd[311]: Executing: /sbin/mkswap /dev/mapper/cryswap
Apr 22 21:18:12 deb8v systemd[1]: Found device /dev/mapper/cryswap.
Apr 22 21:18:12 deb8v systemd[1]: dev-disk-by\x2did-dm\x2duuid\x2dCRYPT\x2dPLAIN\x2dcryswap.device changed dead -> plugged
Apr 22 21:18:12 deb8v systemd[1]: dev-disk-by\x2did-dm\x2dname\x2dcryswap.device changed dead -> plugged
Apr 22 21:18:12 deb8v systemd[1]: Activating swap /dev/mapper/cryswap...
Apr 22 21:18:12 deb8v systemd[1]: About to execute: /sbin/swapon /dev/mapper/cryswap
Apr 22 21:18:12 deb8v systemd[1]: dev-mapper-cryswap.swap changed dead -> activating
Apr 22 21:18:12 deb8v systemd[1]: Child 311 belongs to systemd-cryptsetup@cryswap.service
Apr 22 21:18:12 deb8v systemd[1]: systemd-cryptsetup@cryswap.service: control process exited, code=exited status=0
Apr 22 21:18:12 deb8v systemd[1]: systemd-cryptsetup@cryswap.service got final SIGCHLD for state start-post
Apr 22 21:18:12 deb8v systemd[1]: systemd-cryptsetup@cryswap.service changed start-post -> exited
Apr 22 21:18:12 deb8v systemd[1]: Job systemd-cryptsetup@cryswap.service/start finished, result=done
Apr 22 21:18:12 deb8v systemd[316]: Executing: /sbin/swapon /dev/mapper/cryswap
Apr 22 21:18:12 deb8v kernel: Adding 2093052k swap on /dev/mapper/cryswap.  Priority:-1 extents:1 across:2093052k FS
Apr 22 21:18:12 deb8v systemd[1]: Started Cryptography Setup for cryswap.
Apr 22 21:18:12 deb8v systemd[1]: systemd-cryptsetup@cryswap.service: cgroup is empty
Apr 22 21:18:12 deb8v systemd[1]: Child 316 belongs to dev-mapper-cryswap.swap
Apr 22 21:18:12 deb8v systemd[1]: dev-mapper-cryswap.swap swap process exited, code=exited status=0
Apr 22 21:18:12 deb8v systemd[1]: dev-mapper-cryswap.swap changed activating -> active
Apr 22 21:18:12 deb8v systemd[1]: Job dev-mapper-cryswap.swap/start finished, result=done
Apr 22 21:18:12 deb8v systemd[1]: Activated swap /dev/mapper/cryswap.
Apr 22 21:18:12 deb8v systemd[1]: dev-disk-by\x2did-dm\x2duuid\x2dCRYPT\x2dPLAIN\x2dcryswap.swap changed dead -> active
Apr 22 21:18:12 deb8v systemd[1]: dev-disk-by\x2did-dm\x2dname\x2dcryswap.swap changed dead -> active

Hier ist ein zweiter Ableger am Werk, der scheinbar dasselbe versucht:

Code: Alles auswählen

# journalctl | grep sda3
Apr 22 21:18:11 deb8v kernel:  sda: sda1 sda2 sda3
Apr 22 21:18:11 deb8v systemd[1]: Installed new job dev-sda3.swap/start as 17
Apr 22 21:18:11 deb8v systemd[1]: Installed new job dev-sda3.device/start as 18
Apr 22 21:18:11 deb8v systemd[1]: Expecting device dev-sda3.device...
Apr 22 21:18:11 deb8v systemd[1]: dev-sda3.device changed dead -> plugged
Apr 22 21:18:11 deb8v systemd[1]: Job dev-sda3.device/start finished, result=done
Apr 22 21:18:11 deb8v systemd[1]: sys-devices-pci0000:00-0000:00:0a.0-ata3-host3-target3:0:0-3:0:0:0-block-sda-sda3.device changed dead -> plugged
Apr 22 21:18:11 deb8v systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/unit/dev_2dsda3_2edevice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=10 reply_cookie=0 error=n/a
Apr 22 21:18:11 deb8v systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1/unit/dev_2dsda3_2edevice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=11 reply_cookie=0 error=n/a
Apr 22 21:18:12 deb8v systemd[1]: About to execute: /sbin/swapon /dev/sda3
Apr 22 21:18:12 deb8v systemd[1]: dev-sda3.swap changed dead -> activating
Apr 22 21:18:12 deb8v swapon[271]: swapon: /dev/sda3: read swap header failed
Apr 22 21:18:12 deb8v systemd[271]: Executing: /sbin/swapon /dev/sda3
Apr 22 21:18:12 deb8v systemd[1]: About to execute: /lib/systemd/systemd-cryptsetup attach cryswap /dev/sda3 /root/secret.key swap
Apr 22 21:18:12 deb8v systemd[277]: Executing: /lib/systemd/systemd-cryptsetup attach cryswap /dev/sda3 /root/secret.key swap
Apr 22 21:18:12 deb8v systemd[1]: Failed to send unit change signal for dev-sda3.swap: Transport endpoint is not connected
Apr 22 21:18:12 deb8v systemd[1]: Child 271 belongs to dev-sda3.swap
Apr 22 21:18:12 deb8v systemd[1]: dev-sda3.swap swap process exited, code=exited status=255
Apr 22 21:18:12 deb8v systemd[1]: dev-sda3.swap changed activating -> failed
Apr 22 21:18:12 deb8v systemd[1]: Job dev-sda3.swap/start finished, result=failed
Apr 22 21:18:12 deb8v systemd-cryptsetup[277]: Set cipher aes, mode cbc-essiv:sha256, key size 256 bits for device /dev/sda3.
Apr 22 21:18:12 deb8v systemd[1]: Unit dev-sda3.swap entered failed state.
Apr 22 21:18:12 deb8v systemd[1]: Failed to send unit change signal for dev-sda3.swap: Transport endpoint is not connected

Fragt man den Status ab, liegt es am fehlenden swap-Header.

Code: Alles auswählen

# systemctl status dev-sda3.swap
● dev-sda3.swap - Swap Partition
   Loaded: loaded (/run/systemd/generator.late/dev-sda3.swap)
   Active: failed (Result: exit-code) since Fr 2016-04-22 21:18:12 CEST; 31min ago
     What: /dev/sda3
     Docs: man:systemd-gpt-auto-generator(8)
  Process: 271 ExecActivate=/sbin/swapon /dev/sda3 (code=exited, status=255)

Apr 22 21:18:12 deb8v swapon[271]: swapon: /dev/sda3: read swap header failed

Doch es gibt einen Hinweis: "Docs: man:systemd-gpt-auto-generator(8)". Achso, da erkennt noch einer swap-Partitionen direkt auf der Platte. Stimmt, da ist noch die swap-ID:

Code: Alles auswählen

# fdisk -l
[...]
Disklabel type: gpt
Disk identifier: A6EE12AC-B753-4780-8DB0-D5C7A1490CAA
[...]
/dev/sda3  6297600 10483711 4186112    2G Linux swap

Das ändere ich mal:

Code: Alles auswählen

/dev/sda3  6297600 10483711 4186112    2G Linux server data

OK, nach einem Reboot ist der Spuk vorbei:

Code: Alles auswählen

# systemctl status dev-sda3.swap
● dev-sda3.swap - /dev/sda3
   Loaded: loaded
   Active: inactive (dead)
     What: /dev/sda3

Also doch ein Bedienfehler. Die zu verschlüsselnde swap-Partition darf keine swap-Signatur bzw. ID 83 haben, sonst mischt sich da eins der vielen Helferlein ein. Nach diesem Griff in ein Fass ohne Boden bin ich allerdings zu erschöpft, um jetzt noch zu prüfen, ob das auch Einfluss auf die Parameter in der crypttab hat.

Gruss, habakug

[debianoli]

Also doch ein Bedienfehler. Die zu verschlüsselnde swap-Partition darf keine swap-Signatur bzw. ID 83 haben, sonst mischt sich da eins der vielen Helferlein ein. Nach diesem Griff in ein Fass ohne Boden bin ich allerdings zu erschöpft, um jetzt noch zu prüfen, ob das auch Einfluss auf die Parameter in der crypttab hat.

Erstmal ein Danke für die ausführliche Fehlersuche!

Heißt das, dass man einem verschlüsselten Swap-Device keine Swap-Signatur geben darf, um den Fehler auszuschalten? Das Blöde ist nur, dass ich das alles über den Installer gemacht habe. Folgt daraus, dass der Installer diesen Sonderfall nicht richtig implantiert hat oder ist einfach systemd hier zu eifrig?

[NAB]

debianoli, du solltest vorallem die Schlüsselworte "plain", "swap", "tmp" in der /etc/crypttab vermeiden, sonst schrottet er dir ohne Warnung deinen LUKS-Header.

Weiterhin ist ein "swap" bei einer LUKS-Verschlüsselung auch ziemlich sinnlos und macht dir Suspend-to-Disk kaputt.

Der installer selber möchte übrigens, dass du nur _eine_ verschlüsselte Partition anlegst, und da rein ein LVM, und da rein dann root/home/swap. Das läuft anscheinend selbst unter Systemd zuverlässig, sonst gäbe es hier mehr Beschwerden.

[debianoli]

Ich wollte aber kein LVM, da ich darin keinen Sinn bei einem Laptop sehe. Es kommen keine Platten dazu und man muss keine Partition vergrößern oder verkleinern.

Blöderweise legt mit der Installer die Einträge in der crypttab dann mit swap,luks an. Ist nicht auf meinem Mist gewachsen und ich prüfe eigentlich keine configs nach einer Installation, wenn alles scheinbar funktioniert.

Ich habe das jetzt durch 2 luks-Partitionen gelöst, von denen ich eine nach dem entschlüsseln als Swap einbinde. Das funktioniert.

Weiterhin ist ein "swap" bei einer LUKS-Verschlüsselung auch ziemlich sinnlos und macht dir Suspend-to-Disk kaputt.

Das erklärt auch einiges.

[NAB]

Ich wollte aber kein LVM, da ich darin keinen Sinn bei einem Laptop sehe. Es kommen keine Platten dazu und man muss keine Partition vergrößern oder verkleinern.

Tja ... versteh ich ... deswegen habe ich auf LVM und auf Systemd verzichtet.

Aber der wahre Vorteil von LVM ist hier, dass du gewisssermaßen Partitionen innerhalb einer Partition haben kannst. Darum nimmt der Installer bei Crypt auch immer LVM. So hast du nur einen Crypt-Container. Gerade auf einem Laptop, wo du wohl weder Swap noch Home auf eine andere Platte auslagern willst, ist das sinnvoll.

[debianoli]

Es gibt noch eine Grund, der bei mir gegen LVM spricht: Ich habe es nicht hinbekommen, bei einer verschlüsselten Partition mit LVM auf eine weitere Partition (im LVM) mit einem Test-System einzurichten.

Geht nicht über den Debian-Installer und auch nicht per debootstrap. Es gab immer Probleme beim Hochfahren, das Passwort für die Entschlüsselung wurde nicht angenommen (ist etwas länger her, ich muss die Threads erst wieder suchen). ich habe das dann aufgegeben und nutze seitdem die Lösung ohne LVM.

[NAB]

Ich habe es nicht hinbekommen, bei einer verschlüsselten Partition mit LVM auf eine weitere Partition (im LVM) mit einem Test-System einzurichten.

Diesen Satz habe ich nicht verstanden.

[debianoli]

viewtopic.php?f=12&t=156491
viewtopic.php?f=12&t=156968

Kurze Beschreibung,was ich damals machen wollte: Ich habe eine Laptop mit UEFI, auf dem eine Standardinstallation mit Verschlüsselung und LVM darin lief. Dort wollte ich das installierte Debian klonen, um es als Testpartition für Testing oder SID zu nutzen (macht ja Sinn, man kann rumspielen und hat weiterhin ein laufendes System).

Nur: Das ging nicht. Hochfahren hat nicht geklappt. Das gleiche Spiel bei einer Installation per debootstrap in eine Test-Partition im LVM.

Hochfahren ging in beiden Fällen nicht, obwohl so etwas wie Klonen ohne LVM kein Problem ist. Da fehlte wohl jedes mal etwas in der iniramfs und ich habe meinen Fehler nicht gefunden.
Ich habe es dann bleiben lassen und habe die obige Variante wieder eingerichtet, da ich die Verschlüsselung primär als Schutz meiner Daten bei einem Diebstahl des Laptops brauche. Für alle anderen Angriffe auf ein unverschlüsseltes System bin ich nicht wichtig genug

[NAB]

Nach kurzem Überfliegen ... ohne eigene Boot-Partition für den Clone würd ich Chaos erwarten. Ansonsten gibst du ja nicht an, wie du den Clone genau angepasst hast.

Aber hier ging's ja um den Laptop einer Bekannten ... die sollte mit LVM gut bedient sein. Bei allem anderen ist fraglich, ob Debian ein sauberes Upgrade auf Stretch mit Systemd hinbekommt.

[debianoli]

Der Laptop meiner Bekannter ist auch soweit wieder ok und bis zum Upgrade auf Stretch dürfte es auch noch einige Zeit dauern... Wenn dann mit meiner Lösung Probleme Auftreten, weiß ich zumindest, wo ich suchen muss.