cryptsetup will nicht mehr entschlüsseln?

[Bytechanger]

Hallo,

bisher hatte ich keine Probleme. Ich habe an einem Raspi (Debian Jessie) eine USB Festplatte installiert und diese mit

Code: Alles auswählen

cryptsetup -q -y luksFormat /dev/sda1
 ls -al /dev/mapper/bu_crypt
neue Partition formatieren:  mkfs.ext4 /dev/mapper/bu_crypt

Mountpunkt festlegen: mkdir /mnt/bu_crypt
Device Mounten: mount /dev/mapper/bu_crypt /mnt/bu_crypt

angelegt.
Wenn ich aber jetzt meine Partition mit

Code: Alles auswählen

cryptsetup luksOpen /dev/sda1 crypt
encrypten möchte, bekomme ich nach der Kennworteingabe folgende Meldung:
Code: Alles markieren
Geben Sie die Passphrase für »/dev/sda1« ein:
Einrichten der dm-crypt-Schlüsselzuordnung für Gerät »/dev/sda1« fehlgeschlagen.
Stellen Sie sicher, dass der Kernel die aes-cbc-essiv:sha256-Verschlüsselung unterstützt.
(Sehen Sie im System-Log nach, ob sich dort Hinweise finden.)

Was läuft hier plötzlich falsch?
Wie kann ich das beheben?

Greets

Byte

[smutbert]

vor allen Dingen könntest du erwähnen, dass es sich um einen Crosspost handelt:
http://www.forum-raspberrypi.de/Thread- ... nicht-mehr

[DeletedUserReAsG]

Code: Alles auswählen

Stellen Sie sicher, dass der Kernel die aes-cbc-essiv:sha256-Verschlüsselung unterstützt.
(Sehen Sie im System-Log nach, ob sich dort Hinweise finden.)

Was genau ist daran unverständlich? (abgesehen von deinen Codeblöcken, da scheint dir beim Posten so einiges durcheinandergeraten zu sein)

[Benno007]

Willkommen!

Wenn du Kernel selber kompilierst, musst du die nötigen Module in der Konfiguration angeben und mit update-initramfs wie folgt updaten (Beispiel Ubuntu):

https://wiki.ubuntuusers.de/System_vers ... m-wechseln

Ab da bis fast ganz runter, vorher mit z.B. Chroot-Notfallstick rein (Chroot ist verlinkt).

[Bytechanger]

Hallo,

also unverständlich ist, dass ich das normale "Raspbian Jessie" Image verwende (also keinen Kernel selber kompiliert) und es bisher bereits funktioniert hat!
Jetzt, plötzlich, erhalte ich die Fehlermeldung (nach einem Raspi-Neustart, vermute ich).

Wenn der Raspi läuft, entsperre ich über SSH-Konsole die Festplatte. Einmal im Monat startet der Raspi neu. Dies war nun der Fall.
Das Laufwerk lässt sich jetzt nicht mehr entsperren. Vielleicht hat ein Update dazwischen gehauen.

Was muss ich jetzt machen, damit es wieder läuft??
Benötige Hilfe, danke!


Greets

Byte

[Benno007]

Probier es mal mit einem älteren Kernel aus dem Grub-Menü. Viel Glück.

[DeletedUserReAsG]

Probier es mal mit einem älteren Kernel aus dem Grub-Menü.

Es handelt sich um einen Pi, wie im Eingangsbeitrag zu lesen ist – dort gibt es kein Grub (und es lässt sich auch nicht ohne Weiteres von USB-Sticks booten, btw.).

Den vorherigen Kernel kann man dennoch mal probieren, wenn es nach Beachtung des von mir gequoteten Teils noch nicht funktionieren sollte. Allerdings muss man dann auch Sorge dafür tragen, dass sich die dazugehörigen Module unter /lib/modules/… befinden – sonst hat man genau das gleiche Problem weiterhin, weil das entsprechende Modul nicht geladen werden kann.

[Bytechanger]

Hallo,

ich bin mir nicht sicher, ob ich so fit bin, dass zu machen.
Also, wenn ich es richtig verstanden habe, ist das Problem, dass bei einem dist-upgrade der Kernel geuppt wurde?
Im neuen Kernel wird die verwendete Verschlüsselung nicht unterstützt?
Bisher war dies aber die Standardverschlüsselung für cryptsetup.
Wenn das so wäre, würde mir das aber auch Sorgen für die Zukunft machen (Plötzliches Umstellen / löschen des verwendeten Verschlüsselungsalgo.)

Derzeit verwende ich diesen Raspi als Backupziel. D.h. die Kiste steht bei meinem Schwiegervater und erhält wichtige Daten über Nacht...

Ich habe mal ins syslog geschaut, konnte dort aber keinen Eintrag finden. Kann ich irgendwo verifizieren, ob der Kernel die Verschlüsselung nicht
mehr unterstzützt?

Greets

Byte

[DeletedUserReAsG]

