# Verschlüsseltes Rootfilesystem: Passwd eingabe beim booten

## alexander_ro

Hallo ...  :Smile: 

Ich habe gerade versucht eine Gentoo Installation zu bauen bei der das Rootfilesystem und SWAP verschlüsselt sind. Das habe ich auch soweit zum laufen bekommen. Nur leider kann der das Rootfilesystem nicht finden. Startet man dann eine Shell und da den cryptsetup Befehl und exit bootet das System.

Initrdfs und Kernel habe ich so mit genkernel gebaut:

```

genkernel --no-clean --luks --disklabel --microcode --menuconfig all

```

Weiß jemand zufällig wie man das so macht das der cryptsetup Befehl automatisch ausgeführt wird und ich nur noch das Passwort eingeben muss?

Grüße

Alexander

----------

## Tyrus

Dazu musst du Bootparameter setzen.

Also wenn grub dein Bootmanager ist musste das in /etc/default/grub eintragen.

Da kann man über GRUB_CMDLINE_LINUX die Paramter einstellen

Bei mir sieht das z.B. so aus:

```

GRUB_CMDLINE_LINUX='crypt_root=UUID=d5a3428b-b21c-42b4-a4ce-0818c92bca9c real_root=/dev/mapper/GENTOO-ROOT root_keydev=UUID=E716-DA12 root_key=dmcrypt-2.key dobtrfs dolvm

```

Allerdings nutze ich auch lvm. Das kannste weglassen. Und das ist nicht mit Passworteingabe sondern mit einem Keyfile. Das File liegt bei mir auf einem USB-Stick. Bedeutet ohne den Stick kann der Bootvorgang nicht stattfinden.

Weiterhin würde ich immer UUIDs nutzen weil der USB-Stick zum Beipsiel wechselnde Benennungen hat wenn der gemountet wird (/dev/sdX - das X ist wechselnd). crypt_root ist die UUID der verschlüsselten Partition.  real_root ist das device das cryptsetup erzeugt wenn es die verschlüsselte Partition öffnet.

Wenn du Passworteingabe willst reicht vermutlich root_keydev und root_key wegzulassen. Ich hab das aber noch nicht ausprobiert.

Edit:

Ich hab eventuell vergessen zu erwähnen, das du natürlich das /boot/grub/grub.cfg neu erzeugen musst.

Ich mach das mit grub-mkconfig dann so:

```

grub-mkconfig -o /boot/grub/grub.cfg

```

Das Kommando beachtet dann /etc/default/grub für die Parameter.

----------

## alexander_ro

Ich habe das jetzt mal so versucht was leider nicht funktioniert hat.

```

GRUB_CMDLINE_LINUX="crypt_root=/dev/sda4 real_root=/dev/mapper/GentooRoot root_keydev=/dev/sda"

```

Wer verarbeitet diese Parameter denn?

Der Kernel selber ist es eher nicht ... bin mir nicht sicher.

----------

## Tyrus

Hallo Alexander.

Hast du mein Edit gesehen? Sorry hab ich nicht gleich dazu geschrieben.

Du musst die Parameter natürlich übernehmen mit grub-mkconfig in das grub.cfg

Wegen "/dev/sda4" - nimm besser die UUID.

Kannste nachsehen wie die lautet mit 'blkid'.

root_keydev  brauchst du nur, wenn du ein Keyfile zum entsperren nutzt. Bei der Passwortlösung macht das keinen Sinn.

Damit sagste dann auf welchem Device das Keyfile liegt.

Das Device für real_root kannst du nachsehen in der Benennung. Das ist etwas unglücklich als Beispiel oben, weil das ist ein Mappereintrag, der aber von LVM kommt. Das ist ein Logical Volume bei mir.

Du hast für root ein Filesystem ja angelegt. Den Eintrag findest du am besten indem du erst manuell mit cryptsetup entsperrst und dann blkid nutzt um die UUID von dem Filesystem zu holen.

Edit:

 *Quote:*   

> 
> 
> Wer verarbeitet diese Parameter denn? 
> 
> 

 

Das passiert über die initramfs - weil da wird ja zuerst mal entsperrt - vorher kann der Kernel nicht an die Root-Partition ran.

----------

## Tyrus

Da ich grade den neuen Kernel 5.6.16 gebaut habe musste ich auch die initramfs dazu erneuern. Die Ausgabe sieht so aus:

```

luthien /usr/src/linux # genkernel --luks --lvm initramfs

* Gentoo Linux Genkernel; Version 4.0.7

* Using genkernel configuration from '/etc/genkernel.conf' ...

* Running with options: --luks --lvm initramfs

* Working with Linux kernel 5.6.16-gentoo-luthien for x86_64

* Using kernel config file '/usr/share/genkernel/arch/x86_64/generated-config' ...

* Current kernel's LOCALVERSION is set to '-luthien'; Will ignore set --kernel-localversion value '-x86_64' because kernel was not build ...

* initramfs: >> Initializing ...

*         >> Appending devices cpio data ...

*         >> Appending base_layout cpio data ...

*         >> Appending auxilary cpio data ...

*         >> Appending busybox cpio data ...

*         >> Appending blkid cpio data ...

*         >> Appending btrfs cpio data ...

*         >> Appending luks cpio data ...

*         >> Appending lvm cpio data ...

*         >> Appending modprobed cpio data ...

*         >> Appending modules cpio data ...

*         >> Appending linker cpio data ...

*         >> Deduping cpio ...

*         >> Pre-generating initramfs' /etc/ld.so.cache ...

*         >> Compressing cpio data (.xz) ...

* 

* You will find the initramfs in '/boot/initramfs-5.6.16-gentoo-luthien.img'.

* WARNING... WARNING... WARNING...

* Additional kernel parameters that *may* be required to boot properly:

* - Add "dobtrfs" for Btrfs device scanning support

* - Add "dolvm" for LVM support

* - Add "crypt_root=<device>" for LUKS-encrypted root

* - Add "crypt_swap=<device>" for LUKS-encrypted swap

* Do NOT report kernel bugs as genkernel bugs unless your bug

* is about the default genkernel configuration...

* 

* Make sure you have the latest ~arch genkernel before reporting bugs.

```

Da du kein lvm nutzt geh ich davon aus das du das root aber auch swap seperat verschlüsselt hast.

Deswegen solltest du auch wie vorgeschlagen von genkernel auch crypt_swap einstellen weil das muss ja auch entsperrt werden. 

Ob es auch real_swap gibt weiss ich grade nicht. Ich verwende auch einen Swap. Aber der liegt auf dem gleichen verschlüsselten Bereich wie root. Bei mir ist das so aufgebaut, das ich erst eine verschlüsselte Partition habe und da drin liegen dann logische Volumes für root aber eben auch für swap (also mit lvm). Deswegen brauch ich das nicht.

----------

## alexander_ro

Gut zu wissen das es im initrd verarbeitet wird dann weiß ich wo man nach Infos suchen kann. Ich habe zwar einige Sachen gefunden aber nie hat einer geschrieben wo es her kommt. Leider ist das oft wie eine Todo Liste aufgebaut. Keiner Erklärt die Hintergründe warum man tun soll was beschrieben ist. Schon mal danke das Du das immer mit erklärt hast.

Ich habe es so hin bekommen das der nach dem Passwort fragt. Ich habe das in meiner fstab so angegeben das /dev/mapper/GentooRoot das Rootfilesystem ist. Das ist es auch nach dem er sucht. Soweit würde das gehen. Nur das der bei der automatischen Passwort abfrage dann das Entschlüsselte Laufwerk unter /dev/mapper/root mappen tut. Klar ich könnte das jetzt in der fstab ändern dann geht es vermutlich. Nur hätte ich das gerne als GentooRoot so lautet auch das Label der Partition. Ich würde auch gerne statt der UUID das LABEL verwenden. Die UUID ist halt überhaupt nicht selbst Erklärend.

Das mit crypt_root=LABEL=GentooRoot habe ich aber noch nicht zum funktionieren bekommen.

