Verschlüsselte Backupdisks

[Trollkirsche]

Hallo,

Könnt ihr mir helfen?

Ich möchte eine verschlüsselte Backupdisk erstellen. Ich hab mir das so vorgestellt, dass ich auf der ganzen Festplatte einen verschlüsselten Datenträger per Luks anlege, diesen öffne und darin dann 2 primäre ext4 Partitionen erstelle.

Leider scheitere ich beim Partitionieren des verschlüsselten Datenträgers.

Folgendermassen bin ich vorgegangen :

1. Erstmal die komplette HD verschlüsseln :
cryptsetup luksFormat -c serpent-xts-plain64 -s 512 -h sha512 /dev/sdX

2. Den verschlüsselten Datenträger öffnen:
cryptsetup luksOpen /dev/sdX sdX_crypt

Ab hier fangen die Probleme an. Ich habe die Partitionierung per GNU Parted probiert. Hierzu habe ich erst eine ms-dos table erstellt und das auf der sdX_crypt Datei, die sich im /dev/mapper Ordner befindet:

parted /dev/mapper/sdX_crypt // Datenträger auswählen
mktable msdos // Eine MSDOS Partitionstabelle im offenen Datenträger erstellen
mkpart primary ext4 0 1325GB // 1. ext4 Partition erstellen

Warning: The resulting partition is not properly aligned for best performance.
Ignore/Cancel? Ignore

mkpart primary ext4 1325GB 100%

Error: partition length of 5226139648 sectors exceeds the msdos-partition-table-imposed maximum of 4294967295

Dies ist die Antwort die erhalte. Was genau mach ich falsch?

Gruss,

[NAB]

hmmm ... mal schauen. er meckert ja, dass die Partition zu groß für eine MBR-Partitionierung ist:

Error: partition length of 5226139648 sectors exceeds the msdos-partition-table-imposed maximum of 4294967295

Wenn man von 512-Byte-Blöcken ausgeht:

Code: Alles auswählen

$ echo "5226139648*512/1024/1024/1024" | bc
2492

dann wären das knapp 2,5 TB - das wäre in der Tat zu groß für eine MBR-Partition. Die Frage ist, wie kommt er darauf?

Da parted eigentlich auch kein "mktable" kennt, vermute ich mal, du hast den Kram abgetippt und tippe auf "Tippfehler".

Für Partitionen größer 2 TB musst du eine GPT-Partitionierung verwenden. Beispiel hier:
https://plone.lucidsolutions.co.nz/linu ... device-2tb

[wanne]

