LUKS-Image mit wachsender Größe

[Marco Moock]

Hallo zusammen!

Gegeben sei ein System mit ext4 auf /. Nun soll ein LUKS-Image dazu,
das dynamisch mit dem Inhalt in seiner Größe wächst, da die Platte
nicht allzu groß ist.

Ist das ohne Komplikationen möglich?

Praktisch sowas wie vdi bei Virtualbox, aber halt ohne VM und sowas,
nur mit LUKS.

[Thomas Klix]

Post by Marco Moock
Hallo zusammen!
Gegeben sei ein System mit ext4 auf /. Nun soll ein LUKS-Image dazu,
das dynamisch mit dem Inhalt in seiner Größe wächst, da die Platte
nicht allzu groß ist.

LUKS kennt keine dynamischen Größen.
(Was meinst du mit LUKS-Image? PV (Physical Volume?)

Post by Marco Moock
Ist das ohne Komplikationen möglich?

Nein.

Das einzige, was mir dazu einfällt, ist "partitionmanager" (KDE) - der
kann auch eingehängte PV/VG/LV in der Größe ändern. D.h., mit "df" oder
so die Belegung im Auge behalten - und ggf. nachjustieren.
So muss man wenigstens nicht mit externem Linux auf das LUKS zugreifen.
:-)

Post by Marco Moock
Praktisch sowas wie vdi bei Virtualbox, aber halt ohne VM und sowas,
nur mit LUKS.

Ja, man kann ja mal träumen. :-)

Thomas

[Marco Moock]

Post by Thomas Klix

Post by Marco Moock
Hallo zusammen!
Gegeben sei ein System mit ext4 auf /. Nun soll ein LUKS-Image dazu,
das dynamisch mit dem Inhalt in seiner Größe wächst, da die Platte
nicht allzu groß ist.

LUKS kennt keine dynamischen Größen.

Schade. Ich gucke mal, ob ecryptfs geeignet ist.

Post by Thomas Klix
(Was meinst du mit LUKS-Image? PV (Physical Volume?)

Datei auf /, die per LUKS beschrieben wird, statt einem echten
Datenträger.

[Thomas Klix]

Post by Marco Moock

Post by Thomas Klix

Post by Marco Moock
Hallo zusammen!
Gegeben sei ein System mit ext4 auf /. Nun soll ein LUKS-Image dazu,
das dynamisch mit dem Inhalt in seiner Größe wächst, da die Platte
nicht allzu groß ist.

LUKS kennt keine dynamischen Größen.

Schade. Ich gucke mal, ob ecryptfs geeignet ist.

Post by Thomas Klix
(Was meinst du mit LUKS-Image? PV (Physical Volume?)

Datei auf /, die per LUKS beschrieben wird, statt einem echten
Datenträger.

O-kay. Ich habe keine Ahnung, wie sich PV/VG/LV verhalten, wenn das PV
ein sparse-file ist. Ich habe bisher immer Partitionen verwendet.
Wenn das PV ein sparse-file ist, könnte es sein, dass das transparent
bis zum LV ist. Wieder was zum ausprobieren. :-)

Mit "dd if=/dev/zero of=luks-pv bs=1 count=0 seek=2G" bekommst du eine
(leere) Datei von 2G Größe, die 0 Byte belegt. Das ist doch ein Anfang.
:-)

Thomas

[Thomas Klix]

Post by Thomas Klix
[...]
O-kay. Ich habe keine Ahnung, wie sich PV/VG/LV verhalten, wenn das PV
ein sparse-file ist.

Tja, schön wäre es gewesen.
pvcreate akzeptiert nur echte Geräte, die es unter /dev/ findet.

Die Unix-Philosophie (erst einmal ist alles ein Bytehaufen - wie ich
ihn anspreche, ist entscheidend) greift hier nicht. Ich kann Dateien
mounten, wenn ich sie als Filesystem anspreche, ich kann Blockdevices
oder einzelne Partitionen in Dateien speichern - und umgekehrt. (Gilt
natürlich auch für LUKS - nur eben in /dev/mapper).