In der Regel muss nur das entsprechende Modul geladen werden. Naheliegenderweise ist’s eines mit ›sha256‹ im Namen – nach dem String kann man dann mal unter /lib/modules suchen, und infragekommende Module testweise laden. Was momentan zur Verfügung steht, kann man etwa in /proc/crypto nachlesen.

Da es sich aber eben nicht um Debian handelt, was auf deinem Pi läuft, kann man da nur mutmaßen. Die Dürftigkeit der Informationen von dir trägt auch nicht gerade zu einer Verbesserung der Situation bei – keine Infos über: welches System in welcher Version mit welchem Kernel (mit welchen geladenen Modulen) auf welcher Hardware läuft genau, wie geupdated, welche Meldungen gab es dabei, was steht in den Logs (wenn man selbst nicht in der Lage ist, das zu interpretieren, schiebt man’s eben irgendwo hoch, wo jemand drüberschauen könnte, der sich damit auskennt …), gibt es einen spezifischen Logeintrag (dmesg) beim Versuch, die Partition zu entschlüsseln, was genau wird bei dem Versuch ein- und ausgegeben (wie geschrieben: der entsprechende Teil im Eingangsbeitrag ist eindeutig kaputt), …

[wanne]

Zuerstmal: Man nutzt Rasspian ja genau wegen des eigenen Kernels. (Weil das PI etwas obskure Hardware hat, die mit normalen Kerneln nicht läuft.)
Dein Problem ist also extrem PI bezogen. Wäre also an erster Stelle schon besser gewesen. Hättest du Debian am Laufen, hättest du das Problem nicht.
Das wie die den Kernel installieren, scheinen die Rasspian Leute auch ziemlich verkackt zu haben:

The modules being complained about here are less used filesystems, crypto, etc. Currently some of this stuff is compiled straight into the installer kernel and some modules are really missing. It shouldn't give you much problems though, only maybe if you choose to install to encrypted partition - that will probably fail.

Currently there is no standard Raspberry Pi kernel installer package. This issue is worked around by including the current kernel.img into installer initramfs and copying it to the Raspberry Pi boot partition directly after the installer is done.

Möglicherweise kannst du einfach gar keine Kernel-Module nutzen. Lediglich Sachen, die dei PIler fest einkompiliert haben.

Zuerstmal solltest du rausfinden, was du für einen Kernel hast:

Code: Alles auswählen

uname -r

Dann gucken, was für Kernelmodule nachgeladen werden können:
Die liegen im Ordner "/lib/modules/[DEIN KERNEL NAME]"
Wie du dir da selbst welche baust:
http://elinux.org/RPi_Kernel_Compilation
https://www.grendelman.net/wp/compiling ... pberry-pi/

/lib/modules/

[Bytechanger]

Sorry,

spärliche Infos sind nicht böswillig, sondern meinem newbie-Wissen in Linux...

uname -r
4.1.18-v7+

Code: Alles auswählen

cat /proc/crypto
cat /proc/crypto
name         : cbc(aes)
driver       : cbc(aes-generic)
module       : kernel
priority     : 100
refcnt       : 1
selftest     : passed
internal     : no
type         : givcipher
async        : no
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : eseqiv

name         : cbc(aes)
driver       : cbc(aes-generic)
module       : kernel
priority     : 100
refcnt       : 1
selftest     : passed
internal     : no
type         : blkcipher
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : stdrng
driver       : krng
module       : kernel
priority     : 200
refcnt       : 2
selftest     : passed
internal     : no
type         : rng
seedsize     : 0

name         : crc32c
driver       : crc32c-generic
module       : kernel
priority     : 100
refcnt       : 2
selftest     : passed
internal     : no
type         : shash
blocksize    : 1
digestsize   : 4

name         : aes
driver       : aes-generic
module       : kernel
priority     : 100
refcnt       : 1
selftest     : passed
internal     : no
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

name         : des3_ede
driver       : des3_ede-generic
module       : kernel
priority     : 100
refcnt       : 1
selftest     : passed
internal     : no
type         : cipher
blocksize    : 8
min keysize  : 24
max keysize  : 24

name         : des
driver       : des-generic
module       : kernel
priority     : 100
refcnt       : 1
selftest     : passed
internal     : no
type         : cipher
blocksize    : 8
min keysize  : 8
max keysize  : 8

dmesg

Code: Alles auswählen

