Automatische Entschlüsselung funktioniert nicht

Alles rund um sicherheitsrelevante Fragen und Probleme.
rhHeini
Beiträge: 807
Registriert: 20.04.2006 20:44:10

Automatische Entschlüsselung funktioniert nicht

Beitrag von rhHeini » 15.02.2017 23:05:12

Rechner mit M2-SSD als Boot- und Systemlaufwerk, Jessie amd64 mit Mate Desktop, frisch installiert. /boot = sda1, /root verschlüsselt auf sda2. Ausserdem ist swap auf sda5 verschlüsselt. Einen USB-Stick habe ich vorbereitet nach der Ubuntu-Anleitung, den abgeleiteten Key zusätzlich sda2 bekanntgemacht.

Öffnen per Key geht. Habe mich jetzt am Wiki https://wiki.debianforum.de/Cryptsetup_ ... _USB-Stick entlanggehangelt und die crypttab wie folgt geändert.

Code: Alles auswählen

# Original-Eintrag
# sda2_crypt UUID=aa9c8d6f-92f9-4729-841e-a9731819d951 none luks
# Modifiziert für automatische Entschlüsselung
sda2_crypt UUID=aa9c8d6f-92f9-4729-841e-a9731819d951 /dev/disk/by-id/usb-TOSHIBA_TransMemory_00187D1174F5EC50A0000553-0:0 luks,discard,tries=3,keyfile-size=4096,keyfile-offset=7680
Die generierte Unit sieht wie folgt aus:

Code: Alles auswählen

# Automatically generated by systemd-cryptsetup-generator

[Unit]
Description=Cryptography Setup for %I
Documentation=man:crypttab(5) man:systemd-cryptsetup-generator(8) man:systemd-cryptsetup@.service(8)
SourcePath=/etc/crypttab
DefaultDependencies=no
Conflicts=umount.target
BindsTo=dev-mapper-%i.device
IgnoreOnIsolate=true
After=systemd-readahead-collect.service systemd-readahead-replay.service cryptsetup-pre.target
Before=cryptsetup.target
After=dev-disk-by\x2did-usb\x2dTOSHIBA_TransMemory_00187D1174F5EC50A0000553\x2d0:0.device
Requires=dev-disk-by\x2did-usb\x2dTOSHIBA_TransMemory_00187D1174F5EC50A0000553\x2d0:0.device
BindsTo=dev-disk-by\x2duuid-aa9c8d6f\x2d92f9\x2d4729\x2d841e\x2da9731819d951.device
After=dev-disk-by\x2duuid-aa9c8d6f\x2d92f9\x2d4729\x2d841e\x2da9731819d951.device
Before=umount.target

[Service]
Type=oneshot
RemainAfterExit=yes
TimeoutSec=0
ExecStart=/lib/systemd/systemd-cryptsetup attach 'sda2_crypt' '/dev/disk/by-uuid/aa9c8d6f-92f9-4729-841e-a9731819d951' '/dev/disk/by-id/usb-TOSHIBA_TransMemory_00187D1174F5EC50A0000553-0:0' 'luks,discard,tries=3,keyfile-size=4096,keyfile-offset=7680'
ExecStop=/lib/systemd/systemd-cryptsetup detach 'sda2_crypt'
In der Unit fallen mir halt die ein Sonderzeichen "\x2d" auf. Machen die das Problem?

Habe jetzt 3 mal drüber geschaut das ich keinen Typo drin habe, die Unit mal in /etc/systemd/system kopiert, draussen gelassen, immer wird der Key abgefragt. Was fehlt im Wiki, oder wo habe ich was falsch verstanden?

Danke im Voraus, Rolf

Update: nach einem update-initramfs wird der Key für sda2 nicht mehr abgefragt, swap wird mit Key entschlüsselt, dann fällt das System in die Wartungsshell da sda2_crypt nicht existiert.
Zuletzt geändert von rhHeini am 19.02.2017 20:27:29, insgesamt 1-mal geändert.

rhHeini
Beiträge: 807
Registriert: 20.04.2006 20:44:10

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rhHeini » 17.02.2017 00:03:45