Aber LUKS meint mit "Physisches Volume" wirklich physisch.
Wusste ich auch nicht mehr - Wann beschäftigt man sich schon mit dem
Kram, wenn es einmal läuft...

Thomas

[Lutz Falke]

Post by Thomas Klix

Post by Thomas Klix
[...]
O-kay. Ich habe keine Ahnung, wie sich PV/VG/LV verhalten, wenn das PV
ein sparse-file ist.

Tja, schön wäre es gewesen.
pvcreate akzeptiert nur echte Geräte, die es unter /dev/ findet.

Macht doch nichts. losetup ist dein Freund.
Erst Image erzeugen. Dann mit losetup ein /dev/loop? bereitstellen.
Anschließend dann pvcreate darauf anwenden.

Post by Thomas Klix
Die Unix-Philosophie (erst einmal ist alles ein Bytehaufen - wie ich
ihn anspreche, ist entscheidend) greift hier nicht. Ich kann Dateien
mounten, wenn ich sie als Filesystem anspreche, ich kann Blockdevices
oder einzelne Partitionen in Dateien speichern - und umgekehrt. (Gilt
natürlich auch für LUKS - nur eben in /dev/mapper).

Der DeviceMapper ist sehr flexibel, die Dinger kann man mit dmsetup
beliebig stapeln. Er will aber immer "echte" Blockdevices haben.
notfalls muss man die halt als Loop-Device bereitstellen.

Das Mounten von Images funktioniert ja genauso. Da passiert das
Anlegen des Loop-Devices nur teilweise automatisch im Hintergrund.

Post by Thomas Klix
Aber LUKS meint mit "Physisches Volume" wirklich physisch.
Wusste ich auch nicht mehr - Wann beschäftigt man sich schon mit dem
Kram, wenn es einmal läuft...

LUKS braucht ja nicht zwingend ein PV. Das kommt ja aus der LVM-Welt
und ist nochmal eine zusätzliche Schicht. Ich hatte ja auch zuerst an
ein LVM mit Thinprovisioning gedacht, das scheint aber doch etwas dick
aufgetragen. :)

Lutz

[Thomas Klix]

Post by Lutz Falke

Post by Thomas Klix

Post by Thomas Klix
[...]
O-kay. Ich habe keine Ahnung, wie sich PV/VG/LV verhalten, wenn das PV
ein sparse-file ist.

Tja, schön wäre es gewesen.
pvcreate akzeptiert nur echte Geräte, die es unter /dev/ findet.

Macht doch nichts. losetup ist dein Freund.
Erst Image erzeugen. Dann mit losetup ein /dev/loop? bereitstellen.
Anschließend dann pvcreate darauf anwenden.

Danke für die Korrektur - das ist die eine Möglichkeit, an die ich
nicht gedacht habe.
Die andere hast du im Parallelposting genannt: direkt cryptsetup & mkfs.

Wie gesagt, wenn es einmal eingerichtet ist und läuft, denkt man nicht
oft darüber nach...

Thomas

[Lutz Falke]

Post by Marco Moock
Gegeben sei ein System mit ext4 auf /. Nun soll ein LUKS-Image dazu,
das dynamisch mit dem Inhalt in seiner Größe wächst, da die Platte
nicht allzu groß ist.

Man kann mit "cryptsetup resize ..." die von LUKS verwendete Größe
inherhalb des Images oder der Partition ändern. Siehe
cryptsetup-resize(8). Du musst halt selbst sicherstellen, dass du
damit das enthaltene Dateisystem nicht kaputt machst.

Du kannst auch das Image als Sparse-File anlegen, dann kann das in
gewissen Grenzen mitwachsen.

Etwa so:

# truncate -s 64G test.img

# ls -lsha test.img
0 -rw-rw-r-- 1 root root 64G Aug 19 23:22 test.img

# cryptsetup luksFormat test.img
[...]

# ls -lsha test.img
16M -rw-rw-r-- 1 root root 64G Aug 19 23:23 test.img

# cryptsetup open test.img test
[...]

# mkfs.ext4 -v -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/test
[...]

# ls -lsha test.img
1.3G -rw-rw-r-- 1 root root 64G Aug 19 23:25 test.img

