Welcome, Guest. Please login or register.
Did you miss your activation email?

Author Topic: [DE] luks, lvm und USB-Schlüssel  (Read 5325 times)

Roland

  • Guest
[DE] luks, lvm und USB-Schlüssel
« on: 2015/09/13, 03:15:39 »
Moin,

ich hoffe, das hier jemand eine Idee hat. Ich bin vor kurzem von Wheezy nach Siduction-Cinnamon umgestiegen. Meine Festplatte habe ich neu eingeteilt in eine Partition für /boot und eine für den Rest. Den Rest hab ich mit luks verschlüsselt und dann ein LVM für /root und swap aufgesetzt. So weit so gut.

Nun will ich aber wegen der Bequemlichkeit mit einem USB-Key aufschließen. Irgendwie klappt das mit dem Keyscript und dem Initramfs aber nicht so richtig. Ich habe bereits verschiedene Anleitungen durchgesehen, aber die sind ja alle irgendwie ähnlich.

Nach dem booten versucht das Init-System bei mir immer erst die VolumeGroup zu starten, das geht natürlich nicht weil die ja noch verschlüsselt ist. Erst danach fragt es mich nach der Passphrase. Ich habe zum Glück einen zweiten Schlüssel als Passphrase eingegeben, damit kann ich dann wenigstens hochfahren.

Ich hatte schon zu Wheezy-Zeiten ein ähnliches Konzept, nur ohne LVM. Da hat das mit dem USB-Sick immer sehr gut geklappt. An der Hardware liegt es nicht. Auch die neu erstellte Schlüssel-Datei funktioniert gut wenn ich ein Live-System verwende.

Das LVM und die Verschlüsselung habe ich wie hier im Wiki beschrieben (Variante2) erstellt. Die Schlüsseldatei habe ich als ganz normale Datei auf einem USB-Stick mit ext4 abgelegt. Das Keyscript ist in der Crypttab eingetragen, beim neu erstellen der Initram kommt keine Fehlermeldung. In der Busybox kann ich den Stick manuell mounten, daher möchte ich Treiber-Probleme ausschließen.

Das einzige was mir halt auffällt, ist die Reihenfolge. Erst einhängen und dann entschlüsseln geht nicht. Kann man das irgendwie beeinflussen? Oder gibt es eventuell einen komplett anderen Weg?

Roland

  • Guest
Re: luks, lvm und USB-Schlüssel
« Reply #1 on: 2015/09/21, 00:46:51 »
 Hallo,

ich habe nun wieder etwas Zeit gefunden, mich weiter mit der Materie zu beschäftigen. Ich habe eine aktuellere Anleitung gefunden: https://wiki.debianforum.de/Cryptsetup_mit_systemd_und_Schl%C3%BCssel_auf_externem_USB-Stick
Leider bei mir ohne gewünschte Wirkung. Damit werde ich nicht mehr nach der Passphrase gefragt, sondern es kommen Fehlermeldungen und ich lande direkt in der Busybox.

Das Problem mit dem USB-Schlüssel liegt also an Systemd. Mein Keyscript aus der Zeit von Wheezy wird ignoriert. Hier ist eine interessante Diskussion zu dem Thema: https://forum.ubuntuusers.de/topic/zweite-verschluesselte-festplatte-wird-nicht-m/2/ . Die Aussage, das Schlüssel auf externen Medien von Systemd nicht mehr vorgesehen sind, kann ich aber nicht so richtig nicht glauben.

Ich habe mal weiter geforscht und verschiedene Konstellationen in den Konfigdateien getestet, leider ohne Erfolg. Ich hatte ein Rootdelay in der /etc/default/grub eingebaut, das mounten über /etc/default/cryptdisks wars auch nicht.

Irgendwie nervt mich der tolle neue Systemd gerade etwas. Anstatt einfacher wird nun alles komplizierter. Als Anwender will ich ein Betriebssystem nicht erst neu programmieren. Ich habe nur an Wochenenden mal etwas Zeit und muss mich jetzt durch einen Dschungel von Konfigdateien durchwuseln. Auf die Festplattenverschlüsselung will ich nicht verzichten.

Ansonsten ist Siduction ein gutes System, vor allem aktuell. Das Prinzip mit dem Rolling Release gefällt mir.