Habe heute Abend etwas weitergebastelt.

Aus der Wartungsshell raus kann ich root ganz normal mit cryptsetup luksOpen ... entschlüsseln, dann bootet der Rechner.

Beim Erstellen einer neuen initramfs kommt ein Hinweis auf den Keyfile und das da etwas geskipt wird. Hat das was zu sagen?

In der Wartungsshell kommt konsistent eine Meldung:

Code: Alles auswählen

module ehci-orion not found in modules.dep
Die Ente zeigte unter anderem das es da eventuell Probleme mit USB3 gibt. Alle fixen USB-Ports des Mainboards sind USB3, mein Stick USB2. Ein Eintrag von xhci-hud in der modules war erfolglos, ebenso Umstecken des Sticks auf eine USB2-Port im Gehäuse, ebenso Eintragen eines rootdelays von 20s.

Habe noch mal die UUID und ID des Sticks genau überprüft, passt. Noch mal den Schlüssel gelesen und verglichen, passt.

Welche Randbedingung kann noch daneben sein?

Gruss, Rolf
Zuletzt geändert von rhHeini am 17.02.2017 19:26:54, insgesamt 1-mal geändert.

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rendegast » 17.02.2017 02:06:09

module ehci-orion not found in modules.dep
https://packages.debian.org/file:ehci-orion.ko
Modul nur unter 3.16 arm. Dort wohl für gewisse Systeme boot-relevant (bugreport).
Vielleicht per Pakettranskription auf das System gekommen.
(Hier auf einem jessie mit backports finde ich "ehci.orion" gar nicht)
- wohl unwichtig -




Landet die Aufschlüsselungsanweisung für / (sda2_crypt) mithilfe des USB-Stick denn passend in der initramfs?
Zur Untersuchung Hilfs-Link erstellen
4.9-amd64.cpio.gz -> initrd.img-4.9...amd64

Falls Debianintel-microcode verwendet wird, muß dafür dessen cpio von der eigentlichen initrd gestrippt werden

Code: Alles auswählen

for i in $(ls -1 /boot/initrd.*-amd64); do
    # Das microcode-pre ist ein regulaeres cpio
    INITRD=$(cpio -t < $i 2>&1 | awk '$2=="blocks" {print $1}')

    echo dd if=$i bs=$INITRD \> $i.initrd-tail
    dd if=$i skip=$INITRD > $i.initrd-tail.cpio.gz
done
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

rhHeini
Beiträge: 807
Registriert: 20.04.2006 20:44:10

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rhHeini » 17.02.2017 21:05:03

Danke fürs Feedback.

Der Punkt mit dem Entfernen von Debianintel-microcode war wichtig, habs geschafft in den Rest reinzuschauen. Bin mir nicht sicher wo genau ich suchen muss, aber nach meinem Dafürhalten ist da nichts drin zur Entschlüsselung mit Keyfile. Habe alle Directories geflöht, finde keinen Hinweis auf eine neue Unit oder einen Hinweis auf den Stick. In den modules sind meine Einträge drin.

Hatte erst nur den 316er-Kernel drauf, habe jetzt auch den 4.9 nachinstalliert, gleiches Spiel. Das Update der initramfs ist im Wiki nicht erwähnt, ist aber logisch das es erforderlich ist. Dort kommt:

Code: Alles auswählen

# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-0.bpo.1-amd64
cryptsetup: WARNING: target sda2_crypt uses a key file, skipped
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
cryptsetup: WARNING: target sda2_crypt uses a key file, skipped
Das sagt doch das update-initramfs den Keyfile nicht mag. Warum? Eine neuere Version als die installierte ist in den Backports nicht drin.

Noch Vorschläge?

Danke im Voraus, Rolf

PS: die Meldung wegen dem ehci-orion kommt nach wie vor.

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rendegast » 17.02.2017 22:42:01

rhHeini hat geschrieben: cryptsetup: WARNING: target sda2_crypt uses a key file, skipped
Das sagt doch das update-initramfs den Keyfile nicht mag. Warum?
Eigentlich ist es
cryptsetup: /usr/share/initramfs-tools/hooks/cryptroot, Funktion add_device() -> get_device-opts()