# mount /dev/mapper/test /mnt

# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/test 63G 2.1M 60G 1% /mnt

# dd if=/dev/urandom of=/mnt/foo bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.64029 s, 295 MB/s

# ls -lsha /mnt/
total 1.1G
4.0K drwxr-xr-x 3 root root 4.0K Aug 19 23:27 .
4.0K drwxr-xr-x 19 root root 4.0K Aug 19 22:36 ..
1.1G -rw-rw-r-- 1 root root 1.0G Aug 19 23:27 foo
16K drwx------ 2 root root 16K Aug 19 23:25 lost+found

# umount /mnt

# ls -lsha test.img
2.3G -rw-rw-r-- 1 root root 64G Aug 19 23:29 test.img

# cryptsetup close test

Der Kürze wegen alles als root. Das geht alles (bis auf das Erzeugen
des Dateisystems) auch mit "udisksctl loop-setup", "udisksctl unlock"
und "udisksctl mount", wenn du ein passendes Desktop-Setup mit PolKit
etc. pp. hast.

Post by Marco Moock
Ist das ohne Komplikationen möglich?

Zwei Sachen fallen mir direkt ein:

- Wenn dir auf dem Dateisystem, wo das Image draufliegt, der
Speicherplatz ausgeht, dann knallts halt. Da fängt sich dann der
DeviceMapper und das Dateisystem einen IO-Error ein. Ich habe jetzt
nicht nachgelesen/getestet, wie die damit umgehen.

- Das Image wird, wenn du Daten löschst, nicht wieder schrumpfen. Das
machen VDIs aber AFAIK auch nicht von alleine.

HTH,
Lutz

[Thomas Dorner]

Post by Lutz Falke
Du kannst auch das Image als Sparse-File anlegen, dann kann das in
gewissen Grenzen mitwachsen.

Korrekt, so etwas habe ich seit einiger Zeit im Einsatz:
# l -h mydata
-rw------- 1 root root 70G 2024-08-19 11:12 mydata
# du -sh mydata
23G mydata
# df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/vda3 157G 31G 120G 21% /

Post by Lutz Falke
# truncate -s 64G test.img

Genau so mit truncate habe ich den Container erzeugt.

Post by Lutz Falke

Post by Marco Moock
Ist das ohne Komplikationen möglich?

- Wenn dir auf dem Dateisystem, wo das Image draufliegt, der
Speicherplatz ausgeht, dann knallts halt. Da fängt sich dann der
DeviceMapper und das Dateisystem einen IO-Error ein. Ich habe jetzt
nicht nachgelesen/getestet, wie die damit umgehen.

Ja, da muß man aufpassen.

Viele Grüße, Thomas

[Lutz Falke]

Post by Lutz Falke

Post by Marco Moock
Gegeben sei ein System mit ext4 auf /. Nun soll ein LUKS-Image dazu,
das dynamisch mit dem Inhalt in seiner Größe wächst, da die Platte
nicht allzu groß ist.

Du kannst auch das Image als Sparse-File anlegen, dann kann das in
gewissen Grenzen mitwachsen.

Hier habe ich noch etwas zu ergänzen: Schrumpfen von Sparse-Files geht
doch! Voraussetzung ist, dass das Image auf eimen Dateisystem liegt,
das fallocate(2) unterstützt. Das sind laut Manpage Ext4, XFS und
Btrfs.

Post by Lutz Falke
# truncate -s 64G test.img
# ls -lsha test.img
0 -rw-rw-r-- 1 root root 64G Aug 19 23:22 test.img
# cryptsetup luksFormat test.img
[...]
# ls -lsha test.img
16M -rw-rw-r-- 1 root root 64G Aug 19 23:23 test.img
# cryptsetup open test.img test
[...]

An dieser Stelle kaufe ich ein "--allow-discards". Das Loop-Device
kann tatsächlich TRIM/Discard-Kommandos verarbeiten, wenn das Image
auf einem passenden Dateisystem liegt.

# cryptsetup open --allow-discards test.img test

