Welche verschlüsselte Partitionen werden außerhalb der /etc/crypttab eingebunden

[Rosenrot]

Hallo,
ich habe gerade ein Debian ganz frisch installiert.
Dabei gibt es drei bereits beim installieren verschlüsselte Partitionen.
Eine root, eine Home und eine Swap Partition.
Da der Bootloader (auf dem Computer gibt es noch ein anderes System, also Debian selbst hat keinen Bootloader mit installiert) Debian nicht erkennt, habe ich einen eigenen Eintrag geschrieben.
So weit so gut, wird auch alles gebootet.
Nur kann ich die Punkte an denen die entschlüsselte Partition gemappt wird nicht mehr ändern. Das booten wird dann abgebrochen und er sagt die Datei gibt es nicht. Dabei wird die doch automatisch erstellt.
Ich muss also genau den Punkt angeben, der bei der Installation dafür festgelegt wurde.
Des weiteren habe ich einfach um die Ursache dieses Verhaltens herauszufinden die /etc/crypttab komplett auskommentiert. Mit dem Ergebnis, dass die Root und die Swap-Partition dennoch entschlüsselt werden konnten während des Hochfahrens.
Erst beim mounten der Home-Partition meckerte das System.
Kaum war die Zeile in der /etc/crypttab wieder eingefügt ging auch diese Partition entschlüsseln und (wie alle anderen auch) per /etc/fstab mounten.
Meine Fragen sind nun:
Wieso kann ich diese Mapper-Einträge nicht verändern (also z. B. /dev/mapper/home)? Verändere ich den Namen des Eintrags in der /etc/crypttab, der /etc/fstab und in meinem manuellen Grub2-Eintrag muss ich teilweise eine Partition während des Hochfahrens zwei mal entschlüsseln. Aber nicht gleich hintereinander. Mit dem Passwort hat es also nichts zu tun.
Ich möchte diese Einträge aber ändern weil ich dann besser damit arbeiten kann. Ist einfach eine persönliche Vorliebe.
Und zweitens: Ist es normal das Root und Swap auch ohne einen Eintrag in die /etc/crypttab beim Hochfahren entschlüsselt werden?
Zum Verständnis: In der /etc/fstab stehen sie natürlich drinnen.
Ich bin noch nicht lange bei Debian dabei und muss das System noch ein wenig besser kennen lernen.
Deswegen die Fragen. Es stört mich nicht aber ich bin interessiert und möchte auch natürlich erkennen wenn ich was falsch gemacht habe.
Lieben Gruß
Rosenrot

[spiralnebelverdreher]

Hallo,
ich habe gerade ein Debian ganz frisch installiert.

Glückwunsch!
Wenn du in deinen Beiträgen noch dazu schreibst, ob es sich um stable oder einen anderen Zweig handelt ist das hilfreich.

Dabei gibt es drei bereits beim installieren verschlüsselte Partitionen.
Eine root, eine Home und eine Swap Partition.
Da der Bootloader (auf dem Computer gibt es noch ein anderes System, also Debian selbst hat keinen Bootloader mit installiert) Debian nicht erkennt, habe ich einen eigenen Eintrag geschrieben.

Das ist ein wichtiger Punkt für die kommenden Fragen. Welcher andere Bootloader wird denn zuerst gestartet? Was ist noch installiert? Ein Ubuntu? Wie sieht dein Eintrag aus und wo steht er drin? Grub ist da recht flexibel und erlaubt verschieden Herangehensweisen (Chain Loading, Erweiterung bestehender Grub Konfigurationen).

So weit so gut, wird auch alles gebootet.
Nur kann ich die Punkte an denen die entschlüsselte Partition gemappt wird nicht mehr ändern. Das booten wird dann abgebrochen und er sagt die Datei gibt es nicht. Dabei wird die doch automatisch erstellt.
Ich muss also genau den Punkt angeben, der bei der Installation dafür festgelegt wurde.
Des weiteren habe ich einfach um die Ursache dieses Verhaltens herauszufinden die /etc/crypttab komplett auskommentiert. Mit dem Ergebnis, dass die Root und die Swap-Partition dennoch entschlüsselt werden konnten während des Hochfahrens.
Erst beim mounten der Home-Partition meckerte das System.
Kaum war die Zeile in der /etc/crypttab wieder eingefügt ging auch diese Partition entschlüsseln und (wie alle anderen auch) per /etc/fstab mounten.
Meine Fragen sind nun:
Wieso kann ich diese Mapper-Einträge nicht verändern (also z. B. /dev/mapper/home)?

Was steht denn original in der /etc/crypttab drin?