Kennt sich jemand mit den einzelnen Konfig-Dateien aus für die Erstellung der Initramfs? Ich denke wenn ich die passende Datei finde, korrekt abändere und dann noch an den richtigen Ort platziere, wird mein USB-Schlüssel auch erkannt.

Danke schonmal für eventuelle Hilfestellungen,
Roland

Offline absolut

  • User
  • Posts: 455
Re: luks, lvm und USB-Schlüssel
« Reply #2 on: 2015/09/22, 13:05:49 »
ich persönlich habe mit dieser materie keine erfahrung, aber versuchen kann man es ja.

ich glaube aber, es ist jetzt relevant zu erfahren, was für fehlermeldungen denn kommen; wie deine konfiguration derzeit aussieht, usw... ohne diese info wird es mit der hilfe schwierig werden

Roland

  • Guest
Re: luks, lvm und USB-Schlüssel
« Reply #3 on: 2015/09/28, 01:48:39 »
 Danke an absolut für die angebotene Hilfe.

Ich habe mir heute mal Zeit genommen und versucht mich in die Welt des neuen Systemd einzulesen. Leider nicht wirklich erfolgreich.

Hier nun einige meiner Versuche:
Leider hat mein USB-Stick mit dem Schlüssel nicht lange durchgehalten, den Anfang des Sticks mit Zufallsdaten zu überschreiben scheint das Dateisystem nicht auf Dauer vertragen zu haben. Ich habe die Vorlage aus der oben genannten Webseite etwas abgewandelt und habe den Schlüssel an das unpartitionierte Ende kopiert. Ich habe das mal alles mitprotokolliert.

Kontrolle des USB-Stick:
Code: [Select]
# fdisk -l /dev/sdh
Disk /dev/sdh: 1,9 GiB, 2013265920 bytes, 3932160 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x054bdde4

Device     Boot Start     End Sectors  Size Id Type
/dev/sdh1  *     2048 3930111 3928064  1,9G  6 FAT16


Den Schlüssel, der bereits im Luksheader hinterlegt ist, auf den USB-Stick kopiert:
Code: [Select]
# dd if=/root/key of=/dev/sdh bs=512 seek=3930161
4+0 Datensätze ein
4+0 Datensätze aus
2048 Bytes (2,0 kB) kopiert, 0,00118767 s, 1,7 MB/s


Die ID des USB-Sticks abfragen:
Code: [Select]
# ls -l /dev/disk/by-id/
lrwxrwxrwx 1 root root  9 Sep 27 13:59 usb-Generic_Flash_Disk_CCBB1206251346300122371807-0:0 -> ../../sdh
Die /etc/cryptab  anpassen.
Code: [Select]
# <target name>    <source device>        <key file>    <options>
#cryptsda3    UUID="1c2cfd04-bbbf-4260-a700-d765c74ff79c"     /dev/disk/by-id/usb-Generic_Flash_Disk_CCBB1206251346300122371807-0:0        luks,tries=1,keyfile-size=2048,keyfile-offset=2012242432
cryptsda3    UUID="1c2cfd04-bbbf-4260-a700-d765c74ff79c"    LABEL=FAT    luks,keyfile-offset=2012242432,keyfile-size=2048,hash=sha256
cryptmd0    UUID="dc11d569-b9df-4201-a66a-25739cadd837"    /root/cd0    luks

Ich habe unterschiedliche Einstellungen und Optionen durch probiert, ohne Erfolg.


Die /etc/default/cryptdisks habe ich wieder in den Urzustand versetzt. Ich vermute, das man hier ein Dateisystem mounten kann auf dem der Schlüssel als Datei ablegt ist. Auch das hatte ich versucht, bin aber gescheitert. Wenn ich in der fstab einen Mountpunkt für den USB-Stick angebe, wird dieser im Hauptsystem gemountet, nicht aber in der RAMdisk.
Code: [Select]
# Run cryptdisks initscripts at startup? Default is Yes.
CRYPTDISKS_ENABLE=Yes

# Mountpoints to mount, before cryptsetup is invoked at initscripts. Takes
# mountpoins which are configured in /etc/fstab as arguments. Separate
# mountpoints by space.
# This is useful for keyfiles on removable media. Default is unset.
CRYPTDISKS_MOUNT=""
#CRYPTDISKS_MOUNT="/dev/disk/by-id/usb-Generic_Flash_Disk_CCBB1206251346300122371807-0:0-part1"