Post by Lutz Falke
# mkfs.ext4 -v -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/test
[...]
# ls -lsha test.img
1.3G -rw-rw-r-- 1 root root 64G Aug 19 23:25 test.img
# mount /dev/mapper/test /mnt
# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/test 63G 2.1M 60G 1% /mnt
# dd if=/dev/urandom of=/mnt/foo bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 3.64029 s, 295 MB/s
# ls -lsha /mnt/
total 1.1G
4.0K drwxr-xr-x 3 root root 4.0K Aug 19 23:27 .
4.0K drwxr-xr-x 19 root root 4.0K Aug 19 22:36 ..
1.1G -rw-rw-r-- 1 root root 1.0G Aug 19 23:27 foo
16K drwx------ 2 root root 16K Aug 19 23:25 lost+found
# umount /mnt
# ls -lsha test.img
2.3G -rw-rw-r-- 1 root root 64G Aug 19 23:29 test.img

# mount /dev/mapper/test /mnt

# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/test 63G 1.1G 59G 2% /mnt

# rm /mnt/foo

# df -h /mnt
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/test 63G 2.1M 60G 1% /mnt

# fstrim -v /mnt
/mnt: 62.7 GiB (67299201024 bytes) trimmed

# umount /mnt

Post by Lutz Falke
# cryptsetup close test

# ls -lsh test.img
1.3G -rw-rw-r-- 1 root root 64G Aug 21 23:16 test.img

Faszinierend! Ich bin immer wieder begeistert, was so alles
geht und wie das alles zusammenpasst. :)

Post by Lutz Falke

Post by Marco Moock
Ist das ohne Komplikationen möglich?

[...]
- Das Image wird, wenn du Daten löschst, nicht wieder schrumpfen. Das
machen VDIs aber AFAIK auch nicht von alleine.

Das hat sich ja dann erledigt. Der Punkt geht an das
Loopback-Device. ;)


Lutz

[Marcel Mueller]

Post by Marco Moock
Hallo zusammen!
Gegeben sei ein System mit ext4 auf /. Nun soll ein LUKS-Image dazu,
das dynamisch mit dem Inhalt in seiner Größe wächst, da die Platte
nicht allzu groß ist.

Das geht so nicht und würde auch nicht viel bringen, denn Platz der
einmal verbraucht wurde, bleibt ja verbraucht.

Post by Marco Moock
Praktisch sowas wie vdi bei Virtualbox, aber halt ohne VM und sowas,
nur mit LUKS.

VBox kann das auch nicht in sinnvoller Weise.
Die Management Block Size von VDI ist 1MB. Wenn auch nur ein einziger
Block davon noch in Benutzung ist (nicht unwahrscheinlich), wird nichts
freigegeben. Und selbst wenn nicht, wird das VDI-Image nur nach
Komprimierung kleiner.
Bei Verschlüsselung hat man zudem das Problem, dass das Trimmen freier
Bereichen Information Disclosure ist, denn man könnte daraus in gewissen
grenzen auf den Inhalt der Free-Space-Bitmaps des Dateisystems
schließen, und diese Information wiederum Nutzen, um die Verschlüsselung
leichter zu knacken.


Die Frage ist eher, was du vor hast. Den Platz dynamisch zu teilen,
ergibt ja nur Sinn, wenn man noch irgendetwas anders hat, was auch
dynamisch kleiner wird oder zumindest nicht gleichzeitig Lastspitzen
erzeugt. Was sollte das sein? /home? Wenn ja müssen die Sachen halt auf
dasselbe Volume.

Aber mal im ernst, wie klein ist denn die Platte? Eine SSD auf der
mühelos mehrere Linuxsysteme Platz haben kostet 20€. Ein Linux wiederum
kommt mit 30-40GB für / (ohne /home) aus. Aktuell habe ich hier sogar
nur 20, was mittlerweile wirklich knapp ist.
/dev/sda1 19046484 16213172 1840444 90% /
Das ist eine Xubuntu VM, die schon so manches OS-Upgrade überstanden
hat. Das fliegt demnächst aber runter (wegen dem Snap-Sch***).
Lokal am Laptop habe ich 30GB für /, von denen dank Linux Mint fast 20
frei sind.