Verändere ich den Namen des Eintrags in der /etc/crypttab, der /etc/fstab und in meinem manuellen Grub2-Eintrag muss ich teilweise eine Partition während des Hochfahrens zwei mal entschlüsseln. Aber nicht gleich hintereinander. Mit dem Passwort hat es also nichts zu tun.

Die Dateien /etc/fstab und /etc/crypttab wohnen ja im Root Filesystem und sind beim Booten anfangs noch nicht zugänglich. Deshalb hast du Grub (ist eine Vermutung von mir, dass du das so gemacht hast!!) ja über die Konfig-Datei mitgeteilt, dass sich das Root Dateisystem in einer verschlüsselten Partition befindet (zumindest bei meiner Installation ist das so) und beim Booten wirst du deshalb nach dem Passwort gefragt. Der (überflüssige) zusätzliche Eintrag von / in der fstab sorgt dafür, dass zum späteren Zeitpunkt das Gerät gemounted werden will und deshalb wirst du ein zweites Mal nach dem Passwort gefragt.

Und zweitens: Ist es normal das Root und Swap auch ohne einen Eintrag in die /etc/crypttab beim Hochfahren entschlüsselt werden?

Ja, siehe oben. Grub (ist eine Vermutung von mir, dass du das so gemacht hast!!) weiß von den verschlüsselten Partitionen.

Zum Verständnis: In der /etc/fstab stehen sie natürlich drinnen.
Ich bin noch nicht lange bei Debian dabei und muss das System noch ein wenig besser kennen lernen.
Deswegen die Fragen. Es stört mich nicht aber ich bin interessiert und möchte auch natürlich erkennen wenn ich was falsch gemacht habe.

Das ist genau die richtige Einstellung: nachschauen, nachdenken, Fragen stellen.

[Rosenrot]

Hi,
danke schon mal für deine Hilfe.
Mein Debian ist stable. Es handelt sich also um Debian-stretch.
Als zweites System ist ein Arch-Linux installiert.
Das läuft auch problemlos und ist auf die selbe Art und Weise verschlüsselt.
Der Bootloader ist grub2. Irgendwie hatte ich das vorausgesetzt. Da hab ich geschlafen.
Es gibt nur diesen einen Bootloader.
Mich hat als erstes schon mal gewundert, dass grub Debian nicht erkennt. Beide Boot-Partitionen sind selbstverständlich unverschlüsselt und voneinander getrennt. Es gibt also keine gemeinsame Boot-Partition für beide Systeme.

Leider ist die komplette Installation noch im Aufbau. Ich habe also erst die Arch-Linux Grundinstallation und die Debian Grundinstallation machen wollen bevor ich beide Systeme einrichte. Dann habe ich nicht so viel Zeit verschwendet wenn bei der zweiten Installation irgendwas schief gehen sollte und ich komplett neu aufsetzen muss. Kann ja auch mal vorkommen, so etwas.
Deswegen müsste ich die Dateien nach denen du gefragt hast komplett abtippen. Die werden also auch noch zeitnah gepostet.
In der /etc/crypttab stehen original die Root-, Home- und Swap-Partition drin. Ebenso in der /etc/fstab. In dieser zudem noch die Boot-Partition. Die Einträge sind mapper-technisch richtig. In dieser Hinsicht bilden sie also das manuelle entschlüsseln und mounten mittels cryptsetup ab. Ebenso mein Eintrag in die Datei /etc/grub.d/40_os-prober. Der wird aber auch noch gepostet.
Das Problem ist vielmehr, das ein ändern dieser Einträge (ich meine jetzt explizit den Namen des Mapper-Eintrags in der 40_os-prober) zu einem Fehler beim booten führt. Nur wenn dieser Name genau so ist wie er bei der Installation festgelegt wurde bootet das System fehlerfrei.
Um diesen einen Namen geht es mir. Den möchte ich ändern.

[Rosenrot]

Hallo,

ich hab noch mal ein paar "Experimente" gemacht.
Als erstes habe ich alle Einträge der /etc/crypttab ausgeklammert. Ergebnis: Root und Swap werden während des bootens trotzdem entschlüsselt. Bei Root war mir das klar. Beim Swap wundert es mich. Vor allem wegen folgender Tatsache. Klammere ich Swap in der /etc/fstab aus, wird er nicht gemountet. Beim booten wurde er aber trotzdem entschlüsselt. Den Eintrag für die Root-Partition habe ich auch aus der /etc/fstab ausgeklammert. Er war wie erwartet wirklich unnötig.
Also werden die Root-, und die Swap-Partition unabhängig (wie mir ja schon gesagt wurde) von der /etc/crypttab entschlüsselt.
Meine Frage ist aber: welcher Teil des Systems ist dafür zuständig, da ich ja Änderungen vornehmen möchte.

