[gelöst] Skript mit cryptsetup läuft nicht

[debianoli]

Hallo!

Ich habe mir heute eine Image-Datei als verschlüsselten Datenspeicher für den USB-Stick erstellt. Die .img-Datei binde ich per losetup ein. Hat auch alles gut geklappt, ich kann die .img-Datei per

Code: Alles auswählen

cryptsetup luksOpen /dev/loopX IMAGE

entsperren und dann mounten.

Jetzt wollte ich mir das alles vereinfachen und habe ein kleines Skript geschrieben, das ich per kdesu aufrufen will. Leider fragt mich das Skript nicht nach dem cryptsetup-Passwort. Was mache ich da falsch?

Aufgerufen wird das Skript als Root per

Code: Alles auswählen

ImageMount ImageDatei

Code: Alles auswählen

#!/bin/bash
losetup /dev/loop0 $1
cryptsetup luksOpen /dev/loop0 IMAGE
mkdir /mnt/image
mount /dev/mapper/IMAGE /mnt/image
chown -R $USER:$USER /mnt/image
exit 0

Die Image-Datei wird brav als Loop-Device eingebunden, eben nur nicht entsperrt.!

grüße

[Danielx]

Leider fragt mich das Skript nicht nach dem cryptsetup-Passwort.

Wenn du das Skript mit kdesu aufrufst, ist das auch nicht verwunderlich.

Warum setzt du denn die UID und GID in der vorletzten Zeile auf root?
Denn du führst das Skript als root aus.

Gruß,
Daniel

[stollenreiter]

Hallo.

Ich habe das mal mit kdesudo probiert. Mein Script läuft damit ohne Probleme. Allerdings ist mein luksOpen mit Keydatei gelöst:

Code: Alles auswählen

cryptsetup luksOpen /dev/loop0 loop_crypt -d /var/local/crypt.pass

Vielleicht hilft das ja.

[debianoli]

Leider fragt mich das Skript nicht nach dem cryptsetup-Passwort.

Wenn du das Skript mit kdesu aufrufst, ist das auch nicht verwunderlich.

Warum ist das nicht verwunderlich? cryptsetup benötigt doch das Passwort für die Image-Datei und dieses Passwort ist doch ein ganz anderes wie das Root-Passwort.

Warum setzt du denn die UID und GID in der vorletzten Zeile auf root?
Denn du führst das Skript als root aus.

Da hast du recht, das muss ich noch ändern. Allerdings will ich nicht unbedingt sudo einrichten. Trotzdem kann ich mit diesem Skript auch als Root das Image nicht per cryptsetup mounten, da ich das Passwort nicht eingeben kann.

Ich habe das mal mit kdesudo probiert. Mein Script läuft damit ohne Probleme. Allerdings ist mein luksOpen mit Keydatei gelöst:

Code: Alles auswählen

cryptsetup luksOpen /dev/loop0 loop_crypt -d /var/local/crypt.pass

Deine Lösung funktioniert, doch muss ich da nicht bei jeder verschlüselten Datei eine eigene Keydatei hinzufügen? Wie ich das verstanden habe, weiß cryptsetup sonst nicht, dass es das Image auch per Keydatei öffnen kann.

[stollenreiter]

Also, ich habe damals das Image/Container erstellt und dem ein Passwort gegeben. Anschliessend habe ich eine Datei angelegt, die ein richtig schönes übles Passwort enthält. Anschliessend habe ich dem Image/Container diese Datei als zweites Passwort zugewiesen. Das wars. Du kannst auch anderen Image/Container die gleiche Datei als zweites Passwort zuweisen. Habe ich auch gemacht.

Wenn mich nicht mehr alles täuscht, dann habe ich das über

Code: Alles auswählen

cryptsetup luksAddKey /dev/loop0 -d /var/local/crypt.pass

realisiert. Musst nur voher per losetup das Image/Container dem Device zu ordnen.

Was ich noch nicht geschafft habe, ist das automatische einbinden über /etc/crypttab.

[debianoli]

Was ich noch nicht geschafft habe, ist das automatische einbinden über /etc/crypttab.

Schau mal hier, mit diesem Howto habe ich das problemlos hinbekommen http://www.andreasjanssen.de/cryptodisk.html. Das einzige Problem, dass du da haben kannst, ist: Die Partition, auf der dein Keyfile liegt, ist noch nicht gemountet.

Ich habe das bei mir so gelöst:

1. Home in die crypttab eintragen. Dann fragt er dich beim Hochfahren nach dem Passwort für das verschlüsselte Home (man kann auch Root verschlüsseln)

2. Allen anderen Partition weist du ein Keyfile zu, das du z.B. in dein Home legst: /home/dein_user/Kryptokey

3. Nun änderst du die /etc/rc.local so ab, dass die verschlüsselten Partitionen eingebunden werden:

Code: Alles auswählen

cat /etc/rc.local

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

cryptsetup luksOpen /dev/hda8 hda8_crypt --key-file /home/dein_user/Kryptokey
mount /dev/mapper/hda8_crypt  /home/hda8  -t ext3

cryptsetup luksOpen /dev/hda5 hda5_crypt --key-file /home/dein_user/Kryptokey
mount /dev/mapper/hda5_crypt  /home/hda5  -t ext3

exit 0

[Danielx]

Warum ist das nicht verwunderlich? cryptsetup benötigt doch das Passwort für die Image-Datei und dieses Passwort ist doch ein ganz anderes wie das Root-Passwort.

Weil kdesu das Skript nicht in einer Konsole ausführt, in der du eine Benutzereingabe vornehmen könntest.
Verwende z.B. "su -c ..." oder sudo in einer Konsole.

Gruß,
Daniel

[debianoli]

Weil kdesu das Skript nicht in einer Konsole ausführt, in der du eine Benutzereingabe vornehmen könntest.
Verwende z.B. "su -c ..." oder sudo in einer Konsole.

Danke für den Tipp mit su -c, an das hätte ich gar nicht gedacht.

Ach ja, leider ist die deutsche Übersetzung der su-Manpage zur Option -c mehr als unverständlich:

Code: Alles auswählen

Die Optionen, die vom Befehl su unterstützt werden, sind:

       -c, --commandBEFEHL
           Gibt einen Befehl an, der von der Shell mittels ihrer Option -c ausgeführt wird.

Das dreht sich vom Sinn her doch irgendwie im Kreis, oder? Ich führe eine Option c aus, die Befehle mit der Option c ausführt. Das ist das gleich wie "ein Schraubenzieher ist ein Gerät, das Schrauben zieht".

[Danielx]

leider ist die deutsche Übersetzung der su-Manpage zur Option -c mehr als unverständlich:

In der englischen Version hört es sich auch nicht wirklich anders an:

-c, --command COMMAND
Specify a command that will be invoked by the shell using its -c.

Das dreht sich vom Sinn her doch irgendwie im Kreis, oder?

Nein, du rufst su mit der Option "-c" auf, welche bewirkt, dass der angegebene Befehl wiederum durch die Shell mit ihrer eigenen Option "-c" ausgeführt wird.
Sowohl su als auch die Shell kennen eine Option "-c".
su und die Shell sind verschiedene Programme, welche beide eine Option "-c" kennen.

Gruß,
Daniel

[debianoli]

Das dreht sich vom Sinn her doch irgendwie im Kreis, oder?

Nein, du rufst su mit der Option "-c" auf, welche bewirkt, dass der angegebene Befehl wiederum durch die Shell mit ihrer eigenen Option "-c" ausgeführt wird.
Sowohl su als auch die Shell kennen eine Option "-c".
su und die Shell sind verschiedene Programme, welche beide eine Option "-c" kennen.

Danke, jetzt hab ich das verstanden. Wenn man dazu die man-pages der bash liest, wird es klarer:

Code: Alles auswählen

In addition to the single-character shell options documented in the description of the set builtin command, bash interprets the following options when it is invoked:

       -c string If the -c option is present, then commands are read from string.  If there are arguments after the string, they are assigned to the positional parameters, starting with $0.

Grüße

oli

[debianoli]

Hallo,

habe mein Problem jetzt über libpam-mount gelöst. Dieses Pakte installiert eine PAM-Erweiterung für mount, mit der man verschlüsselte Dateien und Partitionen mounten kann. Ich habe dem Image dazu einen festen Schlüssel auf meiner Partition zugewiesen, dann geht es in einem Aufwasch:

Code: Alles auswählen

mount.crypt Image_Datei.img /media/IMAGE -o loop,users,key-file=/home/USER/mein_Schluessel

Zum Unmounten nimmt man dann umount.crypt

Wenn man den Schlüssel nicht angibt, dann muss man ihn auf der Konsole eingeben. Ist noch nicht so komfortabel, wie zuerst geplant, aber einfacher als cryptsetup und losetup

grüße und Danke für die Hilfe!