Hallo Gruppe,
ich schreibe gerade am Notfallhandbuch und versuche eine ext4 crypted Verzeichnisstruktur an einem beliebigen anderen Rechner zu lesen.
Hängt die Backupplatte am zu sichernden Rechner, verwende ich 'e4crypt add_key -k @u /backup/crypted' und erhalte "Added key with descriptor [***719]"
Hänge ich die Platte an einen anderen Rechner (auch debian 12 amd64, gleicher kernel) und verwende den gleichen Befehl, erhalte ich: "Added key with descriptor [***870]" "Error [File exists] setting policy" "The key descriptor [***870] man not match the existing encryption context for directory [/backup/crypted]"
Die Verzeichnisstruktur ist dann für mich unlesbar (Buchstabensalat) und in die Dateien darf ich nicht reinschauen (cat $FILE ... Der notwendige Schlüssel ist nicht verfügbar)
Ich bin sicher, dass ich beide Male das gleiche Kennwort eingebe. Ich bin sicher, dass beide Keyboard-Layouts identisch sind. Ich habe schon einen 3. Rechner probiert - gleiches Phänomen.
'e4crypt add_key -k @u' auf der Backupmaschiene, gefüttert mit "bernd" liefert: Enter passphrase (echo disabled): Added key with descriptor [b975e6332e33edb7] Added key with descriptor [f33468f048ce7354]
Das gleiche auf den anderen "restore"-Testmaschinen leifert hingegen: Enter passphrase (echo disabled): Added key with descriptor [f33468f048ce7354]
Warum hat das Backupsystem ZWEI descriptoren?
Ich bin ratlos, hat wer eine Idee?
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Am 16.09.24 um 16:19 schrieb ronny@seffner.de:
ich schreibe gerade am Notfallhandbuch
Oh, das klingt spannend. An welchem? Oder "nur" an einem speziellen, nicht allgemein hilfreichen?
und versuche eine ext4 crypted Verzeichnisstruktur an einem beliebigen anderen Rechner zu lesen.
Hängt die Backupplatte am zu sichernden Rechner, verwende ich 'e4crypt add_key -k @u /backup/crypted' und erhalte "Added key with descriptor [***719]"
Vielleicht hilft dir dieser Eintrag aus dem Archwiki: https://wiki.archlinux.org/title/Fscrypt
The e4crypt tool from e2fsprogs can be used as an alternative to the fscrypt tool. However, this is not recommended since e4crypt is missing many basic features and is no longer being actively developed.
Gruß Uwe
ich schreibe gerade am Notfallhandbuch
Oh, das klingt spannend. An welchem? Oder "nur" an einem speziellen, nicht allgemein hilfreichen?
An einem Speziellen, nix was "recyclebar" ist.
Vielleicht hilft dir dieser Eintrag aus dem Archwiki: https://wiki.archlinux.org/title/Fscrypt
Danke für den Hinweis. Da es an einem System aber mit e4crypt geht, will ich als "Ersatz" meiner Unfähigkeit nicht am anderen "fscrypt" verwenden.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
Am Montag, dem 16.09.2024 um 16:19 +0200 schrieb ronny@seffner.de:
Hallo Gruppe,
Hallo Ronny
ich schreibe gerade am Notfallhandbuch
OK, sollte man ja haben. Nutzt Du da eine bestimmte Vorlage und passt Sie an oder erstellt nach Bedarf?
und versuche eine ext4 crypted Verzeichnisstruktur an einem beliebigen anderen Rechner zu lesen.
Ich gehe mal davon aus es verhält sich ähnlich wie f2fscrypt. Hierbei hab ich immer das -S Argument benötigt um es auf anderen Geräten nutzen zu können.
Hängt die Backupplatte am zu sichernden Rechner, verwende ich 'e4crypt add_key -k @u /backup/crypted' und erhalte "Added key with descriptor [***719]"
Was ist da dein Salt-Argument (-S)? Wird das auf den anderen Rechnern gleich initialisiert? Vermute mal "man e4crypt" hast du gelesen.
Hänge ich die Platte an einen anderen Rechner (auch debian 12 amd64, gleicher kernel) und verwende den gleichen Befehl, erhalte ich: "Added key with descriptor [***870]" "Error [File exists] setting policy" "The key descriptor [***870] man not match the existing encryption context for directory [/backup/crypted]"
Die Verzeichnisstruktur ist dann für mich unlesbar (Buchstabensalat) und in die Dateien darf ich nicht reinschauen (cat $FILE ... Der notwendige Schlüssel ist nicht verfügbar)
Ich bin sicher, dass ich beide Male das gleiche Kennwort eingebe. Ich bin sicher, dass beide Keyboard-Layouts identisch sind. Ich habe schon einen 3. Rechner probiert - gleiches Phänomen.
Was sagt dein process keyring keyctl show
'e4crypt add_key -k @u' auf der Backupmaschiene, gefüttert mit "bernd" liefert: Enter passphrase (echo disabled): Added key with descriptor [b975e6332e33edb7] Added key with descriptor [f33468f048ce7354]
Das gleiche auf den anderen "restore"-Testmaschinen leifert hingegen: Enter passphrase (echo disabled): Added key with descriptor [f33468f048ce7354]
Warum hat das Backupsystem ZWEI descriptoren?
Würde vermuten unterschiedliche Initialisierung.
VG Gerd
Ich bin ratlos, hat wer eine Idee?
Mit freundlichen Grüßen / Kind regards Ronny Seffner
ich schreibe gerade am Notfallhandbuch
OK, sollte man ja haben. Nutzt Du da eine bestimmte Vorlage und passt Sie an oder erstellt nach Bedarf?
Keine Vorlage, nur Stichpunkte für den panischen/hektischen Admin zum desaster recovery.
Hierbei hab ich immer das -S Argument benötigt um es auf anderen Geräten nutzen zu können.
Ich habe es gerade verstanden und selber gelöst. Der "-S" Hinweis ist da genau das richtige.
- aktiviert man die crypt features mittels tune2fs, wird pro device ein salt angelegt. - am Backupsystem habe ich zwei solcher Platten/Partitionen - mein Skript mountet EINE davon (EIN Salt) und fragt nach dem key, das führt zu EINEM descriptor - später mounte ich die zweite Platte und offenbar hatte ich dort mittels "e4crypt set_policy" diesen EINEN descriptor aus dem salt der ERSTEN Platte verwendet
- für die Notfalltest hatte ich nun genau diese zweite Platte in der Hand und "e4crypt add_key" ohne "-S" nimmt nun das salt eben dieser zweiten Platte und führt zu einen abweichenden descriptor - jedes weitere "e4crypt add_key" spuckt nun nach dem zweiten mount auch immer zwei descriptoen (einen für jedes salt) aus
- mittels "e4crypt add_key -S $salt_der_ersten_platte" bekomme ich nun auch die zweite aufgeschlossen.
Mit freundlichen Grüßen / Kind regards Ronny Seffner
lug-dd@mailman.schlittermann.de
-
Gerd G -
ronny＠seffner.de -
Uwe Koloska