Hier ist mal meine /etc/grub.d/40_custom:

Code: Alles auswählen

menuentry "Debian" {
load_video
set gfxpayload=keep
insmod gzio
insmodpart_msdos
insmod ext2
linux /vmlinux-4.9.0-3-amd64 root=UUID des bereits entschlüsselten Dateisystems rw cryptdevice=/dev/sda1:sda1_crypt root=/dev/mapper/sda1_crypt lang=de locale=de_DE.UTF-8
initrd /initrd.img-4.9.0-3-amd64
}

Wie gesagt:
Es bringt rein gar nichts den mapper-Eintrag in dieser Datei zu ändern. Das führt zu einem Fehler beim hochfahren.
Gruß
Rosenrot

[spiralnebelverdreher]

Hallo,

ich hab noch mal ein paar "Experimente" gemacht.
Als erstes habe ich alle Einträge der /etc/crypttab ausgeklammert. Ergebnis: Root und Swap werden während des bootens trotzdem entschlüsselt. Bei Root war mir das klar. Beim Swap wundert es mich. Vor allem wegen folgender Tatsache. Klammere ich Swap in der /etc/fstab aus, wird er nicht gemountet. Beim booten wurde er aber trotzdem entschlüsselt. Den Eintrag für die Root-Partition habe ich auch aus der /etc/fstab ausgeklammert. Er war wie erwartet wirklich unnötig.
Also werden die Root-, und die Swap-Partition unabhängig (wie mir ja schon gesagt wurde) von der /etc/crypttab entschlüsselt.
Meine Frage ist aber: welcher Teil des Systems ist dafür zuständig, da ich ja Änderungen vornehmen möchte.

Hier ist mal meine /etc/grub.d/40_custom:

Code: Alles auswählen

menuentry "Debian" {
load_video
set gfxpayload=keep
insmod gzio
insmodpart_msdos
insmod ext2
linux /vmlinux-4.9.0-3-amd64 root=UUID des bereits entschlüsselten Dateisystems rw cryptdevice=/dev/sda1:sda1_crypt root=/dev/mapper/sda1_crypt lang=de locale=de_DE.UTF-8
initrd /initrd.img-4.9.0-3-amd64
}

Wie gesagt:
Es bringt rein gar nichts den mapper-Eintrag in dieser Datei zu ändern. Das führt zu einem Fehler beim hochfahren.
Gruß
Rosenrot

Der Weg zur Änderung sollte rückwärts gedacht hier bei der Option initrd /initrd.img-4.9.0-3-amd64 beginnen:

Code: Alles auswählen