Funktioniert vielleicht eher über Automatismen im devmapper-Apparat,
resp. soll funktionieren ;) .


PS: die Meldung wegen dem ehci-orion kommt nach wie vor.
"ehci.orion" findet sich in initramfs-tools 0.120
/usr/share/initramfs-tools/hook-functions
/usr/share/initramfs-tools/scripts/functions
(ist ein *_all.deb-Paket, daher auf allen Architekturen, das meinte ich mit "Transkription")
Wird bei einem "${panic}"-Start versucht zu laden.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

rhHeini
Beiträge: 807
Registriert: 20.04.2006 20:44:10

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rhHeini » 18.02.2017 16:00:36

Danke für den Hinweis auf den Hook, den hätte ich selber nie gefunden.
rendegast hat geschrieben:
rhHeini hat geschrieben: cryptsetup: WARNING: target sda2_crypt uses a key file, skipped
Das sagt doch das update-initramfs den Keyfile nicht mag. Warum?
Eigentlich ist es
cryptsetup: /usr/share/initramfs-tools/hooks/cryptroot, Funktion add_device() -> get_device-opts()

Funktioniert vielleicht eher über Automatismen im devmapper-Apparat,
resp. soll funktionieren ;) .
Habe mir die Stelle im Skript gesucht wo die Fehlermeldung erzeugt wird:

Code: Alles auswählen

	# If keyscript is set, the "key" is just an argument to the script
	if [ "$key" != "none" ] && [ -z "$KEYSCRIPT" ]; then
		echo "cryptsetup: WARNING: target $target uses a key file, skipped" >&2
		return 1
	fi
Da ist von einer Verknüpfung mit einem Keyscript die Rede, in meinen Settings, die dem Wiki entsprechen, steht aber nur was von Keyfile? So 100%tig habe ich das ganze Skript nicht durchdrungen, die Angaben zu keyfile-size und keyfile-offset finde ich weder hier noch in den anderen Hooks. Für mich sieht es so aus das die initramfs-tools das Vorhaben blockieren. Oder sehe ich das falsch?
rendegast hat geschrieben:
rhHeini hat geschrieben: PS: die Meldung wegen dem ehci-orion kommt nach wie vor.
"ehci.orion" findet sich in initramfs-tools 0.120
/usr/share/initramfs-tools/hook-functions
/usr/share/initramfs-tools/scripts/functions
(ist ein *_all.deb-Paket, daher auf allen Architekturen, das meinte ich mit "Transkription")
Wird bei einem "${panic}"-Start versucht zu laden.
Passt doch, wenn root nicht verfügbar ist, ist das doch eine Art von panic. Ist jedenfalls nicht die Ursache sondern ein Folgefehler, kann man damit abhaken.

Bin jetzt etwas ratlos. Macht es Sinn den Keyfile exakt wie im Beispiel zu gestalten? Habe da eher Zweifel, da das initramfs scheinbar streikt. Gibt es noch Ideen was ich ausprobieren könnte?

Gruss, Rolf

rhHeini
Beiträge: 807
Registriert: 20.04.2006 20:44:10

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rhHeini » 18.02.2017 20:06:54

Habe die beiden Threads viewtopic.php?f=37&t=160710 und viewtopic.php?f=37&t=160471 gelesen. Mich beschleicht der Verdacht daß die systemd-Skripte im Zusammenspiel mit meinem Setup ungeeignet und fehlerhaft sind.

Werde wohl noch mal neu aufsetzen mit einem verschlüsselten LVM.

Hatte eigentlich vor noch mindestens eine Parallelinstallation, z.B. von sid auf der SSD zu halten. Wie mache ich das am besten? 2 boot-Partitionen mit eigenen verschlüsselten LVMs?

Gruss, Rolf

rhHeini
Beiträge: 807
Registriert: 20.04.2006 20:44:10

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rhHeini » 18.02.2017 23:58:26