# Default check script. Takes effect, if the 'check' option is set in crypttab
# without a value.
CRYPTDISKS_CHECK=blkid

# Default precheck script. Takes effect, if the 'precheck' option is set in
# crypttab without a value.
# Default is 'un_blkid' for plain dm-crypt devices if unset here.
CRYPTDISKS_PRECHECK=
Den USB_Stick in die /etc/fstab einzubinden, nützt nichts. Dieser erscheint nach dem booten im Verzeichnis /usb, wird aber von der Initramfs anscheinend ignoriert:
Code: [Select]
# <file system>                    <mount point>    <type>        <options>                <dump>    <pass>

# USB-Key
#/dev/disk/by-id/usb-Generic_Flash_Disk_CCBB1206251346300122371807-0:0-part1    /usb    vfat    utf8    0    0

# (root) /dev/VGsys/LVroot, Block device 253:1, LV-UUID FSoLkW-sXA3-hbLh-H0rL-ndvL-9az3-Gx5y04
UUID=34caf3d6-17f4-4ed9-904e-b5639e504f9f    /        ext4        defaults,noatime,errors=remount-ro    0    1   

# sda2 /boot -Partition
UUID=fc6972d9-5de9-4c38-8090-86eee965b960    /boot        ext4        defaults,noatime,errors=remount-ro    0    2   

# sda1 EFI-Partition
# UUID=353A-9BD6                /boot/efi    vfat        utf8                    0    0

# /home /dev/mapper/cryptmd0
UUID="bca08917-e956-40bf-ad1a-fb62e101158c"    /home        ext4        defaults,noatime,errors=remount-ro    0    2

# (swap) /dev/VGsys/LVswp, Block device 253:2, LV-UUID dE0Jh7-PVs0-GexD-nhMT-AiZ3-v1n4-BZ3wfM
UUID=0ebf9a48-c88c-4316-aec9-143c64a4b099    none        swap        sw                    0    0   



In /etc/default/grub habe ich ein rootdelay angegeben, leider auch ohne Auswirkungen:
Code: [Select]
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="cryptopts=source=UUID=1c2cfd04-bbbf-4260-a700-d765c74ff79c,target=cryptsda3,lvm=/dev/VGsys/LVroot,rootdelay=10"

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=1920x1080
GRUB_GFXPAYLOAD_LINUX=keep

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
Zum Schluss die Generatoren für Systemd gestartet:
# systemctl --system daemon-reload

den Grub geupdatet:
# update-grub

und eine neue Initramfs erstellt:
# update-initramfs -u -k 4.2.1-towo.1-siduction-amd64
update-initramfs: Generating /boot/initrd.img-4.2.1-towo.1-siduction-amd64
cryptsetup: WARNING: target cryptsda3 uses a key file, skipped

Die Warnmeldung stört mich etwas weil da steht „skipped“, ich bin aber nicht sicher ob das wirklich relevant ist. Der Schlüssel ist ja nicht direkt dort.

Leider habe noch nicht herausgefunden, wie ich den Bootlog aus dem Initramfs aufzeichnen kann. Ich hab mal ein Bildschirmfoto nach der altmodischen Art gemacht, hier die Meldungen:
Code: [Select]
cryptsetup: cryptsetup failed, bad password or options?
/scrips/local-top/cryptroot: /scrips/local-top/cryptroot: line 1: line 1: /lib/cryptsetup/askpass: not found/sbin/cryptsetup: not found

cryptsetup: cryptsetup failed, bad password or options?
   lvmetad is not active yet, using direct activation during sysinit
   Volume group „VGsys“ not found
   Cannot process volume group VGsys
Gave up waiting for root device. Common problems:
   - Boot args (cat /proc/cmdline)
      - Check rootdelay= (did the system wait long enough?)
      - Check root= (did the system wait for the right device?)
   - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mapper/VGsys-LVroot does not exist. Dropping to a shell!