Ich habe jetzt zwar eine eigene SWAP Partition gemacht mit eigenem Passwort aber man könnte ja auch eine SWAP-Datei auf das Rootfilesystem legen. Damit geht aber dann glaube ich kein Shutdown to Disk ob der mit Verschlüsselung überhaupt geht weiß ich nicht. Da es aber nicht funktionierte wie gewünscht habe ich erst mal das mit der SWAP weg gelassen. Der Rechner hat 8GB-RAM wird also normal außer für Shutdown to Disk keine SWAP benötigen. Ich probiere halt gerade mal herum was geht und was nicht.

----------

## Tyrus

/dev/mapper/root gitbs bei mir auch. Das scheint einfach der Name zu sein den cryptsetup für die "entschlüsselte" Partition vergibt. 

```

/dev/mapper/root: UUID="WeNcwR-5pL7-QCAF-AgGA-GExf-bSxM-WIkdha" TYPE="LVM2_member"

```

Wie man sieht ist das hier die Partition die dann von LVM verwaltet wird. Deswegen liegt da auch nicht schon das root-Device bei mir.

In deinem Fall passt es natürlich und root ist das korrekte Element. Es könnte sogar sein, das du das "real_root" weglassen kannst. Weil es für die initramfs klar sein sollte wie das Device heisst. 

In meinem Fall muss ich aber eben dann ein anderes Device angeben das nach Start von lvm verfügbar wird. 

Wenn du "root" (den Namen) ändern willst, dann müssest du in die initramfs schauen und den Aufruf von cryptsetup verändern. Also da würde ich zumindest schauen.

Wegen der UUIDs - du kannst ja in fstab auch Kommentare dazu schreiben. Also LABEL hab ich noch nicht versucht. Ich sehe am mountpoint eigentlich welches Device vorne gemeint ist. Deswegen hatte mich das nie gestört.

Dazu findest du in der manpage zu cryptsetup:

```

[...]

LUKS EXTENSION

[...]

       The  <device>  parameter can also be specified by a LUKS UUID in the format UUID=<uuid>. Translation to real device name uses symlinks in

       /dev/disk/by-uuid directory.

[...]

```

Interessant ist das es auch /dev/disk/by-label gibt. Aber scheinbar scheint cryptsetup das nicht implementiert zu haben. Also so interpretiere ich die manpage dazu jetzt.

----------

## alexander_ro

Das Label wird mit verschlüsselt. Wenn man es lesen will mit e2label /dev/sdb4 wird man darauf hingewiesen das es einen Luks Header gibt.

(Ich boote das mit Qemu von USB deshalb hat das Laufwerk mal sda oder sdb je nach Zugriff Host oder Gast.)

```

e2label /dev/sdb4

e2label: Ungültige magische Zahl im Superblock beim Versuch, /dev/sdb4 zu öffnen

/dev/sdb4 hat ein crypto_LUKS-Dateisystem

```

----------

## Tyrus

Das verschlüsselte Device - bei dir jetzt im Beispiel /dev/sdb4 hat kein LABEL aber es gibt ein PARTLABEL. 

Bei mir sieht das so aus:

```

/dev/sda3: UUID="d5a3428b-b21c-42b4-a4ce-0818c92bca9c" TYPE="crypto_LUKS" PARTLABEL="Crypted Gentoo /" PARTUUID="cd1e1d55-027e-47be-b0f7-d139d615615a"

```

Keine Ahnung ob man das PARTLABEL irgendwo nutzen kann. Ich hab es "beschreibend" eingesetzt. Es wird angezeigt zum Beispiel wenn man die Partitionstabelle mit parted ausgibt:

```

luthien ~ # parted -a optimal /dev/sda print

Modell: ATA Crucial_CT275MX3 (scsi)

Festplatte  /dev/sda:  275GB

Sektorgröße (logisch/physisch): 512B/512B

Partitionstabelle: gpt

Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem  Name              Flags

 1      1049kB  3146kB  2097kB               grub              bios_grub

 2      3146kB  2003MB  2000MB  fat32        efi-boot          boot, esp

 3      2003MB  275GB   273GB                Crypted Gentoo /  msftdata

```

(Das Flag msftdata wurde von Windows 7 (das liegt bei mir auf /dev/sdb) damals bei der Installation da gesetzt. Windows trägt sich in die Efi-Partition ein ... warum das Flag da gesetzt wurde weiss ich nicht.)

----------

## alexander_ro

Das ist bei mir einfach leer:

```

parted -a optimal /dev/sdb print

Modell: Hitachi HTS542516K9SA00 (scsi)

Festplatte  /dev/sdb:  160GB

Sektorgröße (logisch/physisch): 512B/512B

Partitionstabelle: gpt

Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem  Name  Flags

 1      1049kB  6291kB  5243kB                     bios_grub

 2      6291kB  111MB   105MB   ext2

 3      111MB   21,6GB  21,5GB

 4      21,6GB  160GB   138GB

```

Ich hatte das mit fdisk gemacht der glaube ich kann das nicht setzen. Muss ich mal suchen und probieren ob das dann geht.

<Edit>

Das finde ich interessant eine schöne Sammlung. Danach kann man bei LUKS2 auch eine Label setzen.

https://wiki.archlinux.org/index.php/Persistent_block_device_naming#by-label

</Edit>

----------

## Tyrus

Das kannste im Gentoo-Handbuch zur Installation nachlesen: https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Disks/de#Standard:_Partitionieren_mit_parted

Also so sollte es gehen:

```

parted -a optimal /dev/sdb

name 4 <Dein Name>

print

quit

```

Edit:

Ah das ist für das neue Format LUKS2. Aber Achtung - wenn man umstellt - die sind nicht kompatibel. Dafür hat emerge für das Paket cryptsetup ein Useflag und hatte mir ne fette Warnung rausgehauen sodas ich das erstmal nicht gemacht hab. Lies mal hier:

https://forums.gentoo.org/viewtopic-t-1108052.html

Getestet hab ichs noch nicht auf dem alten Laptop - werd ich aber noch machen.

Edit-2:

Die Sammlung ist wirklich top. Danke - da hab ich mir mal ein Lesezeichen drauf gesetzt. *grins*

----------

## alexander_ro

Ist mir nicht gleich wieder eingefallen aber fdisk hat ja mit x den Experten Modus da kann man dann auch das Label setzen. Ich weiß nicht genau was daran so expertig ist aber gut es geht. Das Beispiel von Dir geht auch. Ob sich das so jetzt mit Label booten lässt muss ich erst noch ausprobieren ...

Das mit LUKS1 oder LUKS2 ist seltsam. Ich habe das erst erstellt mit cryptsetup es wurde aber immer noch LUKS1 automatisch erstellt. Trotz der neuen Version von cryptsetup

```

qlist -Iv | grep cryptsetup

sys-fs/cryptsetup-2.3.2

```

<Edit>

Das lässt sich leider nicht booten. Es gibt bei mir in der Shell innerhalb der initrd aber auch nur das Verzeichnis /dev/disk/by-id die anderen für UUID oder LABEL sind gar nicht vorhanden.

</Edit>

----------

## Tyrus

Wegen der PARTLABEL.

Lies mal hier: https://wiki.gentoo.org/wiki/Custom_Initramfs#Mount_by_UUID_or_label

Wenn ich das richtig verstehe kann das in der initramfs zuerst mit findfs aufgelöst werden, sodas cryptsetup die Auflösung nicht selber machen muss. 

Also bei mir zeigt:

```

luthien /etc/portage/package.use # findfs PARTLABEL='Crypted Gentoo /'

/dev/sda3

```

Versuch mal in der initramfs das Kommando:

```

cryptsetup luksOpen $(findfs PARTLABEL=<Dein Partlabel>) <dein Name für das entsperrte Device>

```

Zumindest sieht das den Versuch wert aus.

----------

## alexander_ro

Den Wiki Artikel kenne ich schon hatte den aber schon wieder vergessen. Den findfs gibt es in der initrd von genkernel nicht.