Also verrate erst mal, was es werden soll, dann findet sich bestimmt
auch eine Lösung.


Marcel

[Marco Moock]

Post by Marcel Mueller

Post by Marco Moock
Gegeben sei ein System mit ext4 auf /. Nun soll ein LUKS-Image dazu,
das dynamisch mit dem Inhalt in seiner Größe wächst, da die Platte
nicht allzu groß ist.

Das geht so nicht und würde auch nicht viel bringen, denn Platz der
einmal verbraucht wurde, bleibt ja verbraucht.

Stimmt, aber die Idee war, dass die Datei halt dynamisch größer oder
kleiner wird (ist halt wohl nicht so) und man dann flexibler ist, wenn
/ mal größer werden sollte.

Post by Marcel Mueller
Die Frage ist eher, was du vor hast. Den Platz dynamisch zu teilen,
ergibt ja nur Sinn, wenn man noch irgendetwas anders hat, was auch
dynamisch kleiner wird oder zumindest nicht gleichzeitig Lastspitzen
erzeugt. Was sollte das sein? /home? Wenn ja müssen die Sachen halt
auf dasselbe Volume.

Installiertes Slackware auf ner HDD mit 40GB. / belegt davon halt
aktuell alles und /home soll nun doch verschlüsselt werden.
Klar kann ich / verkleinern und dann ne separate Partition für /home
anlegen. 10 GB sollten reichen.

Und nein, es wird keine neue Platte gekauft für das alte Teil.

[Tim Ritberg]

Post by Marco Moock
Installiertes Slackware auf ner HDD mit 40GB. / belegt davon halt
aktuell alles und /home soll nun doch verschlüsselt werden.
Klar kann ich / verkleinern und dann ne separate Partition für /home
anlegen. 10 GB sollten reichen.
Und nein, es wird keine neue Platte gekauft für das alte Teil.

ext4 encrytion existiert...

Tim

[Marcel Mueller]

Post by Marco Moock
Installiertes Slackware auf ner HDD mit 40GB. / belegt davon halt
aktuell alles und /home soll nun doch verschlüsselt werden.

Das könntest du aber auch mit ecryptfs machen. Das kann einzelne Ordner
verschlüsseln.

Diese Verschlüsselung gilt als nicht sonderlich sicher, weil natürlich
an anderen Stellen im System immer irgendwelche Informationen leaken.
Aber das Ziel /home zu verschlüsseln erreicht man damit. Es wird dann
halt jeder einzelne User mit seinem eigenen Key verschlüsselt.

Post by Marco Moock
Klar kann ich / verkleinern und dann ne separate Partition für /home
anlegen. 10 GB sollten reichen.

Geht auch, ist aber Gefummel. Mutmaßlich wäre Backup/Restore fällig. Man
kann ext4 zwar verkleinern, aber eben nur wenn auch 10GB frei sind.
Einen Befehl zum Teilen gibt es nicht.

Post by Marco Moock
Und nein, es wird keine neue Platte gekauft für das alte Teil.

Hat der echt noch ne HDD?
Das ist doch lahm ohne Ende.

Ich nutze seit 15 Jahren keine HDDs mehr zum täglichen arbeiten. Ich
habe damals von Cheetah 15k (eine der schnellsten Platten, die es je
gab) auf SSD umgestellt, und selbst das hat der zu dem Zeitpunkt 10
Jahre alten Kiste nochmal einen ordentlichen Schub verpasst.


Marcel

[Marc Haber]

Post by Marcel Mueller
Ich nutze seit 15 Jahren keine HDDs mehr zum täglichen arbeiten. Ich
habe damals von Cheetah 15k (eine der schnellsten Platten, die es je
gab) auf SSD umgestellt, und selbst das hat der zu dem Zeitpunkt 10
Jahre alten Kiste nochmal einen ordentlichen Schub verpasst.

Mein 2012 gekauftes T520 hatte anfänglich noch rotierenden Rost. Ich
glaube, das war die letzte 2,5 Zoll HDD die ich gekauft habe. Als dann
die erste SSD kam, zog die HDD in die Ultrabay um. So war das dann bis
2018, bis zum etwas überstürzten¹ Umstieg auf das X260, das dann eine
2 TB SSD bekam (keine Ultrabay mehr).