Ich weiss jetzt warum mein Entschluss produktiv nur Wheezy verschlüsselt einzusetzen richtig war. Jessie mit Verschlüsselung und systemd ist absolut kaputt.

Habe den Rechner neu aufgesetzt, neben /boot eine grosse Partition als Volume für Verschlüsselung, darin ein LVM mit Volumes für swap und root.

Nach der Installation die sources bereinigt, backports rein, erst ein allgemeines Update, dann den 4.9er Kernel und die firmware-linux-nonfree aus den Backports drüber.

Dann nach Reboot versucht den Key vom Stick auf sda3 zu schreiben. Funzt nicht, kommt nie zum Ende, muss das Terminal abbrechen. Nach mehreren Versuchen den 3.16er-Kernel gebootet: siehe da es geht. Die crypttab laut Wiki geändert, selbes Problem wie zuvor, egal mit welchenm Kernel. Habe die Nase voll von Jessie und systemd, so nicht.

Gruss, Rolf

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rendegast » 19.02.2017 05:48:51

rhHeini hat geschrieben: Einen USB-Stick habe ich vorbereitet nach der Ubuntu-Anleitung, den abgeleiteten Key zusätzlich sda2 bekanntgemacht.
Diese Anleitung?
https://wiki.ubuntuusers.de/System_vers ... C3%BCssel/
# sda2_crypt UUID=XXXX none luks
# Modifiziert für automatische Entschlüsselung
sda2_crypt UUID=XXXX /dev/disk/by-id/usb-TOSHIBA_TransMemory_YYYY-0:0 luks,discard,tries=3,keyfile-size=4096,keyfile-offset=7680
Dazu steht in 'man 5 crypttab', daß
keyfile-size=...
keyfile-offset=...
für LUKS / TCRYPT ignoriert wird.
keyfile-size / keyfile-offset werden nur bei 'cryptsetup --help' erwähnt.
--------------------------
EDIT Nach Test bestätigt sich das.
Die Funktion scripts/local-top/cryptroot:parse_options().
cipher / hash / size gehören zusammen und werden aus der crypttab in die cryptroot der initrd übernommen.
'offset', obwohl dazugehörig erwähnt, wird NICHT in die cryptroot übernommen? die Funktion beschwert sich aber nicht und gibt sie aus.
In den initrd-Hooks/Skripten von cryptsetup findet sich keine direkte Auswertung dazu.

Die von Dir gesetzten 'keyfile-*' sind ein Sonderfall,
die Funktion macht einen generischen Fehler wegen des "-"
export: CRYPTTAB_OPTION_...-...: bad variable name
Sie sind soweit "nur" Optionen des Programms.
Das Skript aus obiger ubuntu-Anleitung benutzt auch nicht diesen Mechanismus, sondern schneidet den key per 'dd' aus dem key-device.
--------------------------

In obiger Anleitung wird keyscript=.... benutzt (+ eine dazugehörige Konf-Datei).
(Beachte: es wird auch ein zusätzlicher initramfs-hook eingesetzt.
Dieser kopiert auch die dazugehörige Konf-Datei in die initrd)
Dazu steht in 'man 5 crypttab', daß keyscript= nicht mit systemd funktioniert ("WARNING:"),
außer in der crypttab ist die Option 'initramfs' gesetzt.
EDIT Das gilt so nur für devices, die NICHT "/" enthalten
(gemeint sind erstmal nur direkt mit "/" funktionell verbundene devices wie tmp (hibernation) oder swap).
Ansonsten führt es zu einem doppelten Eintrag für das "/" enthaltende device in /conf/conf.d/cryptroot.



------------------------------------
Was mir noch einfällt, wenn ich die initrd im Standardzustand "Paßwort" durchstöbere,
es landet die entsprechende crypttab in der initrd als /conf/conf.d/cryptroot.
Die "Paßwort"-initrd funktioniert also als Notlösung und sollte in der Testphase in /boot/ als Sicherheitskopie verbleiben (sodaß sie in der grub-shell eingetragen werden könnte).