Ich habe jetzt mal gesucht wie man das wieder in einzelne Dateien zerlegt.

Ist ja ganz einfach ein cpio Archiv ja echt ... geht nur nicht so wie die meisten es beschreiben.

```

file initramfs-4.19.97-gentoo-x86_64.img

initramfs-4.19.97-gentoo-x86_64.img: XZ compressed data

```

Ah ein xz ist das ... dem muss  man aber das xz anhängen sonst verweigert unxz die Arbeit.

```

mv initramfs-4.19.97-gentoo-x86_64.img initramfs-4.19.97-gentoo-x86_64.img.xz

unxz initramfs-4.19.97-gentoo-x86_64.img.xz

```

Nun noch das cpio auspacken

```

cpio --extract --make-directories --format=newc --no-absolute-filenames < initramfs-4.19.97-gentoo-x86_64.img 

45558 Blöcke

```

Ein Kinderspiel wenn man weiß wie es geht ...

Man findet da drinnen lauter Hübsche Sachen ... Diamanten, Ölquellen und natürlich das init Script das genkernel verwendet und da drinnen (im init) alte bekannte wie root_real usw.. Das werde ich mir Morgen mal näher anschauen. Dann sieht man besser was geht und was nicht.

----------

## Tyrus

Danke jetzt hast du mich neugierig gemacht selber reinzuschaun. *schmunzelgrins*

So geht es aber:

```

blkid -o device -l -t PARTLABEL="Crypted Gentoo /"

```

Das ergibt bei mir auch:

```

/dev/sda3

```

Und:

```

mithrandir@luthien ~/test $ ls -l sbin

insgesamt 5716

-rwxr-xr-x 1 mithrandir users 1085240  5. Jun 23:39 blkid

-rwxr-xr-x 1 mithrandir users 1942880  5. Jun 23:39 btrfs

lrwxrwxrwx 1 mithrandir users       5  5. Jun 23:39 btrfsck -> btrfs

-rwxr-xr-x 1 mithrandir users 2801192  5. Jun 23:39 cryptsetup

lrwxrwxrwx 1 mithrandir users      19  5. Jun 23:39 dmsetup -> ../usr/sbin/dmsetup

lrwxrwxrwx 1 mithrandir users      19  5. Jun 23:39 dmstats -> ../usr/sbin/dmstats

lrwxrwxrwx 1 mithrandir users       7  5. Jun 23:39 init -> ../init

lrwxrwxrwx 1 mithrandir users      15  5. Jun 23:39 lvm -> ../usr/sbin/lvm

```

Also das gibt es in meiner initramfs. Im init-Script ist auch findfs erwähnt. Also wahrscheinlich kann man das mit irgendeiner Option dem Genkernel sagen - dann hat er das auch. Aber reicht ja mit blkid.

Edit:

Der Aufruf von cryptsetup steht in initrd.scripts im Verzeichnis etc. Da findest ab Zeile 1745 die Funktion "openLUKS" und in Zeile 1900 den eigentlichen Aufruf von cryptsetup mit luksOpen:

```

crypt_filter "${gpg_cmd}cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}"

```

Ab Zeile 2256 findest du dann die Funktion "start_LUKS". Die benutzt das openLUKS:

```

start_LUKS() {

   # if key is set but neither ssh enabled or key device is given, find

   # the key device

   [ -n "${CRYPT_ROOT_KEY}" ] && [ -z "${CRYPT_ROOT_KEYDEV}" ] \

      && sleep 6 && bootstrapKey "ROOT"

   if [ -n "${CRYPT_ROOT}" ]

   then

      openLUKS "root"

      if [ -n "${REAL_ROOT}" ]

      then

         # Rescan volumes

         start_volumes

      else

         REAL_ROOT="/dev/mapper/root"

      fi

   fi

   # same for swap, but no need to sleep if root was unencrypted

   [ -n "${CRYPT_SWAP_KEY}" ] && [ -z "${CRYPT_SWAP_KEYDEV}" ] \

      && { [ -z "${CRYPT_ROOT}" ] && sleep 6; bootstrapKey "SWAP"; }

   if [ -n "${CRYPT_SWAP}" ]

   then

      openLUKS "swap"

      if [ -z "${REAL_RESUME}" ]

      then

         # Resume from swap as default

         REAL_RESUME="/dev/mapper/swap"

      fi

   fi

}

```

Im init-Skript ab Zeile 608 findest du dann den Aufruf von start_LUKS:

```

# Initialize LUKS root device except for livecd's

if [ "${CDROOT}" != '1' ]

then

   start_LUKS

   if [ "${NORESUME}" != '1' ] && [ -n "${REAL_RESUME}" ]

   then

      case "${REAL_RESUME}" in

         LABEL=*|UUID=*|PARTLABEL=*|PARTUUID=*)

            RESUME_DEV=""

            retval=1

            if [ ${retval} -ne 0 ]

            then

               RESUME_DEV=$(findfs "${REAL_RESUME}" 2>/dev/null)

               retval=$?

            fi

            if [ ${retval} -ne 0 ]

            then

               RESUME_DEV=$(blkid -o device -l -t "${REAL_RESUME}" 2>/dev/null)

               retval=$?

            fi

            if [ ${retval} -eq 0 ] && [ -n "${RESUME_DEV}" ]

            then

               good_msg "Detected real_resume=${RESUME_DEV}"

               REAL_RESUME="${RESUME_DEV}"

            fi

            ;;

      esac

      do_resume

   fi

fi

```

Jetzt musste nur noch (*hust*) rausfinden wie du da am am leichtesten eingreifen kann. Mir ist das jetzt auch zu spät - aber ich schau mir das morgen auch noch mal tiefer an ...

Aber dann haste schon mal nen paar Hinweise wo du weiterschauen kannst.  :Smile: 

*müde sein jetzt* *grins*

Tyrus

----------

## alexander_ro

Wo ich geschrieben habe das es findfs nicht gibt wusste ich noch nicht wie man das initramfs auspackt. Ich hatte es einfach in der initramfs Shell ausprobiert. Stimmt blkid gibt es da.

Danke für Deine Vorsuche das start_LUKS hatte ich zwar auch schon entdeckt aber den Rest nicht. Das hat schon mal geholfen. Da kam mir dann die Idee mal zu schauen was die mit dem crypt_root so machen. Ich hatte da einfach LABEL angegeben also so: crypt_root=LABEL=GentooRoot was aber halt für das Label in der GPT falsch ist da muss man PARTLABEL statt LABEL angeben. Sieht dann so aus: crypt_root=PARTLABEL=GentooRoot.

So findet er dann das Laufwerk und frägt automatisch nach dem Passwort zum entsperren. Der mappt das entsperrte Laufwerk aber immer noch auf /dev/mapper/root. Das wollte ich eigentlich auf /dev/mapper/GentooRoot haben. Also das er es mappt auf den PARTLABEL Namen. Da muss ich jetzt mal suchen. Vielleicht gibt es ja da auch wieder eine Option die ich nicht kenne ...  :Sad: 

<Edit>

So wie es aussieht ist das leider fest vorgegeben.

Die rufen die Funktion: openLuks "root" auf.

</Edit>

----------

## Tyrus

Zur Namensvergabe des entsperrten Device:

Den Verdacht das das hart verdrahtet ist hatte ich ja von Anfang an. Weil bei mir ist das Device ja auch unter dem Namen vorhanden.

Was man machen könnte ist ein kleines Script schreiben. Zwei Funktionen reinstecken. Eine entpackt die initramfs, die andere setzt alles wieder zusammen. Und dann kannste das patchen. Also nach >> openLUKS "root" << suchen und root ersetzen.

Also einfach mal so als Idee.

Edit:

Als Erweiterung - welcher Name soll ersetzt werden - das kannste auch noch etwas optimieren. Dazu kannste noch ne Funktion machen die aus der /etc/fstab das rausholt. Also Zeile suchen die als Mountpoint nur "/" enthält. Dann den Device-Eintrag da rausfiltern. Zur Sicherheit kannste das Ergebnis nochmal mit blkid Aufruf von oben gegenchecken ob dann ein auch wirklich das aufgelöst wird in etwas der Art "/dev/sdX". Damit haste dann auch verifiziert das das PARTLABEL noch zur /etc/fstab passt.

----------

## alexander_ro

Ich musste da jetzt erst mal Überlegen wie ich da weiter mache ...

Ja das wäre eine Möglichkeit.

Aber die fstab benutzt der glaube ich gar nicht. Weil er ja alle Parameter vom Kernel geliefert bekommt. Weil gerade Kernel ... warum man die Parameter durch den Kernel schleust ist mir ein echtes Rätsel der macht damit ja nichts das ist nur Mega verwirrend. Und ob man nun einen Grub oder ein InitRamFs neu installiert ist Jacke wie Hose. Wenn das ja eh alles von genkernel zusammen generiert wird könnte man das ja in einer Konfigurationsdatei im initramfs unterbringen. Die Kernel Macher sollten mal einen präfix einführen mit dem Markiet wird wo die Optionen verarbeitet werden damit könnte man vermutlich für etwas Klarheit sorgen. Klare Schnittstellen ohne überflüssige Datenübergabe wäre aber besser ... aber gut nur weil ich der Meinung bin wird das keiner Ändern also gehen wir mal davon aus die wissen was sie tun.

Mit crypt_root bekommt der das Physikalische Gerät mitgeteilt auf dem die Verschlüsselten Daten sind.

Wenn der dann einen fixen Namen "/dev/mapper/root" vergibt wozu braucht der dann real_root?

Das entsperrte Laufwerk kommt doch so immer in /dev/mapper also könnte man in real_root den Namen übergeben auf den das Laufwerk gemappt werden soll. In meinem Fall also real_root=GentooRoot. Im init Script baut man das dann zu /dev/mapper/GentooRoot zusammen.

<Edit>

Habe ich gerade noch entdeckt:

```

       real_root=<...>

           Legacy kernel parameter from kernel-2.4 initrd. Does the same as root=, which should be used in its place.

```

wohl nicht mehr so aktuell der Parameter.

</Edit>

----------

## alexander_ro

Ich werd das so mal versuchen. Ich weiss nicht so genau wie man Strings in einem Shell-Script zerlegt aber es scheint in dem Beispiel so zu gehen. Den Teil zwischen den fünf Kommentarzeichen oben und unten muss man in das init etc/init.scripts ins der Funktion openLUKS einbauen. Den $1 darf man aber nicht verändern das ist der erste Funktionsparameter. Ist in meinem Beispiel anders weil es keine Funktion ist. Für Swap müsste man das ein zweites mal einfügen. Wenn man aber weder UUID noch LABEL oder PARTLABEL angibt funktioniert das so nicht mehr.

```

#!/bin/sh

Parameter1='root'

CRYPT_ROOT='crypt_root=PARTLABEL=GentooRoot'

#####

# Diesen Teil in die Funktion openLUKS beim case $1 einfügen.

# case $1 darf nicht verändert werden ist hier nur zum Testen umbenannt.

Trennzeichen=`expr index "$CRYPT_ROOT" '='`

ErsterTeil=${CRYPT_ROOT:$Trennzeichen}

Trennzeichen=`expr index "$ErsterTeil" '='`

ZweiterTeil=${ErsterTeil:$Trennzeichen}

        case $Parameter1 in

                root)

                        TYPE=ROOT

                        LUKS_NAME='/dev/mapper/'$ZweiterTeil

                        ;;

                swap)

                        TYPE=SWAP

                        ;;

        esac

#

#####

echo $Trennzeichen

echo $CRYPT_ROOT

echo $ErsterTeil

echo $ZweiterTeil

echo $LUKS_NAME

```

----------

## Tyrus

Also es geht doch darum 'LUKS_NAME' auf 'GentooRoot' zu setzen.

Zumindest sagt mir das der Aufruf von cryptsetup in Zeile 1900.

```

crypt_filter "${gpg_cmd}cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}"

```

Die Zuweisung für LUKS_NAME ist in Zeile 1764:

```

eval local LUKS_DEVICE='"${CRYPT_'${TYPE}'}"' LUKS_NAME="$1" LUKS_KEY='"${CRYPT_'${TYPE}'_KEY}"'

```

Also muss nur $1 mit GentooRoot an der Stelle ankommen. 

/dev/mapper muss sich nicht davor stehen. Das wird von cryptsetup selber gemacht.

Die von dir gezeigte case-Unterscheidung würde ich einfach so ändern auf 'GentooRoot' (also erster Versuch):

```

   case $1 in

      root)                                                      <-- hier dann GentooRoot)

         local TYPE=ROOT

         ;;

      swap)

         local TYPE=SWAP

         ;;

   esac

```

OpenLUKS bekommt das $1 von dem Aufruf aus der Funktion start_LUKS ab Zeile 2265.

Da muss der Aufruf angepasst werden. Weil da wird hart verdrahtet "root" reingeschickt. Der Einfachheit halber das dann auf "GentooRoot" ändern für den ersten Versuch. 

Weiterhin gibt es dann die harte Verdrahtung da drunter noch:

```

   if [ -n "${CRYPT_ROOT}" ]

   then

      openLUKS "root"                                               <-- hier

      if [ -n "${REAL_ROOT}" ]

      then

         # Rescan volumes

         start_volumes

      else

         REAL_ROOT="/dev/mapper/root"                               <-- hier

      fi

   fi

```

Da sollte das "root" hinten ebenfalls gepatched werden auf deinen Wert. Also für den ersten Versuch "GentooRoot"

Für Swap da drunter ähnlich.

Das kann man wenn der Versuch klappt verbessern indem dem Patchscript den zu verdrahtenden Wert variabel ermitteln lässt. Also ich würde das Patchscript dann erst /etc/fstab auslesen lassen und die Zeile mit dem Mountpoint "/" enthält das PATRTLABEL. Das kann man dann vorher noch gegenchecken - also ob die Auflösung des PARTLABEL nach Devicename der Art /dev/sdX klappt. Das geht ja einfach mit blkid. Und wenn der Check erfolgreich ist kann das Patchscript dann die oben erwähnten Stellen patchen.

Edit:

Das Patchscript zu erzeugen da würde ich keine Stringuntersuchung machen. Erster Versuch nehmen. Dann mit Diff einen Patch erzeugen der die Änderungen hat. Den kannste jetzt verändern wenn das variabel werden soll über das Script. Eine Zeile rauswerfen und ne neue rein. Also du nimmst die ersten x Zeilen, hauste ne eigene Zeile rein die variablel angepasst wird und dann wieder den Rest anfügen (head, tail,  echo und cat sollten da helfen). Zum Schluss rufste dann das patch-Kommando auf. So in der Art würde ich das versuchen.

----------

## alexander_ro

Bei mir gibt es zwar eine fstab die enthält aber nicht das GentooRoot.

Sieht so aus:

```

/dev/ram0     /           ext2    defaults      0 0

proc          /proc       proc    defaults    0 0

```

Nachdem was ich gefunden habe kann blkid das PARTLABEL nicht alleine ausgeben. Deshalb habe ich es aus dem CRYPT_ROOT genommen. Aber das setzen des LUKS_NAMEN ist natürlich falsch.

Müsste so aussehen:

```

LUKS_NAME='$ZweiterTeil

```

Wie ich ohne String Operationen an den Namen kommen soll weiß ich jetzt nicht.

Ich hätte das Script einfach manuell geändert und dann das ganze wieder in das initramfs verpackt. Man muss bei einem Update ja dann so immer darauf achten das einem die Änderung nicht verloren geht. Meine Idee war das ich an so wenig stellen wie möglich Änderungen mache. Deshalb habe ich den Aufruf des Scripts unverändert gelassen.

----------

## Tyrus

Schnelle Frage - was zeigt denn bei dir:

```

findmnt -n /

```

Ich bekomme als Ausgabe:

```

/      /dev/mapper/GENTOO-ROOT btrfs  rw,relatime,ssd,space_cache,subvolid=5,subvol=/

```

----------

## alexander_ro

Ja das gibt der bei mir auch in dem Format aus nur halt ext4 und mit GentooRoot weil ich das anders geschrieben habe. Macht er aber nur wenn ich es manuell zusammen baue. Wenn ich es so konfiguriere das er nach dem Passwort eingeben automatisch bootet gibt er /dev/mapper/root aus.

Den Befehl gibt es aber in meinem initramfs nicht ob man den da rein bekommt weiß ich nicht.

----------

## Tyrus

Naja ich würde es ja nach wie vor von aussen patchen.

Also erst genkernel aufrufen das die initramfs baut. Dann ein Script haben, das Auspacken und Einpacken kann und dazwischen einfach die eine Datei patcht. Also dann brauchst auch das 'findmnt' nicht in der Initramfs. Du musst doch nach dem Bau der Initramfs nur sicherstellen das sich die Verhältnisse nicht geändert haben. Mit dem 'findmnt' kannste das Partlabel extraieren (also aus der aktuellen Situation) und das Ergebnis kannst dann mit dem blkid gegenchecken bei der Partition. Wenn du dann als Ergebnis einen Devicenamen wie /dev/sdX bekommst stimmt alles. Dann kannste das Partlabel in das Script in der initramfs reinpatchen. 

Innerhalb der initramfs das Script ummodeln bedeutet ja auch das du das immer erneuern musst. Du musst das jedes mal wenn du genkernel aufgerufen hast wieder machen. Also klar kannste das machen, aber ausserhalb hast du einfach viel mehr Kommandos zur Verfügung um da was zu ändern. 

Nur ein paar Gedanken. Ich will dir da nicht reinreden. Ist eine lokale Lösung und eigentlich egal - wichtig ist es funktioniert für dich.  :Smile: 

----------

## alexander_ro

Ich sehe da nun nicht wirklich einen großen Unterschied. Ein/Aus-Packen muss ich es in beiden Fällen. Einen Patch machen und mit dem gleichnamigen Kommando einbauen oder was ähnliches muss ich auch in beiden Fällen. Vergessen darf ich das auch in beiden Fällen nicht und wenn man es mit genkernel neu macht muss ich das wieder korrigieren auch in beiden Fällen. 

Nur das es sich nicht mehr booten lässt wenn man das initramfs aus und wieder einpackt. Warum weiß ich nicht. Muss mal suchen was da falsch ist.

Muss man das eigentlich unbedingt einpacken?

Die wichtigen Filesystem habe ich so nicht als Kernel-Module also müsste der Kernel doch ein ext2 Filesystem auch direkt lesen könne. Also den Inhalt des initramfs cpio auch ohne cpio Weg booten können.

<Edit>

Man hat doch dann einige der Programme aus dem root Filesystem in dem initramfs. Wenn es für die Updates gibt müsste man doch eigentlich das initramfs neu bauen. Zumindest wenn es irgendwelche Sicherheitsrelevanten Udates sind. Ob das jemals einer gemacht hat? Also ich nicht weil ich bisher gar nicht wusste was alles in dem initramfs eingepackt ist. Ich hatte angenommen das wurde geschaffen damit der Kernel Zugang zu den Kernel-Modulen hat die er braucht um ein Rootfs einzubinden. Ist aber ja schon fast ein eigenes Rootfs das da eingepackt wird. Sogar Tastatur Maps sind da nur kann man die auch nicht vorgeben. Der Parameter --keymap de wählt leider nicht das Deutsche Layout aus.

</Edit>

----------

## Tyrus

Zu der Frage aus dem Edit. Genkernel baut statische Versionen von cryptsetup, lvm, btrfs, usw. (wenn ich das richtig verstehe) mit jeder neuen Version. Solange die Version sich nicht anhebt bleiben die. Weiss grade nicht wo, aber das wird irgendwo angelegt einmal. 

Man bemerkt es, weil das Versionsupdate von genkernel dazu führt, das der darauf folgende Bau der Initramfs dann deutlich mehr Zeit in Anspruch nimmt. Danach geht es sehr schnell bei mir, bis zum nächsten Versionsupdate.

Wenn du willst das es immer gemacht wird musst du schauen wo die statischen Versionen quasi gecached werden und das weg löschen. Das sollte reichen vermutlich.

Zur Frage ob das gepackt vorliegen muss. Gegenfrage - wie sagst du grub das? Das Wurzelverzeichnis da anzugeben würde reichen. Kannste ja mal testen was dann passiert. Soll heissen - ich hab keine Ahnung ob das geht ... *grins* 

Und ja ext2 sollte der Kernel können.

----------

## alexander_ro

Ach grub macht das. Ich hatte irgendwo gelesen oder so verstanden das der Kernel das liest entpackt und dann das init Script startet. Ich guck mal was die über den grub sagen vielleicht finde ich was.

Was mir aber mehr sorgen macht wenn ich ein fertiges initramfs von genkernel auspacke und ohne Änderung wieder einpacke kann ich nicht mehr booten.

So habe ich das gemacht (im Verzeichniss wo ich das ausgepackt habe):

```

find . | cpio --verbose --create --format=newc > ../initramfs-5.4.28-gentoo-x86_64.img

```

Dann mit xz wieder komprimierte.

Fehlermeldung: unable to mount root fs on unknown-block (0,0)

Weisst Du vielleicht was ich da beim einpacken falsch mache?

<Edit>

Grub habe ich mit grub-mkconfig aktuallisiert.

</Edit>

----------

## Tyrus

Also kann sein das ich da irgendwo was verschlampt habe. Ist schon spät. Bei mir macht das genkernel wie folgt. Also habe da in das Skript geschaut.

Damit legste das das img an:

```

find . -print0 | sort -z | cpio --quiet --null -o -H newc --owner root:root --force-local --reproducible -F initramfs-5.6.17-gentoo-luthien.img

```

Jetzt noch mit xz packen:

```

xz -e --check=none -z -f -9 initramfs-5.6.17-gentoo-luthien.img

```

Dann Umbennen um das .xz loszuwerden

```

mv initramfs-5.6.17-gentoo-luthien.img.xz initramfs-5.6.17-gentoo-luthien.img

```

----------

## alexander_ro

Ich hatte das von der Kernel Doku und mich schon gewundert das die Kernel Doku falsch ist. Das kommt eher nicht vor.

https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Ist sie auch dieses mal nicht den Unterschied macht die Komprimierung und nicht das einpacken in das cpio Archiv. In der Kernel Doku verwenden die eine andere Komprimierung.

Das cpio Archiv im gleichen Verzeichnis anzulegen wie die Daten sind ergibt bei mir eine Fehlermeldung. Das kann man aber leicht vermeiden wenn man bei der -F Option eine Verzeichnis mit angibt.

Vermutlich ist das so weil er dann versucht das cpio Archiv mit einzupacken das sich aber laufend verändert.

Danke für die Info das hat sehr geholfen. Irgendwie bin ich nicht auf die Idee gekommen bei der Komprimierung zu suchen.

Jetzt kann ich wieder weiter machen und die Änderungen testen ...

<Edit>

Falls es jemanden interessiert: bei der Komprimierung ist die entscheidende Option --check=none die schaltet die Integritätsprüfung bei der Komprimierung aus.

Ich dachte immer Integritätsprüfungen sind eine gute Sache. Die man Page sieht es ähnlich.

</Edit>

----------

## alexander_ro

Irgendwie geht das nicht wie es soll. Aber die Shell-Magie ist mir auch nicht so richtig bekannt. Sobald man den LUKS_NAME ändert erhält man die Fehlermeldung:

```

Faild to open Luks device /dev/sda4

could not find the in /devsda4

```

Eingebaut habe ich das in openLUKS so:

```

                                fi

                                # At this point, keyfile or not, we're ready!

                                #####

                                # Ändere den Mapping Namen auf das PartLabel

                                  Trennzeichen= expr index "$CRYPT_ROOT" '='`

                                  ErsterTeil=${CRYPT_ROOT:$Trennzeichen}

                                  Trennzeichen= expr index "$ErsterTeil" '='`

                                  ZweiterTeil=${ErsterTeil:$Trennzeichen}

                                  LUKS_NAME=$ZweiterTeil

                                  good_msg "$LUKS_NAME"

                                #

                                #####

                                crypt_filter "${gpg_cmd}cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}"

                                crypt_filter_ret=$?

```

Nach dem Passwort für die Verschlüsselung wird nicht mehr gefragt.

----------

## Tyrus

Also rein aus der Ausgabe schaut es so aus als ob LUKS_NAME nichts enthält.

Aus dem was ich grade an den Kommandos testen wollte ist da auch ein Fehler drin.

Du musst 

```

Trennzeichen=`expr index "$CRYPT_ROOT" '='` 

```

setzen.

Das erste ` Zeichen ist bei dir stattdessen ein Blank.

Dito bei der zweiten Zuweisung an Trennzeichen.

----------

## alexander_ro

Ah ja, da fehlt was ... habe ich doch gut gemacht beim Beispiel Script richtig und dann falsch ...  :Sad: 

Das ist auf meinem Bildschirm weniger als ein Staubkorn kaum zu sehen. Sorry habe ich übersehen.

Ich konnte das nicht kopieren weil ich aus irgendeinem Grund kopieren und einfügen in das Qemu Fenster niccht funktioniert. Ich habe was gelesen das man auf dem Gast Betriebssystem irgendwas installieren muss damit das geht.

Nach einfügen des fehlenden Zeichens bootet es wie es sein soll.

<Edit>

Sehe ich das richtig das man ein Verschlüsseltest SWAP nicht automatisch einfach mit dem gleichen Passwort entschlüsseln kann. Ich weiß jetzt nicht warum man verschiedene benutzen sollte. Ein Angreifer wird versuchen das RootFs Passwort zu raten. Ich würde das zumindest so machen. Wenn man dann Zugriff auch das RootFs hat macht es da noch einen Unterschied ob man das SWAP Passwort hat oder nicht. Klar könnten Temporäre Daten nur im SWAP zu finden sein aber bei den meisten Modernen Rechnern ist so viel Hauptspeicher vorhanden das der Kernel SWAP so kaum benutzt.

Man kann das gleiche Keyfile für root und swap benutzen habe ich gefunden aber ist das wirklich besser. Wie werden denn dann die Keyfiles gesichert. Ohne Passwort könnte dann doch jeder der die Platte in die Finger bekommt die Daten entschlüsseln. Gut Keyfile auf dem USB-Stick geht auch aber wo nimmt man den mit der darf niemals mit dem Notebook in einer Tasche landen. Wenn mit der Kette um den Hals aber macht das wer so und wie verteidigt man den im Zweifelsfall.

Ein Passwort ist finde ich leichter zu verteidigen. Man sagt es einfach nicht wenn man es nicht auf Zetteln lagert kann es nicht geklaut werden bin mir nicht sicher.

</Edit>

----------

## Tyrus

Zur Frage zum Swap:

Mein Swap liegt zusammen mit Root-Filesystem in der gleichen verschlüsselten Partition. Die hat aber erst LVM zum Inhalt und das erzeugt Logical Volumes. Insofern hab ich genau ein Keyfile. Ich habe auch als 2. Sicherheit Passwörter. Sehr lange wilde Passwörter. Und die sind nicht elektronisch irgendwo abgelegt. Die gibt es tatsächlich auf Papier. Jenachdem wie paranoid du sein willst (*hust*) versteckste diese Zettel entsprechend. Das muss nicht im selben Gebäude sein wo du lebst. Wobei so wichtig sind die Platten nun auch nicht bei mir. Aber gut "weggelegt" hab ich die Passwörter wohl ...  :Wink: 

Und wer das Keyfile replizieren kann, der ist doch eh im System. Nen zweites für Swap halte ich auch für unnötig. 

Wenn du mehr Sicherheit willst dann lagerst du die Headers zu den gecrypteten Partitionen ebenfalls extern. Das macht das ganze nochmal erheblich sicherer. cryptsetup hat da auch Kommandos für. Hab das aber noch nicht gemacht.

Was den Stick angeht - theoretisch kann der kaputt gehen. Da ich davon keine Sicherheitskopie habe - aber eben das Passwort - kann ich zur Not ein neues Keyfile einstellen.

Wenn jemand mit Gewalt an dein System will musst du im Prinzip den Stick zerstören. Du kannst ja ne Kneifzange in der Nähe haben ... je nach dem wie paranoid es sein soll ... *lol*

----------

## alexander_ro

So Paranoid ist das gar nicht ... Hausdurchsuchungen werden in Deutschland heute recht Inflationär durchgeführt. Die Details lasse ich jetzt mal weg. Wer einen nicht Optimal gewarteten Internetzugang Betreibt ist von unerwünschtem Staatsbesuch nicht weit entfernt. Werden dann Kundendaten beschlagnahmt und absichtlich oder versehentlich öffentlich hat der Kunde Schadenersatzanspruch. Das kann teuer werden. Bei einer Hausdurchsuchung wenn die den Keyfile USB finden sind die Kundendaten auch weg.

Darum geht es mir aber gar nicht mal so. Was viel Wahrscheinlicher ist das mir der Rechner auf Reisen geklaut wird. Oder die Lufthansa wieder mein Gepäck nach Israel fliegt obwohl sie mich nach Berlin fliegen. Es kann Wochen dauern das Stück zurück zu bekommen und wer derweilen daran rumspielt kann ich nicht feststellen. Der Tägliche Wahnsinn halt. Ist dann ein Keyfile auf dem USB-Stick und das in der gleichen Tasche kann man sich das verschlüsseln sparen. Mir wäre die Passwort Methode wie jetzt für das Rootfs gemacht lieber. Aber halt das man RootFs und SWAP mit dem einmal eingegeben Passwort entsperrt. Ich will kein LVM weil ich es schlicht nicht brauche und es die Sache nur komplizierter macht.

Ich weiß nicht ob Du das Benutzt aber so ähnlich wie beim Thunderbird. Man kann da einstellen ob der Server zum Empfangen und Senden von Mails das gleiche Paswort benutzt dann muss man es nur einmal eingeben und der Benutzt das dann automatisch für beides.

----------

## Tyrus

Naja auf Reisen kann man den Stick gut am Körper tragen. Wenn es um Diebstahl geht oder das dir dein Gepäck abhanden kommt haste immer den Stick. Natürlich musste den dann schon bei dir führen. Schlüsselbund?

Und sicher liegt es an der Wichtigkeit der Daten was sinnvoll erscheint. Bei nem Passwort ist es etwas das du dir merken kannst. Ein Zettel zum nachsehen mitzuschleppen dauernd weil man eine extrem wilde lange Passwortkombination hat macht für mich keinen Sinn. Wenn du aber ein Passwort hast das du dir merken kannst ist es auch irgendwo leichter es zu erraten. 

Lies mal hier: https://wiki.gentoo.org/wiki/Dm-crypt_full_disk_encryption - da unter "On passphrases, detached LUKS headers, and (encrypted) keyfiles"

Leider wird das Auslagern der LUKS-Header nicht von genkernel unterstützt laut der Wiki. 

Ansich kannst du wenn der swap dir weniger wichtig erscheint aber du ihn verschlüsseln willst das automatisieren.

Dazu hat openRC den service dmcrypt. Der wird bei mir im Boot-Runlevel  gestartet.

Wegen Konfiguration schau dann in /etc/conf.d/dmcrypt.

Da findest du auch einen Eintrag für Swap. Da kannste auch ein Keyfile haben. Leg dazu an einem sinnvollen Ort deiner Wahl im root-Filesystem ein Keyfile an das nur dafür da ist den Swap zu entschlüsseln. Dann brauchste auch nur noch das eine Passwort um das root-Filesystem zu entsperren.

Ich habe einige externe Festplatten die alle verschlüsselt sind und von dem Dienst entschlüsselt werden. Jede hat ihr eigenes Keyfile.

----------

## alexander_ro

Man kann Passwörter schon so machen das man sich die Merken kann und die trotzdem sicher sind. Das was die Presse allen voran die c't immer behaupten das von Menschen erdachte Passwörter generell unsicher sind ist schlicht nicht wahr. Man muss aber schon auf einige Sachen aufpassen was scheinbar gerade Fachredakteuren schwer zu fallen scheint.

Ich habe jetzt mal mit den Methoden für die SWAP Verschlüsselung experimentiert. Das mit den Keyfiles ist halt schon sehr umständlich. Wegen dem shutdown to disk kann man die auch schlecht speichern. Weil beim booten eines früheren Zustandes aus der SWAP-Partition das mounten des rootfs um an die Keys zu kommen vermutlich keine gute Idee ist.

Ich habe jetzt die Änderung an dem Init-Script /etc/initrd.scripts so angepasst:

```

                                # At this point, keyfile or not, we're ready!

                                #####

                                # Ändere den Mapping Namen auf das PartLabel

                                  if [ "$1" = "root" ]; then

                                    Laufwerk=$CRYPT_ROOT

                                  else

                                    Laufwerk=$CRYPT_SWAP

                                  fi

                                  good_msg "Laufwerk: $Laufwerk"

                                  Trennzeichen=`expr index "$Laufwerk" '='`

                                  ErsterTeil=${Laufwerk:$Trennzeichen}

                                  Trennzeichen=`expr index "$ErsterTeil" '='`

                                  ZweiterTeil=${ErsterTeil:$Trennzeichen}

                                  LUKS_NAME=$ZweiterTeil

                                  good_msg "LUKS_NAME: $LUKS_NAME"

                                #

                                #####

                                crypt_filter "${gpg_cmd}cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}"