¹ ich hatte den Koffer mit dem T520 im Zug liegengelassen und musste
deswegen direkt und ungeplant auf das X260 umsteigen, das ich
eigentlich nur für die Reisen zum Kunden und zur Nutzung beim Kunden
vorgesehen hatte (das T520 war zu groß und zu schwer). Als ich den
Koffer zwei Wochen später zurückbekam, bin ich nie wieder zurück auf
das große Notebook zurückgewechselt.

Grüße
Marc

[Ralph Aichinger]

Post by Marcel Mueller
Diese Verschlüsselung gilt als nicht sonderlich sicher, weil natürlich
an anderen Stellen im System immer irgendwelche Informationen leaken.
Aber das Ziel /home zu verschlüsseln erreicht man damit. Es wird dann
halt jeder einzelne User mit seinem eigenen Key verschlüsselt.

Wenn es nur um /home geht, dann könnte man auch die Lösung von systemd
in Erwägung ziehen, systemd-homed.

/ralph

[Marco Moock]

Post by Ralph Aichinger

Post by Marcel Mueller
Diese Verschlüsselung gilt als nicht sonderlich sicher, weil natürlich
an anderen Stellen im System immer irgendwelche Informationen leaken.
Aber das Ziel /home zu verschlüsseln erreicht man damit. Es wird dann
halt jeder einzelne User mit seinem eigenen Key verschlüsselt.

Wenn es nur um /home geht, dann könnte man auch die Lösung von systemd
in Erwägung ziehen, systemd-homed.

Slackware hat kein systemd. :-)

[Friedemann Stoyan]

Post by Ralph Aichinger
Wenn es nur um /home geht, dann könnte man auch die Lösung von systemd
in Erwägung ziehen, systemd-homed.

Kennst Du einen der das verwendet?


mfg Friedemann

[Ralph Aichinger]

Post by Friedemann Stoyan
Kennst Du einen der das verwendet?

Nein, aber es ist auch noch ziemlich neu. Ich hab die Vermutung, dass in
den RedHat-abgeleiteten Distributionen das Standard wird. Ich bin mehr
bei der Debian-Distributionsfamilie zuhause, da kommt das wenn überhaupt
erst später. Mal sehen.

/ralph

[Marc Haber]

Post by Ralph Aichinger

Post by Friedemann Stoyan
Kennst Du einen der das verwendet?

Nein, aber es ist auch noch ziemlich neu. Ich hab die Vermutung, dass in
den RedHat-abgeleiteten Distributionen das Standard wird. Ich bin mehr
bei der Debian-Distributionsfamilie zuhause, da kommt das wenn überhaupt
erst später. Mal sehen.

Ich denke zumindest ernsthaft darüber nach. Ich möchte mir seit fünf
Jahren eine VM im Rchenzentrum bauen, auf der meine Daten abgelegt und
gesichert sind und mit der ich notfalls remote arbeiten kann, egal von
was für einem Terminal aus. Da möchte ich gerne das Homedirectory
automatisch aufschließen wenn ich mich einlogge.

Wenn systemd-homed das kann ohne dass mir selbst was stricken muss
dann nehme ich das, alleine weil es nichts anderes anständiges zu
geben scheint.

Grüße
Marc

[Lutz Falke]

Post by Marc Haber

Post by Ralph Aichinger

Post by Friedemann Stoyan
Kennst Du einen der das verwendet?

Nein, aber es ist auch noch ziemlich neu. Ich hab die Vermutung, dass in
den RedHat-abgeleiteten Distributionen das Standard wird. Ich bin mehr
bei der Debian-Distributionsfamilie zuhause, da kommt das wenn überhaupt
erst später. Mal sehen.

Es gibt auf jeden Fall schon ein Debian-Paket dazu. Kann man
installieren, wenn mans haben will.