------------------------------------
Alternative zum bei Dir RAW auf dem Stick vorliegenden Key, in README.initramfs:
Auf dem Stick ein Dateisystem (ext, vfat, btrfs, reiserfs, xfs, jfs, ntfs, iso9660, udf)
und crypttab derart:

Code: Alles auswählen

sda2_crypt UUID=XXXX /dev/disk/by-id/usb-YYYY-partZ:/verzeichnis/key.bin luks,keyscript=passdev
EDIT Funktioniert, übler Beigeschmack:
Unsinnige Meldung/Aktion
systemd: -dev-disk-by.........-partZ:-verzeichnis-key.bin.service: Job ... failed with status 'timeout'
für das "key-device" resp. key-Datei, mit der gewohnten systemd-Wartezeit von x*30s.
'passdev' räumt hinter sich wohl nicht richtig auf resp. es hakt noch an der Korrekten Integration.
Zuletzt geändert von rendegast am 20.02.2017 07:59:28, insgesamt 1-mal geändert.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

rhHeini
Beiträge: 807
Registriert: 20.04.2006 20:44:10

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rhHeini » 19.02.2017 22:12:17

Danke rendegast, das Du immer wieder Feedback gibst.

Muss aber doch etwas ausholen. Ich habe vor Jahren wegen einem Fileserver mit Linux angefangen und da auch Verschlüsselung mit Entschlüsselung per USB-Stick verwendet. Und zwar nach http://www.andreas-janssen.de/cryptodisk.html, also mit sichtbaren Keyfiles auf dem USB-Stick. Zusammengefasst habe ich das mal in viewtopic.php?f=12&t=115886#p736418 beschrieben, funzt ab Etch bis Wheezy. Mein gegenwärtiger PC ist nach dem Verfahren mit Wheezy/Mate aufgesetzt.

Im letzten Jahr bin ich über https://wiki.ubuntuusers.de/System_vers ... C3%BCssel/ gestolpert. Der Beitrag war wegen der unsichtbaren Keyfiles interessant, er hat mir aber vor allem wegen der Beispiele erst mal nur Fragezeichen rausgeworfen, z.B. warum da unbedingt LVM in der crypttab stehen muss, das wird nicht erklärt. Und die Skripte waren auch ausufernd und unverständlich.

Vor knapp einem Monat habe ich den PC meiner Frau von Squeeze auf Wheezy aufgerüstet und neu installiert. Dabei habe ich mich durch die obige Anleitung durchgebissen und schliesslich das ganze auch vereinfacht. Mein Vorgehen habe ich mal zusammengeschrieben und ins Nopaste gestellt: NoPaste-Eintrag39766. Klappt wunderbar ohne zusätzliche Hooks für die initrd.

Dann habe ich mich mit einem neuen PC der eigentlich mal meinen mehr als 10 Jahre alten Fileserver ersetzen soll mal an Jessie drangewagt. Der PC hat nen X99 Chipsatz, eine Xeon-CPU, ausreichend RAM und eine m2-SSD als Bootplatte. Verwendet habe ich Jessie amd64 7.9.0 mit Mate Desktop, im ersten Rutsch nur mit Default-Kernel, im zweiten auch mit dem 4.9er aus den Backports, und zwar installiere ich im Legacy-Modus da ich mich damit auskenne.

Grundlage des Vorgehens ist der Debianforum-Wiki-Artikel https://wiki.debianforum.de/Cryptsetup_ ... _USB-Stick, der wurde in verschiedenen Beiträgen immer wieder mal erwähnt. Dieser Artikel referenziert wiederum den obigen Ubuntuwiki-Artikel. Von der Vorbereitung des Sticks bis zum Hinzufügen des Keyfiles zum luks-Volumen ist erst mal alles gleich. Ab dem Eintrag in der crypttab geht es etwas anders.

Was ich da getrieben habe habe ich im Eingangspost beschrieben. Die Entschlüsselung klappt nicht, beim Generieren des initramfs wird der Keyfile angemeckert, obwohl ich nichts wesentlich anderes als im Wiki gemacht habe ausser das ich kein lvm in der crypttab stehen habe.