```

So muss ich zwar momentan das Passwort zweimal eingeben aber es geht zumindest schon mal.

Bei der ganzen Sucherei bin ich zufällig darüber gestolpert das man die Filesysteme auch irgendwie remote entsperren kann. Das wäre sehr hilfreich wenn man mal einen Server aus der Ferne Neustarten muss.

----------

## forrestfunk81

 *alexander_ro wrote:*   

> 
> 
> So muss ich zwar momentan das Passwort zweimal eingeben aber es geht zumindest schon mal.

 

Du kannst auch ein mit LUKS verschlüsseltes loop Device erstellen, in welchem die Schlüssel für die beiden Partitionen abgelegt werden. Dann brauchst du beim Booten nur einmal das Passwort für das loop Device eingeben und hast damit beide Schlüssel zur Verfügung.

```

# create an image file (here 10MB)

dd if=/dev/urandom of=file.img bs=1M count=10

# bind it to a loopback device

losetup /dev/loop0 file.img

# initialize it with luks

cryptsetup [your cipher, key and hash options here] luksFormat /dev/loop0

# open the image file

cryptsetup luksOpen /dev/loop0 keys

# format the image file

mkfs.ext4 /dev/mapper/keys

# mount the image file

mount /dev/mapper/keys /mnt/keys

# copy key files to image

cp /path/to/key1 /mnt/keys/

cp /path/to/key2 /mnt/keys/

# cleanup

umount /mnt/keys

cryptsetup luksClose keys

losetup -d /dev/loop0

```

Das File kann einfach ins Initramfs kopiert werden, dort als loop Device verwendet und mit cryptsetup entschlüsselt werden.

Zum Thema Initramfs packen möchte ich noch die Kernel Konfiguration CONFIG_INITRAMFS_SOURCE in den Raum werfen. Wenn man dort das Source Verzeichnis des entpackten Initramfs angibt (z.B. /usr/src/initramfs), wird der Kernel Build das Initramfs automatisch mit in das Kernel Binary aufnehmen. Dabei am besten gleich einen geeigneten "Built-in initramfs compression mode" auswählen. Das Kernel Binary ist dann zwar um einiges größer und dauert etwas länger zu laden, aber dafür geht das Initramfs nicht mehr verloren. Vorallem aber ist das Erstellen des Initramfs damit ein Kinderspiel, kein 'find .. | cpio .. | xz ' mehr.

Bleibt noch die Frage zum aktuell-Halten des Initramfs. Ich baue meine initramfs meist selbst (Custom Initramfs) und ich habe mir schon mal überlegt, die Binaries im Initramfs Source Verzeichnis auf die im System installierten "System Binaries" zu linken (eventuell per Hardlink). Das habe ich allerdings noch nicht ausprobiert.

----------

## alexander_ro

Das direkt in den Kernel zu integrieren ist sicher auch keine schlechte Idee. Vom laden wird das nicht viel unterschied machen. Ob man zwei kleiner Dateien oder eine große lädt.

Ich benutze genkernel um Kernel und InitRamFs zu erstellen. Das macht mir alles fertig. Ich finde das mit den Labeln besser weil ich es lesen kann im Gegensatz zur UUID und das durchgängig bis zum Mapping Namen für cryptsetup sorgt meiner Meinung für Übersichtlichkeit. Deswegen muss ich einen Patch in das genkernel Initscript einbauen. Das patchen könnte man aber leicht automatisieren. Wenn ich da so schon einen Patch brauche wäre mir die Lösung es so umzubauen das man dem Initscript sagen kann es soll ein Passwort für beides benutzen. Ich muss das aber erst noch finden wie die bei dem genkernel Initscript das ändern kann.

Falsch war der Code oben nicht weil er tut was er sollte ... wirklich richtig aber auch nicht ...  :Smile: 

Hier die Verbesserung:

```

# At this point, keyfile or not, we're ready!

#####

# Ändere den Mapping Namen auf das PartLabel

  if [ "$1" = "root" ]; then

    Laufwerk=$CRYPT_ROOT

  else

    Laufwerk=$CRYPT_SWAP

  fi

  good_msg "Laufwerk: $Laufwerk"

  Trennzeichen=`expr index "$Laufwerk" '='`

  LUKS_NAME=${Laufwerk:$Trennzeichen}

  good_msg "LUKS_NAME: $LUKS_NAME"

#

#####

                                  

crypt_filter "${gpg_cmd}cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}"

```

<Edit>

Irgendwie geht das immer nicht so wie ich es gerne hätte ...

Das Passwort ein zweites mal zu benutzen geht nicht weil man ein Passwort an cryptsetup nicht übergeben kann. 

Geht doch ist mir nur nicht gleich eingefallen es zu versuchen: echo '<Passwd>' | cryptsetup open /dev/sdb4 GentooRoot

(Den Rest habe ich wieder gelöscht ist ja dann nicht nötig.)

</Edit>

----------

## alexander_ro

Weiß jemand warum man bei genkernel für das InitRamFs keine andere als die Englische Tastatur einstellen kann. Man soll da Passwörter mit Sonderzeichen eingeben aber mit falschen Tastaturlayout. Oder man muss jedesmal die Tastatur extra wieder auswählen. Das macht nur Sinn bei einer Life-CD aber nicht bei einer Installation die an einen Rechner gebunden ist. Ich vermute jetzt mal das wenn man die Laufwerke per SSH Entsperren will geht diese Art der Tastaturauswahl aber nicht mehr.

----------

## Tyrus

Du kannst genkernel sagen das es die Keymap als Bootparameter beachtet.

Also in der manpage steht:

```

       --[no-]keymap

           Enables or disables keymap selection at boot.

```

Das bedeutet du musst wohl beim Aufruf 

```

genkernel --keymap ...

```

benutzen.

Wegen des Kernelparamters steht dann in der manpage zu genkernel:

```

[...]