Post by Marc Haber
Ich denke zumindest ernsthaft darüber nach. Ich möchte mir seit fünf
Jahren eine VM im Rchenzentrum bauen, auf der meine Daten abgelegt und
gesichert sind und mit der ich notfalls remote arbeiten kann, egal von
was für einem Terminal aus. Da möchte ich gerne das Homedirectory
automatisch aufschließen wenn ich mich einlogge.

Klingt nach einem sinnvollen Anwendungsfall dafür.

Post by Marc Haber
Wenn systemd-homed das kann ohne dass mir selbst was stricken muss
dann nehme ich das, alleine weil es nichts anderes anständiges zu
geben scheint.

Also laut Beschreibung ist das so gedacht. Ich frage mich nur
gerade, wie sich das dann mit PubkeyAuthentication von SSH verträgt.

Ansonsten gibt es noch die Pakete "fscrypt" und "libpam-fscrypt", die
zusammen auch ein Verzeichnis beim Login aufsperren können.

Praktische Erfahrung hab ich damit aber auch nicht, steht auf der "mal
genauer angucken"-Liste.

Lutz

[Marc Haber]

Post by Lutz Falke
Also laut Beschreibung ist das so gedacht. Ich frage mich nur
gerade, wie sich das dann mit PubkeyAuthentication von SSH verträgt.

Das bisher nur in meinem Kopf existierende Konzept verlegt die
authorized_keys Datei mit der AuthorizedKeysFile nach
/etc/sshd/authorized_keys/%u und symlinkt sie dann nach
/home/user/.ssh/authorized_keys.

Grüße
Marc

[Thomas Dorner]

Post by Marc Haber
Das bisher nur in meinem Kopf existierende Konzept verlegt die
authorized_keys Datei mit der AuthorizedKeysFile nach
/etc/sshd/authorized_keys/%u und symlinkt sie dann nach
/home/user/.ssh/authorized_keys.

Akzeptiert ssh denn symlinks für die sicherheitskritischen Dateien?

vgt

[Marc Haber]

Post by Thomas Dorner

Post by Marc Haber
Das bisher nur in meinem Kopf existierende Konzept verlegt die
authorized_keys Datei mit der AuthorizedKeysFile nach
/etc/sshd/authorized_keys/%u und symlinkt sie dann nach
/home/user/.ssh/authorized_keys.

Akzeptiert ssh denn symlinks für die sicherheitskritischen Dateien?

ssh braucht den Symlnk ja nicht, der ist nur damit die Datei dort
steht wo der User sie sucht. Der sshd sucht sie dort, wo die
AuthorizedKeysFile Direktive hinzeigt, und das ist hier auch der
wichtige Punkt denn ~/.ssh ist zu dem Zeitpunkt noch nicht
aufgeschlossen.

Grüße
Marc

[Thomas Dorner]

Post by Marc Haber

Post by Thomas Dorner
Akzeptiert ssh denn symlinks für die sicherheitskritischen Dateien?

ssh braucht den Symlnk ja nicht, der ist nur damit die Datei dort
steht wo der User sie sucht. Der sshd sucht sie dort, wo die
AuthorizedKeysFile Direktive hinzeigt, und das ist hier auch der
wichtige Punkt denn ~/.ssh ist zu dem Zeitpunkt noch nicht
aufgeschlossen.

Stimmt, Danke für die Erklärung.

Viele Grüße, Thomas

[Tim Ritberg]

Post by Marcel Mueller

Post by Marco Moock
Installiertes Slackware auf ner HDD mit 40GB. / belegt davon halt
aktuell alles und /home soll nun doch verschlüsselt werden.

Das könntest du aber auch mit ecryptfs machen. Das kann einzelne Ordner
verschlüsseln.

Das hatte ich mal, das ist Mist, langsam und depricated.
Hab nun ext4 encryption.

Tim

[Marco Moock]

Post by Tim Ritberg
Hab nun ext4 encryption.

Funktioniert das überall mit ext4?

[Tim Ritberg]

Post by Marco Moock

Post by Tim Ritberg
Hab nun ext4 encryption.

Funktioniert das überall mit ext4?

Ich habs fürs Home.

Tim

[Marco Moock]

Post by Tim Ritberg

Post by Marco Moock

Post by Tim Ritberg
Hab nun ext4 encryption.