[    4.461811] systemd[1]: Listening on Syslog Socket.
[    4.469098] systemd[1]: Starting Journal Service...
[    4.486094] systemd[1]: Started Journal Service.
[    4.669391] systemd-udevd[112]: starting version 215
[    5.573244] EXT4-fs (mmcblk0p6): re-mounted. Opts: (null)
[    6.082353] bcm2835-rng 3f104000.rng: hwrng registered
[    6.090413] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000
[    6.238735] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
[    6.254784] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    6.713096] systemd-journald[110]: Received request to flush runtime journal from PID 1
[    6.996961] ip_tables: (C) 2000-2006 Netfilter Core Team
[    7.021389] nf_conntrack version 0.5.0 (14813 buckets, 59252 max)
[    7.755854] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[    7.765096] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[    8.434576] usb 1-1.3: new high-speed USB device number 4 using dwc_otg
[    8.556125] usb 1-1.3: New USB device found, idVendor=1058, idProduct=1110
[    8.565821] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    8.575772] usb 1-1.3: Product: My Book 1110
[    8.581412] usb 1-1.3: Manufacturer: Western Digital
[    8.587737] usb 1-1.3: SerialNumber: 57434XXXXX03734XX34
[    8.595857] usb-storage 1-1.3:1.0: USB Mass Storage device detected
[    8.610721] scsi host0: usb-storage 1-1.3:1.0
[    8.839327] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[    9.615670] scsi 0:0:0:0: Direct-Access     WD       My Book 1110     2003 PQ: 0 ANSI: 4
[    9.628571] scsi 0:0:0:1: CD-ROM            WD       Virtual CD 1110  2003 PQ: 0 ANSI: 4
[    9.641125] sd 0:0:0:0: [sda] 1952151552 512-byte logical blocks: (1000 GB/931 GiB)
[    9.644776] scsi 0:0:0:2: Enclosure         WD       SES Device       2003 PQ: 0 ANSI: 4
[    9.667963] sd 0:0:0:0: [sda] Write Protect is off
[    9.674177] sd 0:0:0:0: [sda] Mode Sense: 23 00 10 00
[    9.678023] sd 0:0:0:0: [sda] No Caching mode page found
[    9.684806] sd 0:0:0:0: [sda] Assuming drive cache: write through
[    9.686407] sr 0:0:0:1: [sr0] scsi3-mmc drive: 51x/51x caddy
[    9.686416] cdrom: Uniform CD-ROM driver Revision: 3.20
[    9.688042] sr 0:0:0:1: Attached scsi CD-ROM sr0
[    9.692759] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    9.693112] sr 0:0:0:1: Attached scsi generic sg1 type 5
[    9.693455] scsi 0:0:0:2: Attached scsi generic sg2 type 13
[    9.746296] random: nonblocking pool is initialized
[    9.797549]  sda: sda1
[    9.807640] sd 0:0:0:0: [sda] Attached SCSI disk
[   42.605072] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[   42.629161] NFSD: starting 90-second grace period (net 8086d7c0)
[   43.882437] tun: Universal TUN/TAP device driver, 1.6
[   43.888819] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[101970.430703] usb 1-1.3: reset high-speed USB device number 4 using dwc_otg
[171021.956156] device-mapper: ioctl: 4.31.0-ioctl (2015-3-12) initialised: dm-devel@redhat.com
[171022.630680] NET: Registered protocol family 38

Rasp2

Code: Alles auswählen

cryptsetup luksOpen /dev/sda1 crypt
Geben Sie die Passphrase für »/dev/sda1« ein:
Einrichten der dm-crypt-Schlüsselzuordnung für Gerät »/dev/sda1« fehlgeschlagen.
Stellen Sie sicher, dass der Kernel die aes-cbc-essiv:sha256-Verschlüsselung unterstützt.
(Sehen Sie im System-Log nach, ob sich dort Hinweise finden.)

Werden noch weitere Infos benötigt?
Wie gesagt, keine Bösartigkeit, nur unwissen, sorry

Greets

Byte

[ChronoBoost]

Was läuft hier plötzlich falsch?

So wie es aussieht hat ein nicht rückwärtskompatibler Kernelpatch cryptsetup lahmgelegt. Es sind wohl eine ganze Reihe von Kerneln betroffen. U.a. auch Kernel 4.1.18 der momentan in raspbian verwendet wird.

Weitere Infos hier: https://www.spinics.net/lists/stable/msg120346.html

Wie kann ich das beheben?

• Einen älteren Kernel verwenden (4.1.17 funktionierte wohl noch)
• Einen der betroffenen Kernel selbst patchen (im o.g. Thread findet sich ein Patch) und neu compilieren
• Auf ein Update warten

[Bytechanger]

Hi,

danke für diese wertvolle Info. Habe ich also nichts falsch gemacht
Ich traue mir das patchen nicht zu (keine Anleitung).
Wie kann ich denn die vorherige Kernel-Version aufspielen?
Wie lange kann es erfahrungsgemäß dauern, bis ein Patch kommt? (Tage, Wochen, Monate)??


Greets

Byte

[Bytechanger]

Ok, habs

rpi-update 0764e7d78d30658f9bfbf40f8023ab95f952bcad

tat seinen Job,
bin damit zu 4.1.17 gesprungen, nun geht wieder, DANKE

( https://github.com/Hexxeh/rpi-firmware/ ... 95f952bcad )


Greets

Byte

[ChronoBoost]

Das letzte Update auf 4.1.19 hat den Fehler behoben.

Tip: Das aes_arm Modul für eine Geschwindigkeitssteigerung laden.