Gestern abend habe ich noch mal von vorne angefangen und neu partitioniert und installiert, und zwar so dass ich ein LVM für swap und root im luks-Container angelegt habe, weil wohl so etwas ähnliches im Artikel angenommen wird (ohne sehr spezifisch zu sein). Ich habe dabei gleich in einem Rutsch den 4.9er Kernel geladen, und dann mein Glück versucht. Erst klappte das Zuweisen des Keyfiles zum luks-Container mit dem 4.9er Kernel nicht (kommt nicht zum Ende), ein Reboot auf den 3.16er war notwendig damit das wie gewohnt ging. Bei der Generierung des initramfs kommt aber die Meldung "skipped" wegen des Keyfiles immer noch. Die Entschlüsselung funzt nicht, der PC endet in der Wartungskonsole und findet bei beiden Kerneln kein cryptsetup mehr. Sprich so ist der PC unbrauchbar, ich kann nicht mal mehr in der Wartungskonsole das root entschlüsseln was bein ersten Versuch vorher noch klappte.

Fazit: der referenzierte Debianforum-Wiki-Artikel funzt nicht. Da fehlt eh der Hinweis auf die initramfs.

Ich habe trotz Suchen nach Vorgehensweisen mit dem Gockel oder der Ente keine brauchbare HowTo gefunden. Damit bleibt Jessie für mich ein NoGo. Ich setze kein Linux mehr auf ohne Verschlüsselung und der Möglichkeit der automatischen Entschlüsselung wenn ein Keydevice vorhanden ist.

Ich hoffe das beantwortet jetzt wo ich her komme und wo ich fest stecke. Habe ich etwas wesentliches übersehen oder haben systemd-Patches das Verhalten geändert?

Gruss und schönen Sonntag Abend Rolf

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rendegast » 20.02.2017 07:41:31

Wie Du vermutest, das mit dem "LVM nötig" ist Humbug.
# blkid
/dev/mapper/sda2_crypt: UUID="c5635cd7-a7d5-41ce-8dfd-b09d6a0b8fbe" TYPE="ext4"
/dev/mapper/sda5_crypt: UUID="540bea45-2fb6-4003-b8d6-e897491d2a38" TYPE="swap"
/dev/mapper/lap_crypt: UUID="guiryP-Gy3h-v1w0-AogF-eG9d-Ih2W-ay0Wt8" TYPE="LVM2_member"

/dev/sda2: UUID="b8d00dfa-ce9c-4817-ab17-de8dc8ceb8ce" TYPE="crypto_LUKS"
/dev/sda5: UUID="9f0e7be1-6f92-4829-a2d1-45705f7200d7" TYPE="crypto_LUKS"
/dev/sdb5: UUID="9cd6a5b7-9250-4aa7-92c1-2ea328588e59" TYPE="crypto_LUKS"
/dev/sdc5: UUID="ec50d934-fda0-4b79-afbe-f2a649963c28" TYPE="crypto_LUKS"
<->
* Die crypttab anpassen wie folgt:
#sda2_crypt UUID=74e9067a-10a1-44c7-a63c-e37ed98fe229 none luks
sda2_crypt UUID=74e9067a-10a1-44c7-a63c-e37ed98fe229 none luks,discard,tries=3,keyscript=/etc/dcrypt/SSD-M4.sh

#sda5_crypt UUID=3366f575-75a6-4d81-a46f-5b6264898adc none luks,swap
sda5_crypt UUID=3366f575-75a6-4d81-a46f-5b6264898adc none luks,swap,tries=3,keyscript=/etc/dcrypt/SSD-M4.sh
rap_crypt UUID=353d408d-4949-45cb-b58d-dc2be5090634 none luks,keyscript=/etc/dcrypt/Raptor.sh
Im entsprechenden System hast Du das alles valide gesetzt?
(Nicht vergessen, nach dem Posten hier die device-ID wieder ändern)

Klappt wunderbar ohne zusätzliche Hooks für die initrd.
Du umgehst das Problem bei der ubuntu-Lösung,
die separate Konf mit in die initrd zu bekommen, daß Du die Variablen im Skript selbst setzt.