Könnte sein, das Cryptsetup gar nicht im Initramfs funktioniert? Das LVM kann natürlich nicht aktiv werden wenn die Partition noch nicht zur Verfügung steht. Die Kernel-Module sollten alle da sein, in der /etc/initramfs-tools/initramfs.conf ist der Eintrag MODULES=most gesetzt. Wenn ich in der /etc/crypttab unter <key file> „none“ eintrage, werde ich nach der Passphrase gefragt. Das aufschließen der Partition und anschließende starten des LVM funktioniert einwandfrei. Das Einbinden des RAID mit /home macht keine mucken. Alles wäre wunderschön, wenn die nervige und unsichere Aufforderung zur Passphrase nicht wäre. Es muss doch möglich sein da irgendwie ein Keyfile auf einem externen Medium für einzusetzten.

Ich habe beim durchstöbern einen systemd-cryptsetup-generator gefunden. Ich bin aber noch nicht ganz dahinter gestiegen, wie der funktioniert. In der Man-Page steht etwas von einer „rd.fstab“, die nur vom Initramfs ausgewertet wird. Kann man irgendwo eine spezielle fstab einrichten für meinen USB-Stick?

Das neue Systemd scheint ja nicht schlecht zu sein, aber nur für Leute, die die Zeit haben sich darin einzuarbeiten. Gibt es noch andere wichtige Konfig-Dateien, eventuell wichtig sind?

Vielen Dank schon mal für Hinweise und Hilfen.

Offline hsp

  • User
  • Posts: 623
Re: luks, lvm und USB-Schlüssel
« Reply #4 on: 2015/09/28, 08:13:04 »
cryptsetup: WARNING: target cryptsda3 uses a key file, skipped

Das ist relevant, keyfile direkt geht nicht in der initrd da das nicht erlaubt ist., Dann kommt ja jeder an den Key ran wenn er dir die initrd klaut.  Du musst ihn per script vom usbstick oder so einlesen. Ich hab das ganz etwas modifiziert von den Ubuntugenossen.
https://wiki.ubuntuusers.de/System_verschl%C3%BCsseln/Entschl%C3%BCsseln_mit_einem_USB-Schl%C3%BCssel

Läuft bei mir schon lange mit systemd.

...

Roland

  • Guest
Re: luks, lvm und USB-Schlüssel
« Reply #5 on: 2015/10/02, 00:32:55 »
Hi,

Die Seite kannte ich schon, aber das Keyscript wird beim erstellen des Initramfs offensichtlich ignoriert.
Ich habe mich genau an die Anleitung gehalten (nur die Device angepasst), ohne Erfolg. Ich werde beim booten nach der Passphrase gefragt, der ganze Ablauf sieht dann so aus:
Code: [Select]
Loading, please wait...
   lvmetad is not active yet, using direct activation during sysinit
   Volume group „VGsys“ not found
   Cannot process volume group VGsys
Please unlock disk cryptsda3:  <Eingeben der Passphrase>
   /run/lvm/lvmetad.socket: connect failed: No such file or directory
   Warning:Failed to connect to lvmetad. Falling back to internal scanning.
   Reading all physical volumes. This may take a while…
   Found volume group „VGsys“ using metadata type lvm2
   2 logical volume(s) in volume group “VGsys” now active
cryptsetup: cryptsda3 set up succesfully
Scanning for Btrfs filesystems
fsck from util-linux 2.27
/dev/mapper/Vgsys-Lvroot: clean, 219620/59826176 files, 5312261/239290368 blocks


Beim recherchieren mit einer bekannten amerikanischen Suchmaschine bin ich dann auf diese Seite gekommen:
 https://wiki.debianforum.de/Cryptsetup_mit_systemd_und_Schl%C3%BCssel_auf_externem_USB-Stick
Dort steht, das Keyscripte nicht von systemd ausgewertet werden.
Ich hatte die /etc/crypttab nach dieser Anleitung geändert, bin dann beim booten aber in der Initramfs-Konsole (Busybox) gelandet, mit folgenden Meldungen:
Code: [Select]
cryptsetup: cryptsetup failed, bad password or options?
/scrips/local-top/cryptroot: /scrips/local-top/cryptroot: line 1: line 1: /lib/cryptsetup/askpass: not found/sbin/cryptsetup: not found

