devDiAl/da-HomeNetDocumentation
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Inital commit

Browse Source
This commit is contained in:
devDiAl
2026-06-19 23:18:04 +02:00
commit 1bb79dc5a5
46 changed files with 3401 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
PI5/Konfiguration/etc/cryptsetup.md
+82
View File
@@ -0,0 +1,82 @@
# cryptsetup – Befehle für LUKS-Container
**Zusammenfassung**: Die wichtigsten `cryptsetup`-Befehle zur Verwaltung von LUKS-verschlüsselten Containern – vom Öffnen und Schließen bis zur Schlüsselverwaltung.
**Quellen**: `chats/fstab und crypttab.md`
**Zuletzt aktualisiert**: 2026-06-16
---
## Übersicht
`cryptsetup` ist das Werkzeug zur Einrichtung und Verwaltung von **dm-crypt** + **LUKS**-Verschlüsselung. Auf dem Raspberry PI5 werden zwei LUKS2-Container verwendet ([crypttab](./crypttab.md)).
## Befehle nach Aufgaben gruppiert
### Container öffnen und schließen
```bash
# LUKS-Container öffnen (entschlüsseln)
sudo cryptsetup luksOpen /dev/sdX3 container_name --key-file /pfad/zur/schluesseldatei.bin
# Beispiel: encrypt_data öffnen
sudo cryptsetup luksOpen /dev/sdb3 encrypt_data --key-file /mnt/usb_key/twotb.bin
# Beispiel: encrypt_sdc3 öffnen
sudo cryptsetup luksOpen /dev/sdc3 encrypt_sdc3 --key-file /mnt/usb_key/onetb.bin
# Container schließen (verschlüsseln)
sudo cryptsetup luksClose container_name
```
### Schlüsselverwaltung
```bash
# Neuen Schlüssel (Key-File) zu einem LUKS-Container hinzufügen
sudo cryptsetup luksAddKey /dev/sdX3 /pfad/neuer-schluessel.bin
# Vorhandene Schlüssel auflisten
sudo cryptsetup luksDump /dev/sdX3
# Schlüssel entfernen
sudo cryptsetup luksRemoveKey /dev/sdX3
```
### Status und Informationen
```bash
# LUKS-Header-Informationen anzeigen
sudo cryptsetup luksDump /dev/sdX3
# Prüfen, ob ein Device LUKS ist
sudo cryptsetup isLuks /dev/sdX3
# Status eines geöffneten Containers anzeigen
sudo cryptsetup status container_name
```
## Schlüsseldatei erstellen
Eine sichere Schlüsseldatei wird mit `/dev/urandom` erzeugt:
```bash
# 4KB zufällige Schlüsseldatei erstellen
sudo dd if=/dev/urandom of=/mnt/usb_key/mein-schluessel.bin bs=4096 count=4
# Berechtigungen setzen (nur root lesen)
sudo chmod 0400 /mnt/usb_key/mein-schluessel.bin
# Schlüssel zu LUKS-Container hinzufügen
sudo cryptsetup luksAddKey /dev/sdX3 /mnt/usb_key/mein-schluessel.bin
```
## Wichtige Hinweise
- `luksAddKey` fragt nach einer **vorhandenen Passphrase oder einem vorhandenen Schlüssel**, bevor der neue hinzugefügt wird.
- Schlüsseldateien sollten **nur von root lesbar** sein (`chmod 0400`).
- Der USB-Stick mit den Schlüsseln muss **physisch sicher** aufbewahrt werden.
## Verwandte Seiten
- [crypttab](./crypttab.md) – Automatisierte Entschlüsselung beim Boot
- [luks-verschluesselung](../luks-verschluesselung.md) – LUKS-Konzepte und Arbeitsweise
- [persistente-blockgeraete](../persistente-blockgeraete.md) – UUID vs. /dev/sdX
PI5/Konfiguration/etc/crypttab.md
+52
View File
@@ -0,0 +1,52 @@
# crypttab – LUKS-Entschlüsselungstabelle
**Zusammenfassung**: Die `/etc/crypttab` steuert, welche LUKS-verschlüsselten Container beim Boot automatisch geöffnet werden. Der Raspberry PI5 verwendet zwei LUKS2-Container, die mit Schlüsseldateien auf einem USB-Stick entsperrt werden.
**Quellen**: `konfigurationsdateien/crypttab`, `chats/fstab und crypttab.md`
**Zuletzt aktualisiert**: 2026-06-16
---
## Aktuelle crypttab
```
# <target name> <source device> <key file> <options>
encrypt_data UUID=097bccad-d77d-48bb-9365-9ca2187cf66b /mnt/usb_key/twotb.bin luks,tries=3,x-systemd.requires=mnt-usb_key.mount,x-systemd.after=mnt-usb_key.mount,x-systemd.device-timeout=15s
encrypt_sdc3 UUID=82550dc2-61f7-415e-8335-0d75c89f9629 /mnt/usb_key/onetb.bin luks,tries=3,x-systemd.requires=mnt-usb_key.mount,x-systemd.after=mnt-usb_key.mount,x-systemd.device-timeout=15s
```
## Spalten erklärt
### 1. Zielname (`<target name>`)
Der Name des gemappten Devices unter `/dev/mapper/`. Wird später in der [fstab](./fstab.md) als `<file system>` verwendet.
- `encrypt_data` → `/dev/mapper/encrypt_data` → wird gemountet als `/mnt/data`
- `encrypt_sdc3` → `/dev/mapper/encrypt_sdc3` → wird gemountet als `/media/piadmin/data`
### 2. Quelldevice (`<source device>`)
Das physische LUKS-Device, identifiziert per **UUID** (persistent und sdX-unabhängig).
- `UUID=097bccad-...` → sdb3 (LUKS-Container für `/mnt/data`)
- `UUID=82550dc2-...` → sdc3 (LUKS-Container für `/media/piadmin/data`)
### 3. Schlüsseldatei (`<key file>`)
Der Pfad zur Datei, die den Entschlüsselungsschlüssel enthält.
- `/mnt/usb_key/twotb.bin` – Schlüssel für `encrypt_data` (2TB-Laufwerk)
- `/mnt/usb_key/onetb.bin` – Schlüssel für `encrypt_sdc3` (1TB-Laufwerk)
**Wichtig**: Der USB-Stick (`/dev/sda1`, gemountet als `/mnt/usb_key`) muss **vor** dem Entschlüsseln verfügbar sein – deshalb die `x-systemd.*`-Optionen (siehe [systemd-cryptsetup](./systemd-cryptsetup.md)).
### 4. Optionen (`<options>`)
- **luks** – LUKS-Modus (Standard für LUKS-Container)
- **tries=3** – Maximale Fehlversuche bei der Entschlüsselung
- **x-systemd.requires=mnt-usb_key.mount** – systemd: Der USB-Key-Mount muss aktiv sein
- **x-systemd.after=mnt-usb_key.mount** – systemd: Erst mounten, dann entschlüsseln
- **x-systemd.device-timeout=15s** – systemd: Zeitlimit für das Warten auf das Device
## Verwandte Seiten
- [fstab](./fstab.md) – Mountet die geöffneten LUKS-Container
- [systemd-cryptsetup](./systemd-cryptsetup.md) – systemd-Boot-Reihenfolge im Detail
- [cryptsetup](./cryptsetup.md) – cryptsetup-Befehle
- [luks-verschluesselung](../luks-verschluesselung.md) – LUKS-Konzepte
- [persistente-blockgeraete](../persistente-blockgeraete.md) – Warum UUID statt /dev/sdX
PI5/Konfiguration/etc/fstab.md
+61
View File
@@ -0,0 +1,61 @@
# fstab – Dateisystemtabelle
**Zusammenfassung**: Die `/etc/fstab` steuert, welche Dateisysteme wo und mit welchen Optionen gemountet werden. Alle Einträge verwenden persistente Referenzen (PARTUUID oder `/dev/mapper/`), um sdX-Vertauschungen zu vermeiden.
**Quellen**: `konfigurationsdateien/fstab`, `chats/fstab und crypttab.md`
**Zuletzt aktualisiert**: 2026-06-16
---
## Aktuelle fstab
```
# <file system> <mount point> <type> <options> <dump> <pass>
PARTUUID=228e9390-01 /boot/firmware vfat defaults,noatime 0 0
PARTUUID=228e9390-02 / ext4 defaults,noatime 0 1
/dev/mapper/encrypt_data /mnt/data ext4 defaults,nofail 0 2
/dev/disk/by-partuuid/83910788-01 /media/piadmin/bootfs vfat defaults,noatime 0 0
/dev/disk/by-partuuid/83910788-02 /media/piadmin/rootfs ext4 defaults,noatime 0 2
/dev/mapper/encrypt_sdc3 /media/piadmin/data ext4 defaults,nofail 0 2
# swap devices handled by systemd/zram (not in fstab)
```
## Spalten erklärt
### 1. Dateisystem (`<file system>`)
- **PARTUUID=...** – Persistente Partition-ID (bleibt gleich, auch wenn sich `/dev/sdX` ändert)
- **/dev/mapper/...** – Gemappter LUKS-Container-Name (von cryptsetup erzeugt)
- **/dev/disk/by-partuuid/...** – Alternativer persistenter Pfad über partuuid
### 2. Mountpunkt (`<mount point>`)
Der Pfad, unter dem das Dateisystem eingehängt wird.
### 3. Dateisystemtyp (`<type>`)
- `vfat` – FAT32 (für Boot-Partition)
- `ext4` – Standard-Linux-Dateisystem (für Root und Daten)
### 4. Mount-Optionen (`<options>`)
- **defaults** – Standard-Optionen (rw, suid, dev, exec, auto, nouser, async)
- **noatime** – Unterdrückt Zugriffszeitstempel, spart Schreibzugriffe
- **nofail** – Boot fährt fort, auch wenn das Device nicht verfügbar ist (wichtig für LUKS-Container, die erst geöffnet werden müssen)
### 5. Dump (`<dump>`)
- `0` – Kein Backup mit dump (immer 0 auf modernen Systemen)
### 6. Pass (`<pass>`)
- `0` – Kein fsck-Durchlauf
- `1` – fsck als erstes (nur Root-Dateisystem)
- `2` – fsck danach (alle anderen)
## Besonderheiten
- **Swap fehlt in der fstab**: Der Raspberry PI5 verwendet **zram** und **loop** für Swap, die von systemd automatisch verwaltet werden. Siehe [swap-zram](../swap-zram.md).
- **FAT32 und fsck**: vfat wird nicht von `fsck.ext4` geprüft – daher `pass 0`.
- **LUKS-Mapper**: `/dev/mapper/encrypt_data` und `/dev/mapper/encrypt_sdc3` werden erst beim Boot durch cryptsetup erzeugt (siehe [crypttab](./crypttab.md)).
## Verwandte Seiten
- [crypttab](./crypttab.md) – LUKS-Entschlüsselungskonfiguration
- [persistente-blockgeraete](../persistente-blockgeraete.md) – UUID, PARTUUID, by-partuuid
- [luks-verschluesselung](../luks-verschluesselung.md) – LUKS-Konzepte
- [sdx-vertauschung](../sdx-vertauschung.md) – Warum persistente Referenzen wichtig sind
- [swap-zram](../swap-zram.md) – Swap-Konfiguration
PI5/Konfiguration/etc/systemd-cryptsetup.md
+86
View File
@@ -0,0 +1,86 @@
# systemd-cryptsetup – Boot-Reihenfolge und Abhängigkeiten
**Zusammenfassung**: systemd steuert die Reihenfolge beim Boot: Zuerst muss der USB-Stick mit den Schlüsseldateien gemountet sein, dann können die LUKS-Container geöffnet werden. Spezielle crypttab-Optionen stellen dies sicher.
**Quellen**: `chats/fstab und crypttab.md`, `konfigurationsdateien/crypttab`
**Zuletzt aktualisiert**: 2026-06-16
---
## Die Herausforderung
Die LUKS-Container auf sdb3 und sdc3 werden mit Schlüsseldateien auf einem USB-Stick (`/dev/sda1`) entsperrt. Beim Boot muss systemd sicherstellen:
1. **USB-Stick mounten** (`/mnt/usb_key`)
2. **Dann erst** die LUKS-Container öffnen (Schlüsseldatei liegt auf dem USB-Stick)
3. **Dann** die Dateisysteme mounten (siehe [fstab](./fstab.md))
## Lösung: systemd-Optionen in der crypttab
Die crypttab-Einträge enthalten systemd-spezifische Optionen:
```
encrypt_data UUID=097bccad-... /mnt/usb_key/twotb.bin luks,tries=3,\
x-systemd.requires=mnt-usb_key.mount,\
x-systemd.after=mnt-usb_key.mount,\
x-systemd.device-timeout=15s
```
### Optionen im Detail
| Option | Wirkung |
|---|---|
| `x-systemd.requires=mnt-usb_key.mount` | Stellt sicher, dass der USB-Key-Mount **aktiv** ist, bevor der LUKS-Container geöffnet wird. Schlägt der Mount fehl, wird auch der Container nicht geöffnet. |
| `x-systemd.after=mnt-usb_key.mount` | Legt die **Reihenfolge** fest: Der USB-Key-Mount muss **vor** dem Container-Öffnen gestartet werden. |
| `x-systemd.device-timeout=15s` | systemd wartet maximal 15 Sekunden auf das Device (falls der USB-Stick langsam initialisiert). |
| `tries=3` | Maximale Anzahl an Fehlversuchen bei der Entschlüsselung. |
### Wie der Unit-Name zustande kommt
Der systemd-Mount-Name folgt einer festen Konvention: Pfade werden mit `-` statt `/` und `.mount` als Suffix geschrieben.
- `/mnt/usb_key` → `mnt-usb_key.mount`
- `/mnt/data` → `mnt-data.mount`
## Ablauf beim Boot
```
USB-Stick wird erkannt (udev)
│
▼
mnt-usb_key.mount (systemd mount unit)
│
├── x-systemd.requires ──┐
├── x-systemd.after ─────┤
│ ▼
│ systemd-cryptsetup@encrypt_data.service
│ systemd-cryptsetup@encrypt_sdc3.service
│ │
│ ▼
│ /dev/mapper/encrypt_data ← verfügbar
│ /dev/mapper/encrypt_sdc3 ← verfügbar
│
▼
mnt-data.mount (aus /etc/fstab)
media-piadmin-data.mount (aus /etc/fstab)
```
## Fehlerbehebung
```bash
# Status des Container-Öffnens prüfen
journalctl -b -u systemd-cryptsetup@encrypt_data.service -e
journalctl -b -u systemd-cryptsetup@encrypt_sdc3.service -e
# Prüfen, ob der USB-Stick gemountet ist
lsblk /dev/sda
mount | grep usb_key
# systemd-Abhängigkeiten visualisieren
systemctl list-dependencies mnt-data.mount
```
## Verwandte Seiten
- [crypttab](./crypttab.md) – Die crypttab-Konfiguration
- [fstab](./fstab.md) – Mountet die geöffneten Container
- [cryptsetup](./cryptsetup.md) – Manuelle cryptsetup-Befehle