Das Skript sollte aufgebohrt werden, sodaß mehrere Stick Verwendung finden können.
Admin will/muß ja auch mal an den Rechner mit seinem Stick.


beim Generieren des initramfs wird der Keyfile angemeckert,
Das Skript wird wegen des 'keyscript=' in die initrd übertragen.
Falls es sich noch um diese Meldung dreht:
# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-0.bpo.1-amd64
cryptsetup: WARNING: target sda2_crypt uses a key file, skipped
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
cryptsetup: WARNING: target sda2_crypt uses a key file, skipped
, wegen

Code: Alles auswählen

   # If keyscript is set, the "key" is just an argument to the script
   if [ "$key" != "none" ] && [ -z "$KEYSCRIPT" ]; then
      echo "cryptsetup: WARNING: target $target uses a key file, skipped" >&2
      return 1
   fi
ist bei Dir wohl nicht 'keyscript=' (mit Deinem keyscript) in der crypttab gesetzt.
Bei Tests hier kann ich dort eine leere Datei angeben, sie muß nur ausführbar gesetzt sein.



Der Beitrag war wegen der unsichtbaren Keyfiles interessant,
Ein grundsätzliches Problem.
Der Stick kann komplett kopiert werden (auch die Serial).
Egal ob "unsichtbar" oder als Datei vorliegend.
Gerät der Stick in andere Hände, sind beide Lösungen ungeschützt.
Wird das USB-device auf dem System nur für root lesbar gehalten,
so schützt das beide Lösungen gegenüber unberechtigten Benutzern (nur) auf dem System.
Das "unsichtbar" ist eine pseudo-Sicherheit.

Vorteil der "Datei"-Lösung, bei Benutzung des Stick als Datenstick auch unter windows,
Dort wird der Stick normalerweise raw formatiert (<-> (fehlender) Platz für Deine "unsichtbar"-Lösung),
Benutzer weiß, daß er/sie die key-Datei noch hat oder daß sie weg ist.
Eine malware dürfte den Platz eines partitionierten Stick nach "Müll"-Code (also zBsp. nicht grub-stage1) untersuchen und die paar KB automatisch auf den NSA-Server übertragen (inkl. Stick- und Rechner-ID).
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

rhHeini
Beiträge: 807
Registriert: 20.04.2006 20:44:10

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rhHeini » 23.02.2017 18:49:53

rendegast hat geschrieben:
beim Generieren des initramfs wird der Keyfile angemeckert,
Das Skript wird wegen des 'keyscript=' in die initrd übertragen.
Falls es sich noch um diese Meldung dreht:
# update-initramfs -u -k all
update-initramfs: Generating /boot/initrd.img-4.9.0-0.bpo.1-amd64
cryptsetup: WARNING: target sda2_crypt uses a key file, skipped
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
cryptsetup: WARNING: target sda2_crypt uses a key file, skipped
, wegen

Code: Alles auswählen

   # If keyscript is set, the "key" is just an argument to the script
   if [ "$key" != "none" ] && [ -z "$KEYSCRIPT" ]; then
      echo "cryptsetup: WARNING: target $target uses a key file, skipped" >&2
      return 1
   fi
ist bei Dir wohl nicht 'keyscript=' (mit Deinem keyscript) in der crypttab gesetzt.
Bei Tests hier kann ich dort eine leere Datei angeben, sie muß nur ausführbar gesetzt werden.
Habe die Antwort mit Interesse gelesen. Wegen https://www.debian.org/releases/jessie/ ... d-features habe ich bei Jessie mit systemd nie in Betracht gezogen das trotzdem ein Keyscript da sein muss um die initramfs zu befriedigen. In dem Wiki-Eintrag https://wiki.debianforum.de/Cryptsetup_ ... _USB-Stick steht davon auch nichts.

Dann habe ich mir die Codezeile noch mal genau mit Hilfe des Advanced Batch Scripting Guide angesehen und verstanden das da ein Keyskript gefordert wird. Hatte es erst mal grob so gelesen das da kein Keyscript da sein darf. Habe halt nicht jeden Parameter/Befehl in den Skripten im Kopf. Wieder was gelernt.

