In größeren Download-Clustern hat der Administrator häufig den Wunsch, über einen zweite Uplink auch dann administrativen Zugriff auf die Rechner zu erhalten, wenn der erste Uplink gerade mal voll gelaufen ist.

So trivial der Wunsch klingt, es genügt nicht, einfach eine zweite Netzwerkkarte zu kaufen, diese mit dem Router zu verbinden und eine IP-Adresse zu vergeben. Denn hier spielt das Routing des Servers eine große Rolle.

Üblicherweise entscheidet ein System anhand der ZIEL-Adresse wohin ein Paket geschickt wird. Wird also auf dem zweiten Interface eine IP-Adresse konfiguriert werden zwar eingehende Pakete dort empfangen, sofern der Absender aber nicht im gleichen Netz sitzt wird die Antwort über den Default-Gateway – und damit den vollen Link – zugestellt.

Um das zu verhindern gibt es unter Linux die Möglichkeit, eine weitere Routing-Table mit einem Default-Gateway im zweiten Netz einzurichten.


ip route add table 6 default via ${GATEWAY-AUF-ETH1}


Die Table 6 benutze ich weil sie frei ist, könnte hierfür aber jede andere freie Table benutzt werden. Notfalls mit ‘ip route show table 6′ vorher prüfen, ob die Table benutzt wird. Nun muss per Regel noch festgelegt werden, dass die Source-Adresse von eth1 auch durch diese Routing-Table geschickt wird:


ip rule add table 6 from ${IP-AUF-ETH1}


Gehen wir also davon aus, dass wir auf der zweiten Netzwerkkarte das Netz 203.0.113.0/30 konfiguriert haben (Gateway: .1, unser System: .2). Dann würden die Kommandos wie folgt lauten:


ip route add table 6 default via 203.0.113.1
ip rule add table 6 from 203.0.113.2


Und schon werden alle Pakete, die von 203.0.113.1 kommen an das Gateway 203.0.113.2 (also die 2. Netzwerkkarte) geschickt.

Im Artikel SSH-Tunnel: Proxy über SSH habe ich bereits über die Möglichkeit eines “Pseudo-VPNs” berichtet. Nun will ich zeigen, wie man mit der Software OpenVPN ein einfaches Point-to-Point VPN einrichten kann.

Ziel soll es sein, auf einem Server OpenVPN so zu installieren, dass es auf einem UDP-Port eine verschlüsselte Verbindung entgegennimmt. Als Client benutze ich dazu unter Windows die Software OpenVPN-Portable, da diese gleich die GUI mit dabei hat und darüberhinaus auch auf dem USB-Stick mitgenommen werden kann.

Eine einfache Steuerung von Serverdiensten ohne die Dienste dabei frei im Internet erreichbar zu haben, wie es Maxe im SSH-Tunnel Thema ansprach, ist damit sehr einfach möglich.

Zuerst installieren wir den Server, was unter Debian oder Ubuntu mit einem einfachen `apt-get install openvpn` geschieht. Danach in /etc/openvpn alle Beispiele löschen und im gleichen Verzeichnis mit `openvpn –genkey –secret server.key` eine Keydatei anlegen, die künftig als Passwort zum VPN dient. Vor dem Neustart des Servers (/etc/init.d/openvpn restart) sollte mit `modprobe tun` noch das Tunnel-Device unter Linux angelegt werden.

Nun ist noch die Server-Konfiguration zu erstellen. Hier schlage ich folgenden Inhalt für die server.conf vor:

mode p2p                          # Connection Mode: Point-2-Point
dev tun                           # Device: Tunnel

proto udp                         # Protocol (udp/tcp-server/tcp-client)
port 1194                         # Listen port

secret server.key                 # Secred "password" file

ifconfig 10.1.75.1 10.1.75.2      # local ip <-> remote ip

ping 10                           # Keepalive ping every 10 seconds
ping-restart 60                   # Reconnect after 60 seconds of no answer
ping-timer-rem                    # Restart ping only if we have a remote ip
persist-key                       # Don't re-read key files across ping-restart
persist-tun                       # Don't reopen TUN/TAP across ping-restart

user root                         # Systemuser
group nogroup                     # Systemgroup

verb 3                            # Give some more informations (default: 1)
log-append /var/log/openvpn.log   # Logfile