MBR Partitionstabellen gibt es nur für ganze Datenträger. Die dürfen nicht verschachtelt werten.
Entweder du benutzt irgend welche Hilfskonstrukte wie LVM um die einzelne Verschlüsselte Partition zu unterteilen.
Oder (würde ich massiv empfehlen.) du verschlüsselst beide Partitionen einzeln. LUKS bietet absichtlich viele Möglichkeiten Mehrere Partitionen mit einem Passwort zu entschlüsseln: (Es wurde z.B. Absichtlich darauf geachtet, dass mehrere Partitionen mit dem gleichen PW kein Problem sind. (Und beim booten werden immer alle HDDs mit gleichem Passwort auf einmal geöffnet.) Außerdem werden Keyfiles unterstützt, die sinnvollerweise eben auf einer anderen Verschlüsselten Partition liegen.

[Trollkirsche]

Halli hallo,

Herzlichen Dank für eure Antworten euch beide!

Erstmal zur Fehlermeldung. Das wars. Wenn ich eine GPT Partitionstabelle anlege dann klappts. Ich Hirni habe nicht bedacht das msdos Paritionstabellen max. 2GB Grösse zulassen.

Dennoch frage ich mich folgendes : Ich erhalte beim Partitionieren folgende Warnung :

mkpart primary ext4 0 1325
Warning: The resulting partition is not properly aligned for best performance.

Ich habe versucht anhand dieser Anleitung : http://rainbow.chard.org/2013/01/30/how ... ng-parted/
die Warnung zu umgehen. Wenn ich mir jedoch die "optimal_io_size" im /sys des zugehörigen dm-Laufwerks anzeigen lassen will, erhalte ich 0.

Wieso ist das so? Hat das seine Richtigkeit?

@wanne:

2 einzeln verschlüsselte Partitionen war eigentlich mein Ursprungsgedanke. Ich ging jedoch davon aus, dass ein einziger verschlüsselter Datenträger mit 2 ext4 Partitionen als Inhalt sauberer sei.

In der Tat habe ich bereits die Schlüsseldatei implementiert. Ich werd das dann wohl so machen, dann kann ich mit Gparted arbeiten und die Performance-Warnung umgehen. Dennoch würde ich gern verstehen, wie ich per parted die beste Performance erreichen kann.

Herzlichen Dank nochmal!

[NAB]

hmmmm ... parted kennt die Kommandozeilenoption "--align optimal" ... ich weiß aber nicht, wie man die interaktiv nutzt. Eventuell mit:
parted --align optimal /dev/mapper/sdX_crypt
Sonst müsstest du die Partition mit einem Einzeiler erstellen, in der Art:
parted --align optimal /dev/mapper/sdX_crypt mkpart ext4 0 1325

Ansonsten wird im Arch-Wiki allen Ernstes vorgeschlagen, unterschiedliche Startsektoren durchzuprobieren, bis parted nicht mehr meckert:
https://wiki.archlinux.org/index.php/GN ... #Alignment

Praktisch wäre es, wenn du die GUI-Version "gparted" nutzen könntest, die kümmert sich nämlich automatisch um das Alignment

[Trollkirsche]

hmmmm ... parted kennt die Kommandozeilenoption "--align optimal" ... ich weiß aber nicht, wie man die interaktiv nutzt. Eventuell mit:
parted --align optimal /dev/mapper/sdX_crypt
Sonst müsstest du die Partition mit einem Einzeiler erstellen, in der Art:
parted --align optimal /dev/mapper/sdX_crypt mkpart ext4 0 1325

Ansonsten wird im Arch-Wiki allen Ernstes vorgeschlagen, unterschiedliche Startsektoren durchzuprobieren, bis parted nicht mehr meckert:
https://wiki.archlinux.org/index.php/GN ... #Alignment

Praktisch wäre es, wenn du die GUI-Version "gparted" nutzen könntest, die kümmert sich nämlich automatisch um das Alignment

Ah sehr schön, danke für die Erläuterungen. Ich werde sicherlich wieder parted ausprobieren, nicht zuletzt weil es teil der LPIC Prüfung ist
Momentan begnüge ich mich jedoch mit GPparted und erstelle, wie von wanne vorgeschlagen 2 verschlüsselte, separate Partitionen, die ich dann mit der Schlüsseldatei öffne.

Leider kämpfe ich da grad mit einem weiteren Hindernis. Ich habe die 2 verschlüsselten luks Datenträger mit der Schlüsseldatei erstellt und darin dann jeweil die darin befindliche ext4 Partition kreiert.

Ebenfalls habe ich in der crypttab den Eintrag :
backup_crypt UUID=28fb84e0-aecc-6b2e-85b4-b6c2c641b6f6 /.lkey/key luks

und fstab :
/dev/mapper/backup_crypt /media/backup ext4 rw,nosuid,noauto 0 2


getätigt und den Befehl "update-initramfs -u -k all" ausgeführt.

Die Backupplatte mountet nicht automatisch. Ich muss das Passwort manuell eingeben, dann mountet ers.
Ebenfalls sehe ich mittels des Befehls "blkid -o list" nicht die backup_crypt sobald ich per GUI mounte und die Passphrase eingeben, sondern etwas in der Art : /dev/mapper/luks-3b348211-3fb993-2fb92-94f1-737f47af3bf4b

Weisst du worans liegt, das er die Platte nicht automatisch mounted,sobald ich das Laufwerk in der GUI auswähle?

[NAB]

Gute Frage ... mit "noauto" mounted er natürlich nicht auto-matisch.

Und die UUID=28fb84e0... ist die UUID von /dev/sdX1?

[Trollkirsche]

Gute Frage ... mit "noauto" mounted er natürlich nicht auto-matisch.

Und die UUID=28fb84e0... ist die UUID von /dev/sdX1?

In der Tat..

Ich hab den Fehler gemacht die UUIDs der gemountetes Geräte genommen anstelle der /dev/ Geräte. Das war der Fehler. Wieder etwas gelernt.

Soweit so gut, klappt alles. Wenn ich jetzt noch herausfinde, wie ich den Namen der Partitionen noch VOR dem click auf derselben anzeigen lassen kann, anstelle eines schönden "1.3 TV verschlüsselt", dann wär ich komplett glücklich.

Der Name "Backup" erscheint erst, wenn ich auf die Partition klicke.

[NAB]

Tja ... noch ne gute Frage ...

Wenn ich dich recht verstehe, wird /dev/mapper/backup_crypt jetzt automatisch beim Booten erzeugt. Die Partition wird also entschlüsselt, aber nicht gemounted.

Woher soll er also wissen, dass sie "Backup" heißt? Er könnte höchstens in der fstab nachgucken, und darauf kommen, dass die Partition nach /media/backup gemounted werden soll. Das ist eigentlich nicht sein Job ... er stößt ja nur ein "mount /dev/mapper/backup_crypt" an und lässt den Kernel den Rest machen.

Wobei ... tut er das überhaupt? Dazu fehlt in deiner fstab eigentlich die Option "users". Landet die Partition unter /media/backup oder unter /media/Backup?

Und willst du überhaupt, dass jeder angemeldete User die Partition mounten kann?

[Trollkirsche]

Tja ... noch ne gute Frage ...

Wenn ich dich recht verstehe, wird /dev/mapper/backup_crypt jetzt automatisch beim Booten erzeugt. Die Partition wird also entschlüsselt, aber nicht gemounted.

Woher soll er also wissen, dass sie "Backup" heißt? Er könnte höchstens in der fstab nachgucken, und darauf kommen, dass die Partition nach /media/backup gemounted werden soll. Das ist eigentlich nicht sein Job ... er stößt ja nur ein "mount /dev/mapper/backup_crypt" an und lässt den Kernel den Rest machen.

Wobei ... tut er das überhaupt? Dazu fehlt in deiner fstab eigentlich die Option "users". Landet die Partition unter /media/backup oder unter /media/Backup?

Und willst du überhaupt, dass jeder angemeldete User die Partition mounten kann?

Sodele, da bin ich wieder, nach einem langen Tag der Arbeit

Nein, komischerweise erzeugt er beim Systemstart die /dev/mapper dateien für die Laufwerke beim Systemstart nicht. Erst wenn ich im Dateimanager auf die Laufwerke klicke, werden die /dev/mapper Dateien erzeugt. Diese werden dann jedoch automatisch gemountet und eine Passworteingabe ist nicht notwendig.

Wenn ich die Datei per "cryptsetup luksOpen" öffne, erscheinen sie auch ungemounted im /dev/mapper verzeichnis und werden mit dem richtigen Label im Dateimanager angezeigt und nicht nur mit "1.3TB verschlüsselt".

Ich hab nochmals versucht nach dem öffnen der verschlüsselten Datenträger die initramfs neu zu erzeugen und hab dann neu gestartet. Ist immer noch gleich, beim Systemstart keine offenen /dev/mapper Dateien.

Irgendwo mach ich wohl etwas falsch...

[NAB]

Nein, das sieht alles richtig aus ... und funktioniert ja eigentlich auch.

Es mag sein, dass Systemd da seine Finger im Spiel hat und schlau genug ist festzustellen, dass diese Partition zum Booten nicht benötigt wird und sie darum gar nicht erst entschlüsselt beim Booten. Mit Systemd kenne ich mich nicht wirklich gut aus, aber in die Richtung könntest du noch mal recherchieren.

Davon abgesehen musst du dir überlegen, was du eigentlich willst. Wenn die Platte wirklich immer ans System angeschlossen ist, dann macht es Sinn, einfach das "noauto" aus der fstab zu nehmen. Aber wenn sie nur hin und wieder eingesteckt wird, dann ist es ja genau so, wie es jetzt ist, optimal. Du könntest höchstens per selbstgemachter udev-Regel ein Entschlüsseln beim Einstecken anstoßen.

[Trollkirsche]

Nein, das sieht alles richtig aus ... und funktioniert ja eigentlich auch.

Es mag sein, dass Systemd da seine Finger im Spiel hat und schlau genug ist festzustellen, dass diese Partition zum Booten nicht benötigt wird und sie darum gar nicht erst entschlüsselt beim Booten. Mit Systemd kenne ich mich nicht wirklich gut aus, aber in die Richtung könntest du noch mal recherchieren.

Davon abgesehen musst du dir überlegen, was du eigentlich willst. Wenn die Platte wirklich immer ans System angeschlossen ist, dann macht es Sinn, einfach das "noauto" aus der fstab zu nehmen. Aber wenn sie nur hin und wieder eingesteckt wird, dann ist es ja genau so, wie es jetzt ist, optimal. Du könntest höchstens per selbstgemachter udev-Regel ein Entschlüsseln beim Einstecken anstoßen.

Hallo NAB,

Ja, von der Funktionalität her gibt es nichts zu beanstanden, alles tiptop! Es stört mich halt nur, dass ich im Dateimanager erst sehe, um welche Partition es sich handelt, wenn sie gemountet ist. So wird das weitere Hinzufügen der Partition mit der Option noauto zum Ratespiel. Bei den Backups ist meines Erachtens das Ein/Aushängen nur bei der Backup-Operation sinnvoll. Ansonsten sollten sie besser nicht in das System integriert werden. Bei einem NAS ist das sicherlich anders.

Gut ist schlussendlich nur ein Detail ich werd die Platten so einrichten.

Herzlichen Dank nochmal!