Funktioniert das überall mit ext4?

Ich habs fürs Home.

Ist unter Slackware leider nicht verfügbar (fscrypt fehlt).
Daher eher weniger praktikabel. :-)

[Sieghard Schicktanz]

Hallo Marco,

Post by Marco Moock

Post by Tim Ritberg
Hab nun ext4 encryption.

...

Post by Marco Moock
Ist unter Slackware leider nicht verfügbar (fscrypt fehlt).
Daher eher weniger praktikabel. :-)

Du nutt nur das Basis-System und nicht die "slackbuilds"-Erweiterungen?

[Marco Moock]

Post by Sieghard Schicktanz
Hallo Marco,

Post by Marco Moock

Post by Tim Ritberg
Hab nun ext4 encryption.

...

Post by Marco Moock
Ist unter Slackware leider nicht verfügbar (fscrypt fehlt).
Daher eher weniger praktikabel. :-)

Du nutt nur das Basis-System und nicht die
"slackbuilds"-Erweiterungen?

fscrypt habe ich da gesucht, fand ich da aber ned.

[Frank Schletz]

Post by Marco Moock

Post by Sieghard Schicktanz
Hallo Marco,

Post by Marco Moock

Post by Tim Ritberg
Hab nun ext4 encryption.

...

Post by Marco Moock
Ist unter Slackware leider nicht verfügbar (fscrypt fehlt).
Daher eher weniger praktikabel. :-)

Du nutt nur das Basis-System und nicht die
"slackbuilds"-Erweiterungen?

fscrypt habe ich da gesucht, fand ich da aber ned.

Hm.
Für gentoo scheint es das wirklich zu geben.
Bei Slackware könnte eCryptfs (ecryptfs-utils) das
equivalent sein. Oder?

[Marco Moock]

Post by Frank Schletz
Bei Slackware könnte eCryptfs (ecryptfs-utils) das
equivalent sein. Oder?

Das ist meines Wissens was völlig anderes.

[Tim Ritberg]

Post by Marco Moock

Post by Frank Schletz
Bei Slackware könnte eCryptfs (ecryptfs-utils) das
equivalent sein. Oder?

Das ist meines Wissens was völlig anderes.

jup, das ist dieses lahme eCryptfs, was einem Ubuntu fürs Home andrehen
wollte.

Tim

[Marco Moock]

Post by Tim Ritberg
jup, das ist dieses lahme eCryptfs, was einem Ubuntu fürs Home
andrehen wollte.

Ist aber schon lange her.

[Frank Schletz]

Post by Tim Ritberg

Post by Marco Moock

Post by Frank Schletz
Bei Slackware könnte eCryptfs (ecryptfs-utils) das
equivalent sein. Oder?

Das ist meines Wissens was völlig anderes.

jup, das ist dieses lahme eCryptfs, was einem Ubuntu fürs Home andrehen
wollte.

Ah, ok.

Frank

[Sieghard Schicktanz]

Hallo Marco,

Post by Marco Moock

Post by Sieghard Schicktanz
Du nutt nur das Basis-System und nicht die
"slackbuilds"-Erweiterungen?

fscrypt habe ich da gesucht, fand ich da aber ned.

Da hab'ich wohl nach dem Falschen gesucht, irgendwo "weiter oben" war auch
vn einem "ecrypt" die Rede, da gibt's was. Wurde der Name "fscrypt"
überhaupt schon explizit erwähnt?

[Marco Moock]

Post by Sieghard Schicktanz

Post by Marco Moock

Post by Sieghard Schicktanz
Du nutt nur das Basis-System und nicht die
"slackbuilds"-Erweiterungen?

fscrypt habe ich da gesucht, fand ich da aber ned.

Da hab'ich wohl nach dem Falschen gesucht, irgendwo "weiter oben" war
auch vn einem "ecrypt" die Rede, da gibt's was.

Ist was anderes und wird nicht mehr weiterentwickelt.

Post by Sieghard Schicktanz
Wurde der Name "fscrypt" überhaupt schon explizit erwähnt?

Ja. Leider kein slackbuild vorhanden.