menuentry "Debian" {
....
linux /vmlinux-4.9.0-3-amd64 root=UUID des bereits entschlüsselten Dateisystems rw 
cryptdevice=/dev/sda1:sda1_crypt root=/dev/mapper/sda1_crypt lang=de locale=de_DE.UTF-8 initrd /initrd.img-4.9.0-3-amd64

Mittels der Anweisung initrd /initrd.img-4.9.0-3-amd64 gibt der Grub dem Kernel ein kleines (ins RAM passendes) Dateisystem mit, das schon früh im Bootprozess verwendet wird. Ich vermute mal, dass die dortigen Eintragungen für das Mappen, Entschlüsseln und Mounten von root und swap die entscheidenden sind.
Du solltest also nach den Änderungen der crypttab noch folgendes ausführen (initiales kleines Dateisystem neu erzeugen und dies dem Grub mitteilen):

Code: Alles auswählen

update-initramfs -k all -c
update-grub

Das ist der Debian-Weg, bei Arch nennt sich das Äquivalent glaube ich mkinitcpio. Solltest du prüfen, auch ob die Optionen stimmen.

Bei einer swap Partition kann die Festlegung des Schlüssels bei jedem Systemstart neu erfolgen, solange man keine Resume-Funktion erwartet. Das bedeutet, dass beim Booten gar nichts entschlüsselt wird! Will man dagegen haben, dass Daten in der swap Partition einen Reboot überleben braucht man einen dauerhaften Schlüssel. Dieser könnte im verschlüsselten / Filesystem abgelegt werden. Keine Ahnung, was in deinem Fall zutrifft.

[Rosenrot]

Hallo,

genau, so was habe ich gesucht.
Der Befehl ist schon mal super.
Nur denke ich es wird nichts nutzen vorher die /etc/crypttab zu editieren.
Die wird da nicht übernommen. Weil sie ganz offensichtlich beim booten dynamisch gelesen wird. Das ist auch bei Arch-Linux so.
Dort gibt es eine Datei (mkinitcpio.conf) in der muss vor dem erstellen des initramfs die HOOK-Zeile verändert werden.
Das bedeutet diese Datei wird beim erstellen als Konfig-Quelle genutzt.
Weiß zufällig jemand ob es ein Äquivalent bei Debian gibt, wie es heißt und wo ich es im System finden kann?

Gruß
Rosenrot

[spiralnebelverdreher]

Nur denke ich es wird nichts nutzen vorher die /etc/crypttab zu editieren.
Die wird da nicht übernommen. Weil sie ganz offensichtlich beim booten dynamisch gelesen wird. Das ist auch bei Arch-Linux so.
Dort gibt es eine Datei (mkinitcpio.conf) in der muss vor dem erstellen des initramfs die HOOK-Zeile verändert werden.
Das bedeutet diese Datei wird beim erstellen als Konfig-Quelle genutzt.
Weiß zufällig jemand ob es ein Äquivalent bei Debian gibt, wie es heißt und wo ich es im System finden kann?

Beim Booten ist das in meinem Verständnis nicht dynamisch. Da wird stur abgespult, was vorher (mittels update-initramfs und update-grub) festgelegt wurde und sich nun in GRUB Menüzeilen und in diesem "initrd" Dateisystem wiederfindet.

Schau dir mal das Verzeichnis /etc/initramfs-tools/ an und vergleiche die man-Einträge für mkinitcpio bei Arch und mkinitramfs bei Debian. Mangels eigener Erfahrung kann ich da nur Vermutungen anstellen. Deshalb würde ich dir auch raten, dazu bei weiteren Fragen einen eigenen Thread mit einem neuen Titel aufzumachen, um die Foristen anzusprechen die sowohl debian als auch arch benutzen.

[Rosenrot]

Hi,

ich habe deine Idee jetzt mal ausprobiert.
Vielleicht auch für alle die irgendwann mal vor ähnlichen Problemen stehen.
Also:
Die /etc/crypttab und danach entsprechend die /etc/fstab geändert. Dann habe ich folgende Befehle ausgeführt:

Code: Alles auswählen

update-initramfs -k all -c
update-grub

Dazu muss gesagt werden, bei mir schlugen der erste Befehl fehl mit der Begründung die Datei bestehe schon.
Erst als ich sie in ein anderes Verzeichnis ausgelagert hatte lief alles durch.
Auslagern war wirklich besser (löschen wäre wohl fatal gewesen) weil ich sie später wieder zurück spielen musste.
Booten war nämlich nach den Änderungen wieder nicht möglich.
Auch nach dem zurück ändern der /etc/crypttab und der /etc/fstab blieb das so.
Ich muss mich also getäuscht haben und die Dateien werden doch irgendwie in das zu erstellende Image mit eingearbeitet.
Ich warte jetzt noch ein wenig und wenn keiner noch eine zündende Idee hätte, mache ich extra zu dem Thema noch einen neuen Thread auf.

[spiralnebelverdreher]

ich habe deine Idee jetzt mal ausprobiert.
Vielleicht auch für alle die irgendwann mal vor ähnlichen Problemen stehen.
Also:
Die /etc/crypttab und danach entsprechend die /etc/fstab geändert. Dann habe ich folgende Befehle ausgeführt:

Code: Alles auswählen

update-initramfs -k all -c
update-grub

Dazu muss gesagt werden, bei mir schlugen der erste Befehl fehl mit der Begründung die Datei bestehe schon.
Erst als ich sie in ein anderes Verzeichnis ausgelagert hatte lief alles durch.
Auslagern war wirklich besser (löschen wäre wohl fatal gewesen) weil ich sie später wieder zurück spielen musste.
Booten war nämlich nach den Änderungen wieder nicht möglich.
Auch nach dem zurück ändern der /etc/crypttab und der /etc/fstab blieb das so.
Ich muss mich also getäuscht haben und die Dateien werden doch irgendwie in das zu erstellende Image mit eingearbeitet.

Bei deinem Ansatz, ein Dualboot System (arch, debian) mit nur einem einzigen Grub Bootloaderzu fahren, musst du natürlich ziemlich aufpassen was du genau ins Grubmenü einträgst und was eventuell durch ein "update-grub" auf dem anderen System dann wieder überschrieben wird. Ein kleiner Schreibfehler kann zur Folge haben dass gar nichts mehr bootet. Ich mache so etwas aus Vorsichtsgründen so, dass ich zuerst einen neuen (kopierten) Grubeintrag erzeuge und da noch die alte Umgebung booten lasse. Erst im nächsten Schritt ändere ich nur diesen neuen Eintrag und zur Not kann ich alle vorherigen Einträge weiter nutzen.