cryptsetup: cryptsetup failed, bad password or options?
   lvmetad is not active yet, using direct activation during sysinit
   Volume group „VGsys“ not found
   Cannot process volume group VGsys
Gave up waiting for root device. Common problems:
   - Boot args (cat /proc/cmdline)
      - Check rootdelay= (did the system wait long enough?)
      - Check root= (did the system wait for the right device?)
   - Missing modules (cat /proc/modules; ls /dev)
ALERT!  /dev/mapper/VGsys-LVroot does not exist. Dropping to a shell!

Irgendwas mache ich falsch  :(

Am Wochenende will ich mal versuchen, ob ich den Stick (so wie bei Wheezy) in der initramfs mounten kann um den Schlüssel als Datei auszulesen.

Offline hsp

  • User
  • Posts: 623
Re: luks, lvm und USB-Schlüssel
« Reply #6 on: 2015/10/02, 04:34:34 »
Hier meine config mit usbstick 'aufschliessen'
Geändert habe ich nur die /etc/decryptkeydevice/decryptkeydevice_keyscript.sh glaube ich, ich hab dir aber mal vorsichtshalber mal alles hier reingekippt :)
Hinzugefügt habe ich eine udev-regel damit meine Sticks immer als /dev/usbstick und /dev/disk/disk/by-id/usbstick ansprechbar sind. Ansonsten kannst du dich anden Ubuntuwiki halten. Muss aber dazusagen das bei mir kein LVM im Spiel ist, also nur verschlüsselte Partitionen. Wie weit das dafür relevant ist weiss ich nicht. Sollte aber eigentlich keine Rolle spielen denk ich mir.


/etc/decryptkeydevice/decryptkeydevice.conf
Code: [Select]
# device listed in /dev/disk/by-id/
DECRYPTKEYDEVICE_DISKID="usbstick"

# blocksize usually 512 is OK
DECRYPTKEYDEVICE_BLOCKSIZE="512"

# start of key information on keydevice DECRYPTKEYDEVICE_BLOCKSIZE * DECRYPTKEYDEVICE_SKIPBLOCKS
DECRYPTKEYDEVICE_SKIPBLOCKS="xxxxxxxx"

# length of key information on keydevice DECRYPTKEYDEVICE_BLOCKSIZE * DECRYPTKEYDEVICE_READBLOCKS
DECRYPTKEYDEVICE_READBLOCKS="xxxxxxxxxxxxx"


Die modifizierte /etc/decryptkeydevice/decryptkeydevice_keyscript.sh
Code: [Select]
#!/bin/sh

# read decryptkeydevice Key configuration settings
DECRYPTKEYDEVICE_DISKID=""
if [ -f /etc/decryptkeydevice/decryptkeydevice.conf ] ; then
        .  /etc/decryptkeydevice/decryptkeydevice.conf
fi

TRUE=1
FALSE=0

PLYMOUTH=$FALSE
# test for plymouth and if plymouth is running
if [ -x /bin/plymouth ] && plymouth --ping; then
        PLYMOUTH=$TRUE
fi

# is stty available? default false
STTY=$FALSE
STTYCMD=false
# check for stty executable
if [ -x /bin/stty ]; then
    STTY=$TRUE
    STTYCMD=/bin/stty
elif [ `(busybox stty >/dev/null 2>&1; echo $?)` -eq 0 ]; then
    STTY=$TRUE
    STTYCMD="busybox stty"
fi