RAMDISK/INITRAMFS OPTIONS

       The following options are some of those available to be passed as kernel parameters from the bootloader. Genkernel will not handle this

       operation, please refer to your bootloader documentation for a more complete description of each.

[...]

       keymap=MAP

           Set keymap to MAP, e.g.  keymap=de. For valid values of MAP please see /usr/share/genkernel/defaults/keymaps/.

       dokeymap

           Use keymap. Usage of keymap= implies this option, already.

[...]

```

Also musst du dann auch /etc/default/grub anpassen. Da kommen die Bootparameter ja rein.

Da drin:

```

[...]

GRUB_CMDLINE_LINUX='crypt_root=UUID=d5a3428b-b21c-42b4-a4ce-0818c92bca9c real_root=/dev/mapper/GENTOO-ROOT root_keydev=UUID=E716-DA12 root_key=dmcrypt-2.key dobtrfs dolvm'  keymap=de dokeymap

[...]

```

Das ist nur ein Beispiel. Aber denke da kommt das hin. Wobei wahrscheinlich 'dokeymap' weggelassen werden kann.

Also genkernel baut dann zusätzlich die benötigten Binaries um die Keymap einzustellen. Welche Keymap genommen wird, kommt dann von Grub als Bootparamter später.

Und nicht vergessen 

```

grub-mkconfig -o /boot/grub/grub.cfg

```

----------

## alexander_ro

Bin etwas verwirrt ... hat der Kernel überhaupt was mit der Keymap zu tun?

Warum konfiguriert den genkernel nicht gleich das InitRamFs (das es ja so selbst baut) so das es die gewünschte Keymap benutzt. Hat das irgendeinen Nutzen wenn man es erst noch durch den Kernel schleust?

----------

## alexander_ro

Ich habe jetzt mal versucht zum Testen ein initramfs selber zu bauen. Ich kopiere einfach die nötigen Dateien aus meinem rootfs zusammen. Das macht folgendes Script.

```

#!/bin/bash

#####

# Hinweise:

# Das Script muss man als User root ausführen.

# Parameter:

# $1 Pfand in dem das InitRamFs erstellt werden soll.

#    Wird nichts angegeben wird es im aktuellen Verzeichnis erstellt.

#

#####

Pfad=$1

#####

# Verzeichnise im Root-Verzeichnis anlegen.

  mkdir --parents --mode=u=+rwx,g=+rx-w,o=+rx-w ${Pfad}bin

  mkdir --parents --mode=u=+rwx,g=+rx-w,o=+rx-w ${Pfad}dev

  mkdir --parents --mode=u=+rwx,g=+rx-w,o=+rx-w ${Pfad}etc

  mkdir --parents --mode=u=+rx-w,g=+rx-w,o=+rx-w ${Pfad}proc

#

#####

#####

# Busybox kopieren und konfigurieren.

#

  cp --archive /bin/busybox ${Pfad}bin

# Symbolisch Verlinkungen anlegen.

  aktuellerPfad="`pwd`"

  cd ${Pfad}bin

  ln --force --symbolic busybox sh

  ln --force --symbolic busybox ash

  cd ${aktuellerPfad}

#

#####

#####

# Boot Script erzeugen.

  aktuellerPfad="`pwd`"

  cd ${Pfad}

  cat > "init" << INIT

#!/bin/sh

echo "Geht das jetzt?"

[ ! -e /dev/console ]  && mknod /dev/console c 5 1

[ ! -e /dev/null ]     && mknod /dev/null c 1 3

[ ! -e /dev/tty ]      && mknod /dev/tty c 5 0

[ ! -e /dev/tty0 ]     && mknod /dev/tty0 c 4 0

[ ! -e /dev/tty1 ]     && mknod /dev/tty1 c 4 1

[ ! -e /dev/ttyS0 ]    && mknod /dev/ttyS0 c 4 64

[ ! -e /dev/ttyS1 ]    && mknod /dev/ttyS1 c 4 65

[ ! -e /dev/urandom ]  && mknod /dev/urandom c 1 9

[ ! -e /dev/random ]   && mknod /dev/random c 1 8

[ ! -e /dev/zero ]     && mknod /dev/zero c 1 5

exec /bin/sh

INIT

  chmod u=+rwx,g=-rwx,o=-rwx init

  ln --force --symbolic init linuxrc

  cd ${aktuellerPfad}

#

#####

```

Bekommt man mit "chroot MeinInitRamFs/ /init" einen Shell-Prompt innerhalb des gebauten initramfs.

Wenn man das so in ein initramfs verpackt;

```

#!/bin/bash

Version=5.4.48

Pfad=$1

echo "Erstelle cpio Archiv"

find ./$Pfad -print0 | sort -z | cpio --quiet --null -o -H newc --owner root:root --force-local --reproducible -F initramfs-$Version-gentoo-x86_64.img

echo "InitRamFs mit xz komprimieren"

#xz --compress --extreme -9 --check=none --force initramfs-$Version-gentoo-x86_64.img

gzip -9 initramfs-$Version-gentoo-x86_64.img

echo "xz vom Dateinamen entfernen"

#mv initramfs-$Version-gentoo-x86_64.img.xz initramfs-$Version-gentoo-x86_64.img

mv initramfs-$Version-gentoo-x86_64.img.gz initramfs-$Version-gentoo-x86_64.img

echo "Installiere InitRamFs"

cp -a initramfs-$Version-gentoo-x86_64.img /mnt/boot

```

und mit Qemu versucht zu booten geht es nicht.

```

qemu-system-x86_64 -kernel /boot/vmlinuz-5.4.48-gentoo-x86_64 -initrd initramfs-5.4.48-gentoo-x86_64.img -nographic -append "console=ttyS0"

```

Mekert der Kernel

```

...

pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]

PCI: CLS 0 bytes, default 64

Trying to unpack rootfs image as initramfs...

Freeing initrd memory: 1124K

Initialise system trusted keyrings

workingset: timestamp_bits=62 max_order=15 bucket_order=0

...

--[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

...

```

Finden und entpacken tut er es nur nicht ausführen.

Hier liest sich das so (wenn richtig Übersetzt) als würde der Kernel das initramfs als erstes rootfs benutzen.

https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Hab wohl irgendwas übersehen ...

----------

## alexander_ro

Jetzt habe ich gefunden was ich da falsch gemacht habe. Das hier war etwas ungeschickt ...

```

find ./$Pfad -print0 | sort -z | cpio --quiet --null -o -H newc --owner root:root --force-local --reproducible -F initramfs-$Version-gentoo-x86_64.img

```

Mit dem "./$Pfad" bekommt man ein Archiv das alles in einem Unterverzeichnis hat was der Kernel nicht versteht weil halt die ganzen Pfad angaben dann falsch sind. Logisch ...

Hab es so geändert:

```

cd ./$Pfad

find . -print0 | sort -z | cpio --verbose --null -o -H newc --owner root:root --force-local --reproducible -F ../initramfs-$Version-gentoo-x86_64.img

cd ..

```

Das --verbose gibt dann Pfad und Dateinamen jeder Datei aus die ins Archiv kommt dann sieht man das auch wenn etwas falsch ist.

Das kann man jetzt mit Qemu wie oben angegeben booten. Gibt aber noch Fehlermeldung:

```

Geht das jetzt?[    4.575384] random: fast init done

/bin/sh: can't access tty; job control turned off

```

man bekommt aber schon eine Shell mit der man dann experimentieren kann ...  :Smile: 

----------

## alexander_ro

Och nee ... jetzt haben die die Option --disklabel ausgebaut.

```

genkernel --no-clean --luks --disklabel --microcode --menuconfig all

```

Den Mist mit der UUID gibts noch war ja klar warum Übersichtlich wenn man die Verwirrung Maximieren kann. Jetzt hatte ich mich gefreut weil nach Wochenlanger Arbeite mal was ging und auch auf den ersten Blick zu erkennen war was wie zusammengehört dann wird es einem wieder ohne Vorwarnung kaputt gemacht ... herzlichen Dank auch ...  :Sad: 

----------

