UUID von verschüsselter Systempartition ändern.

[ottonormal]

Hallo,

ich habe einen Zweitrechner mit einem Luks-verschlüsselten Sparky (Buster) darauf. Nun habe ich das System mit dd auf eine ext. Festplatte geklont zum Testen und Experimentieren. Das funktioniert (meist) auch ziemlich gut, oft aber eben auch nicht. Das äußert sich dann so, dass ich das geklonte System auf der ext. Platte starte, dann aber auf dem fest installiertem System des Rechners lande. Nun möchte ich gerne mit gparted die UUID des (ext.) Testsystems ändern um die Probleme damit zu beseitigen.

Was muss ich dabei beachten um keine unliebsamen Überraschungen zu erleben, damit das System danach auch wieder normal bootet?

[ottonormal]

Es scheint wohl nicht so einfach zu sein.
Was ich aber überhaupt nicht verstehen kann: Beide Systeme, das Original auf dem Rechner und der Klon auf der ext. Festplatte, sind ja verschlüsselt. Beide haben aber ein eigenes Passwort.
Wenn ich nun beim Booten die ext. Festplatte mit dem Klon auswähle und das richtige Passwort dafür eingebe, wird trotzdem (nicht immer) das andere System (ohne Passwort) gebootet. Wie ist das möglich, das kann doch nicht sein!?

Ist es eigentlich irgendwie möglich alle anderen Systeme vor dem Zubootenden automatisch zu verstecken bzw. unsichtbar zu machen?

[DeletedUserReAsG]

Es scheint wohl nicht so einfach zu sein.

Die Aufgabe ansich ist im Grunde trivial, wenn man die dafür vorgesehenen Werkzeuge benutzt (Alternativsystem, cryptsetup und tune2fs im Fall eines extX-FS’). Was es nicht so einfach macht, ist die Forderung, dass es mit dem dafür nicht geeigneten (da bin ich mir zugegebenermaßen nicht ganz sicher, zumindest ist’s kein dafür geläufiges) Werkzeug gemacht werden soll.

Edit, Ergänzung:

Wenn ich nun beim Booten die ext. Festplatte mit dem Klon auswähle und das richtige Passwort dafür eingebe, wird trotzdem (nicht immer) das andere System (ohne Passwort) gebootet. Wie ist das möglich, das kann doch nicht sein!?

Der Schlüssel ist für beide Partitionen der Gleiche, das ließe sich nur durch eine komplette Neuverschlüsselung einer Partition ändern. Die Passwörter (eigentlich sollten es ja auch Passphrases sein) dienen nur dazu, den Schlüssel zu sichern – sobald er beim Booten für eine Partition freigeschaltet wurde, lässt er sich für beide Partitionen verwenden.

[debianoli]

Der Schlüssel ist für beide Partitionen der Gleiche, das ließe sich nur durch eine komplette Neuverschlüsselung einer Partition ändern. Die Passwörter (eigentlich sollten es ja auch Passphrases sein) dienen nur dazu, den Schlüssel zu sichern – sobald er beim Booten für eine Partition freigeschaltet wurde, lässt er sich für beide Partitionen verwenden.

Man bei luks doch Schlüssel-Slots hinzufügen und auch entfernen. Also bei der einen Partition einen anderen Key hinzufügen und dann den Schlüssel mit dem gleichen Passwort wie die andere Platte löschen

[DeletedUserReAsG]

Man [kann] bei luks doch Schlüssel-Slots hinzufügen und auch entfernen. Also bei der einen Partition einen anderen Key hinzufügen und dann den Schlüssel mit dem gleichen Passwort wie die andere Platte löschen

Ja, kann man. Hat aber keine Auswirkung auf den Schlüssel selbst. Du kannst mal deinen Header sichern, dann alle acht Passphrase-Slots neu belegen, den gesicherten Header zurückkopieren und dann mit einer alten Passphrase deine Partition entschlüsseln.

Wenn hier nun also beim Booten Partition A gestartet wird, man das Passwort von Partition A eingibt und das System, aus welchem Grund auch immer, damit auf Partition B zugreift, ist’s völlig egal, was in den Slots des Headers von Partition B ist – der Schlüssel ist ja der Gleiche, und wurde von Partition A aus mit einer dazugehöhrigen Passphrase entschlüsselt.

TE sollte tatsächlich einfach die UUID ändern, die Bootloaderconfig anpassen, und sich der Tatsache bewusst sein, dass beide Partitionen immer noch mit demselben Schlüssel verschlüsselt sind, wenn er also jemandem eine Passphrase für das eine System gibt, hat dieser Jemand damit und mit dem Header auch Zugriff auf das andere System – auch, wenn dort mittlerweile andere Passphrases hinterlegt worden sind.

[wanne]

Nun möchte ich gerne mit Debiangparted die UUID des (ext.) Testsystems ändern um die Probleme damit zu beseitigen.

Ich glaube nicht, dass gparted das kann. (Vielleicht irrec ich mich aber auch.)
Bedenke, dass sowohl luks wie auch das Dateisystem im luks eine uuid hat.

Code: Alles auswählen

cryptsetup luksUUID --uuid $(uuidgen) /dev/sdxX #für LUKS
tune2fs -U random /dev/mapper/cryptdisk # für ext*
btrfstune -u  /dev/mapper/cryptdisk # für btrfs
xfs_admin -U generate /dev/mapper/cryptdisk # für XFS

Zuerst solltest du mal in die fstab schauen, ob da irgend wo UUIDs drin sind. – Wenn ja: Austauschen.
Wenn du systemd verwendest musst du dem manuell mitteilen, dass die sich geändert hat:

Code: Alles auswählen

systemctl daemon-reload

Grub verwendet gerne UUIDs du willst also nochmal ein update-grub ausfürhen.
Ich würde auch vorsichtshalber das initramfs neu bauen.

Code: Alles auswählen

update-initramfs -k all -u

Im Zweifelsfall in einer chroot.

[ottonormal]

Danke für Eure Antworten.
Eigentlich hatte ich mir das ja etwas einfacher vorgestellt, ich glaube aber, dass mich das doch überfordert.
Zwischenzeitlich habe ich mal an einem (unverschlüsseltem) Testsystem eine Änderung der UUID mit gparted versucht. Da ging anschließend nichts mehr.

Dann irritiert mich ja auch noch, dass ein verschlüsseltes System 2 UUIDs hat. Ich werde davon also wohl besser die Finger lassen und das ext. Testsystem in die VBox verfrachten, auch wenn's nicht ganz so schön ist.