Statt jedesmal neu auf dem Rechner im Keller zu installieren, habe ich VirtualBox auf meinem PC aktualisiert und dann gleich Stretch direkt von der iso probiert (die Installation läuft ziemlich schnell durch).
1.) Stur so wie im Wiki beschrieben: Endet in einer Endlosschleife weil nach 3 vergebliche Versuchen systemd 60s Pause einlegt und es dann wieder probiert.
2.) Ein leeres Keyskript angelegt, ausführbar gemacht und in die crypttab eingetragen: die Generierung der initramfs geht jetzt ohne Meldung duch, funktionell aber gleiches Ergebnis wie oben, geht auch nicht.

Dann in einem weiteren Versuch Wheezy verschlüsselt in eine VBox installiert und nach dem Ubuntu-Verfahren automatisch entschlüsselt. Upgrade auf Jessie vorbereitet, indem ich den Update nach systemd per Pinning laut https://www.debian.org/releases/jessie/ ... nit-system verhindere: Jetzt läuft Jessie in der Box ohne systemd und entschlüsselt sich automatisch nach dem alten Ubuntu-Verfahren mit 4.9er Kernel.

Mal schauen wie ich weiter mache. Vielen Dank an rendegast das Du mich auf das Thema Keyscript aufmerksam gemacht hast.

Gruss, Rolf

rendegast
Beiträge: 14272
Registriert: 27.02.2006 16:50:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rendegast » 24.02.2017 00:23:17

rhHeini hat geschrieben:
Bei Tests hier kann ich dort eine leere Datei angeben, sie muß nur ausführbar gesetzt werden.
...
2.) Ein leeres Keyskript angelegt, ausführbar gemacht und in die crypttab eingetragen: die Generierung der initramfs geht jetzt ohne Meldung duch, funktionell aber gleiches Ergebnis wie oben, geht auch nicht.
Aua, da habe ich leider nicht genau formuliert.
Der Test sollte nur die initramfs erstellen, und das klappt mit einer ebensolchen auch leeren Datei.

Natürlich klappt damit keine Extraktion des key, die muß ja gerade das "Skript" liefern
(passdev ist kein Skript, sondern ein binary).
Das keyscript kann eines der vorbereiteten aus /lib/cryptsetup/scripts/ sein,
oder sonstige wie auch immer geartete Eigenkonstruktion, zBsp. das Ding aus ubuntu-wiki.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")

rhHeini
Beiträge: 807
Registriert: 20.04.2006 20:44:10

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von rhHeini » 25.02.2017 22:48:09

Herzlichen Dank an rendegast, Problem gelöst.

Es geht nur mit einem Keyscript unter Jessie und Stretch in der crypttab, egal ob in der Doku steht das systemd mit Keyscripts nichts anzufangen weiss. Der Wiki-Eintrag ist falsch, keyfile-size und keyfile-offset kann man weg lassen. Diesmal ging auch das Hinzufügen eines Keys mit dem 4.9er Kernal problemlos.

Gruss, Rolf

breakthewall
Beiträge: 259
Registriert: 30.12.2016 23:48:51

Re: Automatische Entschlüsselung funktioniert nicht

Beitrag von breakthewall » 26.02.2017 01:02:01

rhHeini hat geschrieben:Herzlichen Dank an rendegast, Problem gelöst.

Es geht nur mit einem Keyscript unter Jessie und Stretch in der crypttab, egal ob in der Doku steht das systemd mit Keyscripts nichts anzufangen weiss. Der Wiki-Eintrag ist falsch, keyfile-size und keyfile-offset kann man weg lassen. Diesmal ging auch das Hinzufügen eines Keys mit dem 4.9er Kernal problemlos.

Gruss, Rolf
Der Manpage bzw. Wiki-Eintrag ist schon korrekt. Denn der Grund warum das so funktioniert, liegt an einer Debian seitigen Eigenheit des cryptsetup.

Offiziell bietet systemd keinen Support dafür an, und verweist auf andere Optionen: https://github.com/systemd/systemd/pull/3007

Antworten