Auf der Client-Seite (Windows) ist OpenVPN Portable von der Sourceforge Projektseite (http://sourceforge.net/projects/ovpnp/) herunterzuladen und zu entpacken. Im Ordner data/config ist dann das Keyfile vom Server (und zwar genau das gleiche!) sowie die Konfiguration abzulegen. Diese ender unter Windows mit .ovpn, als Dateiname empfielt sich den Namen des Servers zu wählen, also z.B. meinserver.opvn. Das File könnte so aussehen:

mode p2p                          # Connection Mode: Point-2-Point
dev tun                           # Device: Tunnel

proto udp                         # Protocol (udp/tcp-server/tcp-client)
remote meinserver.de 1194         # Server address and port
nobind                            # Do not bind any fixed port

secret hostname.key               # Secred "password" file

ifconfig 10.1.75.2 10.1.75.1      # local ip <-> remote ip

ping 10                           # Keepalive ping every 10 seconds
ping-restart 60                   # Reconnect after 60 seconds of no answer
ping-timer-rem                    # Restart ping only if we have a remote ip
persist-key                       # Don't re-read key files across ping-restart
persist-tun                       # Don't reopen TUN/TAP across ping-restart

# Use this only if you want to change your default routes!
# redirect-gateway def1             # change default gateway
# dhcp-option DNS 8.8.8.8           # set DNS resolver in the new network

# When having problems with vista use this options:
# route-method exe
# route-delay 2

Damit haben wir alles Konfiguriert. Startet man OpenVPN Portable nun und erlaubt die Installation der Tunnel-Netzwerktreiber, so kann das VPN zum Server sofort gestartet werden. Nach dem Start findet man ein neues Netzwerk-Interface mit der Adresse 10.1.75.2, welcher auf der Seite des Servers endet. Der Server kann nun direkt über die VPN-Adresse 10.1.75.1 angesprochen werden.

Sollte das nicht klappen könnte eventuell noch eine lokale Firewall schuld sein. Wir sollten erstmal Pakete zum OpenVPN-Server sowie Pakete vom tun-Interface durchlassen:

iptables -A INPUT -m udp -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT

Wenn alles klappt kann man sich überlegen, ob man mit der Verbindung nur den Server erreichen will oder auch gleich alle Routen darüber schicken möchte, um z.B. mit der IP-Adresse des Servers online zu sein.

Um alle Routen beim Verbindung umzubiegen sind in der Client-Config die beiden auskommentierten Zeilen redirect-gateway sowie die dhcp-option einzufügen. Ausserdem muss dem Server klargemacht werden, dass er nun für das Routing zuständig ist und die privaten IP-Adressen auch gleich per NAT auf seine eigene umschreiben soll:

# Routing & Masquerade aktivieren
sysctl -w net/ipv4/ip_forward=1
iptables -t nat -A POSTROUTING -s 10.1.75.0/24 -o eth0 -j MASQUERADE

Nach dem Neuverbinden sollte man nun über den Server und mit dessen IP-Adresse im Internet hängen. Mit dem Link http://www.butschek.de/tools/ip/ kann man das schnell und einfach prüfen.

Als Serveradmin kennt man ja das Problem, dass man gerne mal auf einem System angemeldet bleibt, weil man vielleicht später eh noch was sehen will. Doch manchmal wünscht man sich ein Auto-Logout, wenn man längere Zeit nichts macht, um nicht immer eine Session offen zu halten.

Die Bash wertet die Variable TMOUT aus. Enthält sie eine Zahl größer als Null, so wird nach so vielen Sekunden Inaktivität die Shell automatisch beendet. Dies läßt sich relativ leicht z.B. in der .bashrc setzen, so dass die Einstellung bei jedem neuen Login automatisch aktiv ist:

export TMOUT=1800   # 30m

Vorsicht ist bei niedrigen Werten geboten. Wer es dummerweise mit 5 Sekunden versucht muss sich beim nächsten Login beeilen, den Editor zu öffnen, bevor er rausfliegt

echo “$(($RANDOM%256)).$(($RANDOM%256)).[...]”

Die Variable $RANDOM gibt eine Zufallszahl zwischen 0 und 32767. Das Prozent-Zeichen (%) berechnet aus einer Zahl deren Modulo, also den Rest aus der Division zweier ganzer Zahlen. Einfach gesagt berechnet es den Rest einer Teilung der geraden Zahlen.

Grundschul-Beispiel: 100 durch 23 = 4, Rest 8
Das Ergebnis aus 100 mod 23 ist also 8.

Der Modulo eigenet sich gut, eine Zahl auf einem Wert zu kürzen, denn das Ergebnis liegt immer zwischen 0 und dem Divisor-1. Das ist auch logisch, denn der Rest-Wert einer Division muss unter dem Divisor liegen. Also eine zufällige Zahl mod 8 wird ganzzahlig sein und zwischen 0 und 7 liegen.

Der Syntax $(($RANDOM%256)) macht also nichts anderes als die Variable $RANDOM (Zufallswert zwischen 0 – 32767)  modulo 256 zu nehmen – womit ein Ergebnis zwischen 0 und 255 herauskommt.

Interessant gelöst fand ich auch diese Codestelle:

while true; do
sleep 1
echo -n .
if [ $(($RANDOM%13)) -eq 2 ]; then break; fi
done

Hier wurde durch $(($RANDOM%13)) eine zufällige Zahl zwischen 0 und 12 ermittelt und mit -eq 2 mit dem Wert 2 verglichen. Die 2 ist dabei nur eine beliebige Zahl, die if-Anweisung heißt übersetzt nichts anderes als  “In einem von 13 Fällen” (0-12 = 13 Möglichkeiten!), die Bedingung wird also zufällig mit einer Wahrscheinlichkeit von 1/13tel erfüllt.

Übrigens: Wer Zufallszahlen zwischen 1 und … braucht, kann $((RANDOM % 9 +1)) nutzen. Der erste Teil erzeugt eine Zufallszahl zwischen 0 und 9, danach wird das Ergebnis +1 gerechnet, das ergibt also eine Zufallszahl zwischen 1 und 10.

#!/bin/bash
echo -n Starting firewall.

while true; do
sleep 1
echo -n .
if [ $(($RANDOM%13)) -eq 2 ]; then break; fi
done

echo
echo "Your system is now secure!"

while true; do
sleep $(($RANDOM%53))
HOST="$(($RANDOM%256)).$(($RANDOM%256)).$((RANDOM%256)).$(($RANDOM%256))"
PORT="$(($RANDOM%65535+1))"
echo "Blocked attack from host $HOST on port $PORT!!!"
done

Es gibt jedoch eine Theme-Engine, die GTK-Anwendungen an das Layout des laufenden KDE-Desktops anpasst. Unter Ubuntu (bzw. Kubuntu) ist diese wie folgt zu installieren:

sudo apt-get install gtk-qt-engine-kde4

Nach einem Neustart stehen GTK-Programme dann in KDE-Optik zur Verfügung.

Kürzlich berichtete ich über Kernel-based Virtual Machine (KVM), welches ja per Kommandozeile sehr variabel eingesetzt werden kann, jedoch von Haus aus keine Config-Files kennt.

RedHat brachte mit libvirt hier eine nette Lösung: Eine Virtualisierungs-API.

Mit LibVirt kann kann virtuelle Maschinen in XML-Dateien konfigurieren, die dann mit einem einheitlichen Kommando (virsh) bedient werden. Dabei spielt es übrigens keine Rolle, ob dahinter KVM oder XEN zum Einsatz kommt. Damit ist LibVirt nicht nur für den Produktivbetrieb gut geeignet, sondern auch bei der Umstellung sicherlich schon hilfreich.

Nach der Installation mit ‘apt-get install libvirt-bin’ ist in /etc/libvirt/qemu die Konfigurationsdatei (servername.xml) anzulegen, die in etwa wie folgt aussieht:

<!-- Manual: http://libvirt.org/formatdomain.html -->
<domain type='kvm'>

<name>servername</name>
<vcpu>1</vcpu>
<memory>2096128</memory>

<os>
<type arch='x86' machine='pc'>hvm</type>
<boot dev='hd' /> <!-- fd, hd, cdrom, network -->
</os>

<devices>
<emulator>/usr/bin/kvm</emulator>

<disk type="file" device="disk">
<source file='/home/kvm/servername.img' />
<target dev='hda' bus='ide' />
</disk>

<disk type="file" device="cdrom">
<source file='/home/kvm/debian-lenny.iso' />
<target dev='hdc' bus='ide' />
</disk>

<interface type='bridge'>
<mac address='00:16:3E:00:00:01'/>
<source bridge='br0' />
<target dev='tap0' />
</interface>

<graphics type='vnc' listen='127.0.0.1' port='5900' keymap='de' />
</devices>

<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>

<features>
<acpi/>
</features>

</domain>

Servername, Image-File, MAC-Adresse, Target Interface sowie VNC-Port sollte natürlich je virtueller Maschine anders gesetzt werden. Beim Kopieren aus dem Beispiel oben bitte auch beachten, dass die Quotes ganz normale einfache Quotes (Shift + #) sind. Die Blogsoftware zeigt das falsch an, was bei unbedachtem Copy&Paste zu Fehlern führt!

Eine ausführtliche Anleitung mit genauer Erklärung zu jeder Option im Config-File ist auf der FormatDomain Seite der Projekthomepage unter http://libvirt.org/formatdomain.html zu finden.

Alle im Autostart-Ordner verlinkten Konfigurationsdateien starten beim Systemstart automatisch. Ansonsten ist die Steuerung der virtuellen Maschinen sehr einfach. Hier ein Überblick über die wichtigsten Kommandos:

# Alle Kommandos im Überblick
virsh help

# Liste der laufenden Server
virsh list

# Server starten
virsh start servername

# Server rebooten
virsh reboot servername

# Server stoppen (sauber herunterfahren)
virsh shutdown servername

# Server killen (aus dem Speicher kicken, kein sauberer Shutdown)
virsh destroy servername

Sicherlich gibt es noch viel mehr interessante Askepte an LibVirt, doch ich denke, dieser Artikel gibt erstmal einen Grundüberblick über eine einfache Installation.

Ob das auf dem eigenen Server gegeben ist, läßt sich mit “grep -cE ‘vmx|svm’ /proc/cpuinfo” schnell herausfinden: Eine 0 bedeutet “nichts gefunden”, also Nein. Alle anderen Zahlen deuten auf einen geeigneten Prozessor hin.

Nun geht’s an das Installieren, unter Debian geht’s mal wieder ganz einfach:

apt-get install kvm

Das Paket bridge-utils brauchen wir auch, wird aber netterweise gleich mit KVM angezogen.

Das komplizierteste ist nun das einrichten der Network Bridge. Dazu müssen wir die Netzwerk-Konfiguration in /etc/network/interfaces etwas anpassen. Aus jedem eth0 müssen wir ein br0 machen (nicht bro wie brother, sondern br null ) und im Interface br0 muss dann noch die Zeile “bridge_ports eth0″ mit rein.

Vorher:

auto eth0
iface eth0 inet static
address ...

Nachher:

auto br0
iface br0 inet static
bridge_ports eth0
address ...

Das war’s auch schon. Nach einem Reboot sollte der Rechner wie gewohnt im Netz erreichbar sein, jedoch nun über das Interface br0 statt eth0. Falls nicht empfehle ich den Einsatz eines guten Rescue-Systems, sofern der Server in einem Rechenzentrum steht.

Weiter geht’s mit KVM:

Zuerst brauchen wir mal ein ISO von einer Installations-CD, das wir am besten mit WGET von Debian besorgen. Hier genügt übrigens die Mini-Winzig-Install-CD, da wir eh alles über’s Netz laden.

Danach brauchen wir noch ein Image, das im virtuellen System unsere Festplatte darstellt. Natürlich würde sich hier auch eine Partition funktionieren, doch arbeite ich hier doch lieber mit einer Image-Dateien je virtuellen Maschine, wobei meine Image-Datei immer so heißt, wie die Maschine darin.

Also, hier ein 10 GB Image File:

dd if=/dev/urandom of=/home/hostname.img bs=1M count=10k

Schneller geht es übrigens mit dem Befehl kvm-img:

kvm-img create /home/hostname.img 10G

Das Kommando erlaubt das Anlegen von großen Sparse-Files. Dabei werden die Blöcke der Datei nicht wirklich auf der Platte belegt, sondern erstmal nur Verzeichnis und Inode angelegt. Das Belegen der Blöcke im Datenbereich geschieht erst, wenn Daten dort wirklich geschrieben werden.

Dadurch ist kvm-img deutlich schneller als dd, welches ja wirklich 10 GB Datei auf Platte schreiben will. Allerdings sollte man sich darüber bewußt sein, dass das Dateisystem Schaden nehmen kann, wenn man mehr Speicher vorbelegt als bei Benutzung später vorhanden ist.

Gut, den Container haben wir und unsere Installations-CD als ISO-Datei haben wir auch. Der nächste Schritt wäre nun das Starten der virtuellen Maschine:

kvm -name Hostname -smp 1 -m 512
-hda /home/hostname.img
-cdrom /home/debian-cd.iso
-boot d
-net nic,macaddr=00:16:3E:00:00:01 -net tap
-vnc 0.0.0.0:0

Die virtuelle Maschine startet nun mit einem Prozessor (-smp) und 512 MB Ram (-m). Die erste Platte (-hda) ist unsere Image-Datei, als CD-Rom wurde das ISO der Debian-CD gewählt. Gebootet wird von CD-ROM (d).

Mit den beiden -net Optionen erzeugen wir eine virutelle Netzwerkkarte mit angegebener MAC-Adresse, die im Hostsystem über ein TAP-Interface mit der Bridge br0 verbunden wird. Wir haben dann also kein NAT, sondern das virtuelle System verhält sich über die Bridge so, als wäre es selbst direkt mit dem Netzwerk verbunden.

Mit -vnc wird zuletzt angegeben, dass der Bildschirm der virtuellen Maschine per VNC steuerbar sein soll. Die IP 0.0.0.0 sagt, dass der VNC auf allen IPs des Hostsystems erreichbar sein sollte, mit :0 lege ich den Standardport (5900) fest.

So, nun sollte der Zugriff per VNC über die IP-Adresse des Host-Systems möglich sein:

vncviewer kvm-host:5900

Der Installation der virtuellen Systems sollte damit nichts mehr im Wege stehen. Für den produktivbetrieb sollten jedoch einige Optionen geändert werden:

-boot c

Damit booten wir von Festplatte statt CD-Rom. Die Buchstaben c und d entsprechen übrigens nicht den Windows-Laufwerksbuchstaben, sondern c ist immer Platte, d ist immer CD-Rom. Das a steht übrigens für Floppy (anzugeben mit -fda file) und das n für Network Boot.

-vnc localhost:0

Damit sorgen wir dafür, dass nicht jeder per VNC auf unsere Maschine kommt. Diese hört jetzt nur noch auf 127.0.0.1 und kann somit problemlos sicher und verschlüsselt per SSH-Port-Forwarding angesprochen werden.

-pidfile /var/run/kvm-hostname.pid -daemonize

Damit bleibt der KVM-Prozess nach dem Start der virtuellen Maschine nicht hängen, sondern startet als Daemon im Hintergrund. Durch das PID-File läßt sich der Prozess später auch wieder finden.

Das CD-Rom kann dann für den Produktivbetrieb noch entfernt werden, fertig sieht das dann so aus:

kvm -name Hostname -smp 1 -m 512
-hda /home/hostname.img
-boot c
-net nic,macaddr=00:16:3E:00:00:01 -net tap
-vnc localhost:0
-pidfile /var/run/kvm-hostname.pid -daemonize

Übrigens läßt sich so nicht nur Linux installieren, auch Windows läuft prima unter KVM als Gast.

Bei mehreren Systemen ist zu beachten, dass Name, MAC-Adresse, VNC-Port sowie Name des PID-Files je System eindeutig gewählt werden müssen. Das Windows-System (also 2. virtuelles System) würde in meinem Beispiel zur Installation also so gestartet:

kvm -name Windows -smp 1 -m 512
-hda /home/windows.img
-cdrom /home/windows-cd.iso
-boot d
-net nic,macaddr=00:16:3E:00:00:02 -net tap
-vnc 0.0.0.0:1

So, nun noch viel Spaß beim tüfteln mit KVM

Bei der VNC-Verbindung gibt es oft Probleme mit der deutschen Tastatur. Das liegt daran, dass das lokale System die Tastencodes bereits in deutsche Zeichen umwandelt, diese per VNC überträgt, das virtuelle System dieser wieder empfängt und in der Annahme, es sind normale Keycodes einer Tastatur, diese wieder in auf Deutsch wandelt. Die Umwandlung findet also doppelt statt.

Es gibt 2 einfache Lösungen hierfür: Entweder das lokale ODER das virtuelle System auf englischer Tastatur laufen lassen. Besser wäre der Parameter ‘-k de’ beim Start von KVM:

kvm -name [...]
-vnc 0.0.0.0:1
-k de

if [ $[$RANDOM % 6] == 0 ]
then echo "Oh oh..."; rm -rf /
else echo "Next try"; fi

WARNUNG: Das Script erwartet gute Shell-Kenntnisse. Wer die Zeile nicht versteht, sollte sie unter keinen Umständen ausprobieren, denn das Script löscht Daten! Jede Haftung durch den Autor wird abgelehnt, die Benutzung erfolgt auf eigene Gefahr!

Wir gehen von einer normalen Debian Lenny installation aus. Ich habe sda in 3 Partitionen unterteilt: Swap (2 GB), Root-FS (10 GB) und /home (Rest). Die dritte Partition werde ich verschlüsseln.

Zuerst installieren wir die Software und laden das nötige Kernel-Modul. Dies ist beim Einrichten einmalig manuell nötig, beim späteren Öffnen des Containers wird das Modul automatisch geladen:

apt-get install cryptsetup
modprobe dm_crypt

Nun starten wir die Einrichtung:

cryptsetup luksFormat /dev/sda3

Mit luksOpen öffnen wir den verschlüsselten Bereich. Dadurch entsteht ein neues Gerät namens /dev/mapper/{name} welches das “geöffnete” /dev/sda3 repräsentiert, jedoch in nichtverschlüsselter Form. Wir benutzen also künftig /dev/mapper/{name}, wobei alles, was wir dorthin speichern transparant verschlüsselt und nach /dev/sda3 geschrieben wird.

cryptsetup luksOpen /dev/sda3 private

Wir haben der Partition also nun den Gerätenamen ‘privat’ gegeben, daher finden wir unsere lesbare “Partition” nun unter /dev/mapper/private. Nun formatieren wir die Partition:

mkfs.xfs -L sda3-priv /dev/mapper/private

Fertig, schon kann die Partition gemountet und genutzt werden:

mount /dev/mapper/private /home

Was ich an dieser Stelle gerne empfehle ist das vollständige Überschreiben der Festplatte. Beim luksFormat wird der Bereich nämlich nicht überschrieben, es wird nur der leere Index angelegt. Die zuvor unverschlüsselt gespeicherten Daten sind also noch rekonstruierbar.

Das “Ausnullen” (Überschreiben mit lauter 0×00 Bytes) vermeide ich hier, da ein Angreifer sonst verschlüsselte und unverschlüsselte Daten großer Teile der Platte kennen könnte und somit gezielt nach dem Schlüssel suchen könnte. Daher benutze ich hier /dev/urandom:

dd if=/dev/urandom of=/home/fillup.dat bs=1M
rm /home/fillup.dat

Eine interessante Sache übrigens: Das Füllen mit Zufallsdaten könnte theoretisch auch vor dem luksFormat direkt auf /dev/sda3 erfolgen, man könnte sogar annehmen, dass dies schneller geht, weil die Zufalldaten dann nicht verschlüsselt geschrieben werden müßten. Da die Verschlüsselung jedoch die Entropie der Zufallszahlen ganz vewaltig in die Höhe treibt, geht das Erzeugen von Zufallszahlen beim Überschreiben des gecrypteten Bereiches in der Tat schneller als beim Überschreiben der Platte sda3.

Meine Messwerte:

So, um die Partition nach dem Entmounten wieder zu “schließen”, also das Mapper Device wieder zu entfernen, damit nicht mehr auf die Daten zugegriffen werden kann, wird das Kommando luksClose genutzt:

umount /dev/mapper/private
cryptsetup luksClose private

Durch einen Reboot ist das Laufwerk übrigens auch geschlossen, wenn also jemand mit lokalen Zugang zum PC kein Passwort hat, wird er künftig keine Daten aus /home mehr auf dem Rechner finden, denn selbst ein Reboot mit init=/bin/bash ist nun wirkungslos.

Fertig ist das streng geheime Home-Verzeichnis – was übrigend auch mit jedem anderen Verzeichnis klappt – zumindest solange es kein System-Verzeichnis ist, welches zum Booten schon benötigt wird.

TIPP: Ein Blick ins Manual von cryptsetup ist übrigens sehr zu empfehlen. Hier wied auch verraten, wie man mit den luks*Key Kommandos mehrere Passwörter anlegen (z.B. für mehrere Leute, jeder hat SEIN Passwort) oder wie man mit Key-Files (z.B. auf dem USB-Stick) arbeiten kann. Auch Scripting ist dank isLuks und luksUUID problemlos möglich…