# read password from console or with plymouth
# usage: readpass "prompt"
readpass ()
{
    if [ $# -gt 0 ]; then
        if [ $PLYMOUTH -eq $TRUE ]; then
            PASS=`/bin/plymouth ask-for-password --prompt="$1"`
        else
            [ $STTY -ne $TRUE ]
            echo -n "$1" >&2
            $STTYCMD -echo
            read -s PASS </dev/console >/dev/null
            [ $STTY -eq $TRUE ] && echo >&2
            $STTYCMD echo
        fi
    fi
    echo -n "$PASS"
}

# flag tracking key-file availability
OPENED=$FALSE

# decryptkeydevice configured so try to find a key
if [ ! -z "$DECRYPTKEYDEVICE_DISKID" ]; then
    # Is the USB driver loaded?
    cat /proc/modules | busybox grep usb_storage >/dev/null 2>&1
    USBLOAD=0$?
    if [ $USBLOAD -gt 0 ]; then
        modprobe usb_storage >/dev/null 2>&1
    fi
    # Is the mmc_block driver loaded?
    cat /proc/modules | busybox grep mmc >/dev/null 2>&1
    MMCLOAD=0$?
    if [ $MMCLOAD -gt 0 ]; then
        modprobe mmc_core >/dev/null 2>&1
        modprobe ricoh_mmc >/dev/null 2>&1
        modprobe mmc_block >/dev/null 2>&1
        modprobe sdhci >/dev/null 2>&1
    fi

        TIMEOUT=0
        while [ "$TIMEOUT" -lt 50 -a ! -e /dev/disk/by-id/$DECRYPTKEYDEVICE_DISKID ] ; do
            TIMEOUT=$((TIMEOUT+1))
            sleep .1
        done

        DECRYPTKEYDEVICE_FILE="/dev/disk/by-id/$DECRYPTKEYDEVICE_DISKID"

        if [ -e $DECRYPTKEYDEVICE_FILE ]
            then OPENED=$TRUE
        fi
fi


if [ $OPENED -eq $TRUE ]; then
    /bin/dd if=$DECRYPTKEYDEVICE_FILE bs=$DECRYPTKEYDEVICE_BLOCKSIZE skip=$DECRYPTKEYDEVICE_SKIPBLOCKS count=$DECRYPTKEYDEVICE_READBLOCKS 2>/dev/null
    if [ $? -ne 0 ]
        then OPENED=$FALSE
    fi
fi

if [ $OPENED -ne $TRUE ]
    then readpass "Enter passphrase: "
fi

Der Script steigt nach 5 Sekunden aus wenn er den stick nicht findet und fragt nach dem Passwort. Weiterhin gibt er absolut keinerlei Output auf dem Bildschirm aus wie der Originalscript wenn er keinen Stick findet.
Muss ja auch nicht jeder wissen das da was fehlt :)


/etc/initramfs-tools/hooks/decryptkeydevice.hook
Code: [Select]
#!/bin/sh
# copy decryptkeydevice files to initramfs
#

mkdir -p $DESTDIR/etc/
cp -rp /etc/decryptkeydevice $DESTDIR/etc/


/etc/initramfs-tools/hooks/usbsticks.hook
Code: [Select]
#!/bin/sh
# copy usbsticks-rules file to initramfs
#
mkdir -p $DESTDIR/etc/udev/rules.d/
cp -p /etc/udev/rules.d/80-usb-sticks.rules $DESTDIR/etc/udev/rules.d/


/etc/udev/rules.d/80-usb-sticks.rules
Code: [Select]
# CruzerBlade
SUBSYSTEMS=="usb", ATTRS{serial}=="20053045430C8D305B99", KERNEL=="sd*", SYMLINK+="usbstick%n"
SUBSYSTEMS=="usb", ATTRS{serial}=="20053045430C8D305B99", KERNEL=="sd*", SYMLINK+="disk/by-id/usbstick%n"

# Ut161
SUBSYSTEMS=="usb", ATTRS{serial}=="00000000000037", KERNEL=="sd*", SYMLINK+="usbstick%n"
SUBSYSTEMS=="usb", ATTRS{serial}=="00000000000037", KERNEL=="sd*", SYMLINK+="disk/by-id/usbstick%n"

# Single Flash Reader
SUBSYSTEMS=="usb", ATTRS{serial}=="058F63356336", KERNEL=="sd*", SYMLINK+="disk/by-id/usbstick%n"
SUBSYSTEMS=="usb", ATTRS{serial}=="058F63356336", KERNEL=="sd*", SYMLINK+="usbstick%n"

# Realtek Semiconductor Corp. Mass Storage Device (Multicard Reader)
# SUBSYSTEMS=="usb", ATTRS{serial}=="20060413092100000", KERNEL=="sd*", SYMLINK+="disk/by-id/sdcard%n"
# SUBSYSTEMS=="usb", ATTRS{serial}=="20060413092100000", KERNEL=="sd*", SYMLINK+="sdcard%n"


/etc/crypttab
Code: [Select]
# <target name>    <source device>        <key file>    <options>
#
luksdebian UUID=674beb41-f56f-47a9-8de3-892cfafc6b22 none luks,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh


Viel Glück...

Roland

  • Guest
Re: luks, lvm und USB-Schlüssel
« Reply #7 on: 2015/10/03, 17:37:53 »
Danke für deine Config. Leider funktioniert das ganze immer noch nicht, ich verzweifle gerade ein bisschen. :-\
Ich habe dein modifiziertes Script und auch das originale ausprobiert, ohne Erfolg. Die Udev-Regel habe ich natürlich vorher mit der neuen Seriennummer geändert. Das Script und die Hooks sind mit chmod 755 ausführbar gemacht. Ich habe sogar testweise einen neuen Schlüssel kreiert und natürlich der Platte hinzugefügt, keine Chance.

Wegen der LVM-Meldungen habe ich in der /etc/lvm/lvm.conf das „use_lvmetad = „ auf „0“ gesetzt, nun fehlen die Meldungen zu lvmetad. Aber ich denke, das hat nichts mit dem Schlüssel zu tun.

Startmeldungen:
Code: [Select]
Loading, please wait...
   Volume group „VGsys“ not found
   Cannot process volume group VGsys
Please unlock disk cryptsda3:  <Eingeben der Passphrase>
   Reading all physical volumes. This may take a while…
   Found volume group „VGsys“ using metadata type lvm2
   2 logical volume(s) in volume group “VGsys” now active
cryptsetup: cryptsda3 set up succesfully

Es ist allerdings ersichtlich, das die Initramfs versucht das LVM zu starten, bevor luks zum Zuge kommt. Aber ich denke, das ist kein wirkliches Problem weil nach der Eingabe der Passphrase ja trotzdem alles startet.

Beim generieren des Initramfs kommt keine Fehlermeldung, das bedeutetet ja, dass das Script korrekt eingebunden wird.
Müssten nicht eigentlich Fehlermeldungen durch das Keyscript beim Bootvorgang erscheinen wenn es Probleme geben würde? z.B. wenn der Stick nicht erkannt wird oder der Schlüssel falsch ist oder was auch immer nicht passt?
Wenn nichts erscheint deutet das ja daraufhin, dass das Script doch nicht funktioniert.

Hier nochmal meine aktuellen Konfigs:

/etc/udev/rules.d/80-usb-sticks.rules
Code: [Select]
SUBSYSTEMS=="usb", ATTRS{serial}=="CCBB1206251346300122371807", KERNEL=="sd*", SYMLINK+="usbstick%n"
SUBSYSTEMS=="usb", ATTRS{serial}=="CCBB1206251346300122371807", KERNEL=="sd*", SYMLINK+="disk/by-id/usbstick%n"

/etc/crypttab
Code: [Select]
cryptsda3    UUID="1c2cfd04-bbbf-4260-a700-d765c74ff79c"    none        luks,keyscript=/etc/decryptkeydevice/decryptkeydevice_keyscript.sh
cryptmd0    UUID="dc11d569-b9df-4201-a66a-25739cadd837"    /root/cd0    luks

/etc/decryptkeydevice/decryptkeydevice.conf
Code: [Select]
# USB-Speichersticks bzw. SD-Karten als Schlüssel: (mehrere Disk-ID mit Leerzeichen getrennt)
# DECRYPTKEYDEVICE_DISKID="usb-Generic_Flash_Disk_CCBB1206251346300122371807-0:0"
DECRYPTKEYDEVICE_DISKID="usbstick"

# Sektorgröße:
DECRYPTKEYDEVICE_BLOCKSIZE="512"

# Luks-Schlüssel startet nach Sektor:
DECRYPTKEYDEVICE_SKIPBLOCKS="1"

# Luks-Schlüssel Länge in Sektoren:
DECRYPTKEYDEVICE_READBLOCKS="4"

Die Udev-Regel funktioniert, bei # ls -l /dev/disk/by-id/ erscheint:
Code: [Select]
...
lrwxrwxrwx 1 root root  9 Okt  3 16:18 usb-Generic_Flash_Disk_CCBB1206251346300122371807-0:0 -> ../../sdh
...
lrwxrwxrwx 1 root root  9 Okt  3 16:18 usbstick -> ../../sdh
...

Die Hooks und das Script habe ich 1:1 kopiert.