LUKS: Wie man einen Cloud-Container erstellt.

Wer kennt das Bedürfnis nach Synchronisation des Dateibestandes von verschiedenen Geräten über einen Cloudanbieter aka Webhoster nicht? Ok, Ihr könnt jetzt zur nächsten OSBN News wechseln, außer Ihr möchtet an einem Zweitstandort eine sicher aufgehobene Kopie Eurer Daten haben, auf die nur Ihr Zugriff habt, dann lest jetzt weiter …

LUKS: Wie man einen Cloud-Container erstellt.

Verschlüsselungssysteme gibt es ja viele, aber nicht alle sind bei jeder Distro onboard und osübergreifend verfügbar, LUKS schon. Deswegen heute ein kleiner Beitrag wie man seine Daten bei einem Webhoster so parkt, daß man sie von überall aus einbinden kann.

ACHTUNG: Bei einer Cloud-Container-Lösung auf Basis von Luks oder Truecrypt darf nur ein PC das System aktiv einbinden, sonst Datenverlust! Möglich ist aber ein READ-ONLY-Einbinden mehrerer Rechner gleichzeitig. Ich warne ausdrücklich davor so etwas zu versuchen und es dann zu versemmeln!

Der Hintergrund für die Warnung ist ganz einfach der, daß Eurer PC der Meinung ist, daß er den Datenträger exklusiv hat und daher Sachen im RAM vorhält, die nicht auf den Datenträger synchronisiert sind um die Leistung zu steigern. Wenn zwei Rechner das machen und dann vermeidliche freie, aber vom anderen PC schon im RAM anvisierte Blöcke beschreibt, kommt es unweigerlich zum Datenverlust. Wer schon einmal mit SSHFS gearbeitet hat, das einen entfernten PC als Laufwerk einmountet, der wird bemerken, daß da keine lokale Pufferung stattfindet, weil der PC hier nicht wissen kann, ob und wer sonst noch so auf die Datenquelle zugegriffen hat. SSH greift auf der  anderen Seite auch nicht als Filesystem, sondern über die OS API auf Dateien zu und simuliert Euch nur ein Laufwerk.

Anders ist das, wenn zwar der Container per SSHFS verfügbar gemacht wird, aber das Einbinden des entschlüsselten Filesystems dann lokal stattfindet. Das findet dann wieder mit den OS eigenen IO-Steigerungsamethoden statt. Beim Mounten von Datenträgern kann man über die Mount-Options noch einiges abändern, da geht vielleicht sogar was, aber empfehlen kann ich das definitiv nicht.

Die Ausgangslage

Wir behandeln daher einen PC der auf einen Webserver zugreift, dort seinen Container lagert und die ganze Ent- und Verschlüsselung auf dem eigenen PC auflaufen lässt.

Wir brauchen: CryptSetup, einen Webserver, schnelles Internet ( ist von Vorteil )

Der Webserver

Der Webserver muß eine der folgenden Anbindungen unterstützen: SSH, SAMBA oder NFS und zwar genau in der Reihenfolge sollte man das auswählen. Für diesen Artikel nehme ich SSH, da das auf jedem LinuxPC vorhanden ist und der Transportweg so zusätzlich verschlüsselt ist. Da sieht man dann auch nicht, was da eigentlich auf dem Webserver gemacht wird.

Samba ist zwar mittlerweile auch im Datentransport verschlüsselt, aber viele Router halten das auf, damit die Windowskisten nicht das Providernetz vollspammen, die sind sehr mitteilungsbedürftig 😉

NFS kennt keine Authentifizierung außer IPs, ist unverschlüsselt und ist im allgemeinen bestenfalls zwischen Servern einzusetzen.

Das PRE-SETUP

Wir machen das alles als ROOT, weil CryptSetup und mount das gern so möchten. Da hier FUSE nur sekundär im Einsatz ist, weil es sich um normale Filesysteme des Kernels handelt (kommt gleich),  kommt mount zum Einsatz, welches zwingend als ROOT laufen möchte. Das Ergebnis der Aktion kann aber dann von jedem User benutzt werden. Wenn man sich da nicht besonders blöd im Rechtemanagement anstellt, dann ist das auch auf einem Mehrbenutzersystem kein Problem.  Kommen wir zu …

Schritt 1: Einen Mountpoint für den Container erstellen

mkdir -p /media/container/server

Der Ort ist in der Regel für jeden Benutzer erreichbar, was z.b. beim Mounten im eigenen Home nur für den aktuellen Benutzer gelten würde.

Schritt 2: Der Server als Laufwerk einbinden

sshfs demo@meine.demo.de:/home/demo /media/container/server -o allow_other

Je nachdem was man als Authmechnismus eingestellt hat ( KEY oder PASSWORD )  macht da der SSH-AGENT, der hoffentlich in irgendeiner Form bei Euch läuft ( gpg-agent, ssh-agent, gnome-keyring-daemon ) das mit dem Schlüssel automatisch für Euch, oder Ihr müßt ein Passwort eingeben.

Schritt 3: Das Containerfile anlegen

Hier im Beispiel benutze ich jetzt ein 100MB File ( 1M * 100 ) :

# dd if=/dev/zero of=/media/container/server/container.luks bs=1M count=100
100+0 Datensätze ein
100+0 Datensätze aus
104857600 bytes (105 MB, 100 MiB) copied, 29,0354 s, 3,6 MB/s

Wer da übers Netz GBweise Dateien anlegt, der sollte sich fragen, ob er verstanden hat, was er da gerade tut, denn das dauert Stunden und man könnte es ja auch auf dem Webserver erledigen lassen, daß dauert nur Sekunden, denn noch ist da weder Crypto noch ein Filesystem dran beteiligt, es wird nur ein BLOCK mit NULLEN erzeugt.

Schritt 4: Den Container mit LUKS formatieren

Der nächste Schritt sollte allerdings zwingend vom PC aus erledigt werden, da dazu ein Passwort nötig ist, welches, solange der Vorgang dauert, auch im Speicher des Webservers verfügbar wäre, würde man es dort tun. Das Formatieren dauert dann auch ein gutes Weilchen.

# cryptsetup -y luksFormat /media/container/server/container.luks

WARNING!
========
Hiermit werden die Daten auf »/media/container/server/container.luks« unwiderruflich überschrieben.

Are you sure? (Type ‚yes‘ in capital letters): YES
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************
Passphrase bestätigen: ***********************

Ein sinnvoll langes Passwort > 20 Zeichen ist angeraten! Es sollte nicht 123456789… lauten 😉

Schritt 5: Den Container öffnen und zum Mounten bereitstellen

Dieser Schritt geht dann recht zügig von statten. Ihr müßt nicht zwangsweise den gleichen Cryptocontainernamen benutzen wie ich, da seid Ihr flexibel.

# cryptsetup luksOpen /media/container/server/container.luks cryptocontainer
Geben Sie die Passphrase für »/media/container/server/container.luks« ein: ***********************

Schritt 6: Das Filesystem erstellen

Beim ersten mal muß man jetzt das Filesystem einrichten:

# mkfs.ext4 -j /dev/mapper/cryptocontainer
mke2fs 1.45.5 (07-Jan-2020)
Ein Dateisystem mit 86016 (1k) Blöcken und 21560 Inodes wird erzeugt.
UUID des Dateisystems: bcbccb1b-794e-4700-bd64-cd021a42bf32
Superblock-Sicherungskopien gespeichert in den Blöcken:
8193, 24577, 40961, 57345, 73729

beim Anfordern von Speicher für die Gruppentabellen: erledigt
Inode-Tabellen werden geschrieben: erledigt
Das Journal (4096 Blöcke) wird angelegt: erledigt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden geschrieben: erledigt

ich habe jetzt EXT4 ausgewählt, weil das in jedem Kernel vorkommt und als Journalingfilesystem keine ellenlangen Reparaturen vor dem Mounten braucht, was gerade bei einem Netzwerkcontainer ein wichtiger Entscheidungsgrund ist, sonst wartet Ihr da auch schon mal Stunden auf den Mount.

Schritt 7: Den Containerinhalt ins System einbinden

Das Einbinden in das System ist dann denkbar einfach:

# mount /dev/mapper/cryptocontainer /mnt
# df -h | grep mnt
/dev/mapper/cryptocontainer 78M 1,6M 70M 3% /mnt

Das wärs schon, wenn da nicht das Zugriffsproblem wäre. Also muß Root da jetzt z.B. noch ein Verzeichnis anlegen, weil die User keine Schreibrechte haben:

# ls -ls /mnt/
insgesamt 12
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found
# ls -lad /mnt/
drwxr-xr-x. 3 root root 1024 13. Sep 12:01 /mnt/
# mkdir /mnt/demo
# chown demo:demo /mnt/demo
# chmod 700 /mnt/demo/
# ls -ls /mnt
insgesamt 14
2 drwx——. 2 demo demo 1024 13. Sep 12:10 demo
12 drwx——. 2 root root 12288 13. Sep 12:01 lost+found

Nun kann der Benutzer „demo“ da machen was auch immer er möchte.

Einbinden beim System-Boot

Das ist nicht ganz ohne. Man könnte dem Cron sagen, daß er das nach dem Boot machen soll, indem man da ein kleines Script benutzt, daß alle Schritte als Root macht, aber wer sagt uns, daß das auch passiert, wenn ein Netzwerk vorhanden ist? Niemand, also müssen wir das wohl oder übel an den Systemd übergeben. D.b. Ihr schreibt einfach ein kleines Start/Stop Script nach /etc/init.d/ oder direkt eine Unit für Systemd direkt, in dem die Anhängigkeiten zum erfolgreichen Netzwerkstart angegeben sind z.b. wie hier:

xl2tpd.service:After=network.target

So ist sichergestellt, daß es auch klappen kann, sofern alles mit dem Netzwerk und dem Server ok ist.

Sicherheitsanalyse

Wo liegen hier die Vorteile zu einem USB Stick? Zum Einen macht der Hoster normalerweise ein Backup von dem Server oder bietet Euch zumindest an, daß Ihr eins machen könnt. Dann ist das von überall aus erreichbar und i.d.R. kann man das nicht verlieren. Auch ein „Diebstahl“ wäre nicht tragisch, da der Dieb nicht an den Inhalt kommt, außer Eurer Passwort war „123456“ 😀

Die gesamte Ver- und Entschlüsselung der Daten findet zur Laufzeit auf Eurem PC statt, d.b. jemand muß sich Zugang zu Eurem PC verschaffen und dann auf die Daten zugreifen, wenn diese lokal verfügbar sind. Das könnt Ihr mit Updates und Festplattenvollverschlüsselung leicht kontern, denn dann können Euch lokale Angreifer mal am ….. . Auf diese Sicherheit müßt Ihr sowieso bauen, da ansonsten der Aufwand die Daten verschlüsselt im Netz zu speichern kompletter Unfug wäre. Also ganz klar: Entweder alles oder nichts verschlüsseln, sonst nützt es im Zweifel nichts.

VeraCrypt vs LUKS

Aus Benutzersicht ein klares Ja zu VeraCrypt: Kommt mit GUI und bindet sich ohne Root auch beim Login automatisch per FUSE ein.. 1a!

Der LUKS Container hat aber den Vorteil, daß man damit nur den Leuten vertrauen muß, die sowieso schon Eurer OS zusammenbauen. Wenn man denen nicht trauen würde, könnte man auch VeraCrypt nicht einsetzen, weil wenn das OS unsicher ist, wozu dann noch Verschlüsseln?

Über die /etc/crypttab kann LUKS Medien auch automatisch ins System einbinden lassen, allerdings muß zu dem Zeitpunkt das Netzlaufwerk mit dem Container verfügbar sein, sonst ist Essig. Hat also alles Vor- und Nachteile. Welche davon für Euch interessant sind, müßt Ihr entscheiden.

Wie bekomme ich den Container wieder zu?

Wichtige Frage, einfache Antworten:

umount /media/container/server
cryptsetup luksClose cryptocontainer
fusermount -u /media/container/server

How to Linux – Webserver lokal mounten

Icon des Webservers auf dem DesktopIcon des Webservers auf dem DesktopWer seine Webseiten entwickeln will, muß die irgendwie auf seinen Webspace bekommen. Je nachdem was man programmiert und welche Serverumgebung man hat, kann es auch sein, daß einem der Server einen Deploy Mechanismus anbietet. Das ist z.B. im WebApplicationServer Tomcat so vorgesehen. PHP Anwendungen werden üblicherweise einfach nur in das Public_html des Webspace kopiert und direkt aufgerufen.

Schritt 1 – SSH Keys einrichten

Voraussetzung für dies Verfahren ist, daß man sich auf seinem Webspace per SSH einloggen kann. Könnt Ihr das nicht, sucht Euch einen neuen Anbieter.

Das tun wir hier mal ( den Domainnamen habe ich mal exemplarisch gewählt, den gibt es zwar wirklich, aber nicht bei mir 😉 )

[marius@eve ~]$ ssh webdemode@webdemo.de
webdemode@webdemo.de's password: 

Passwort eingeben, weil noch geht ja kein Key.

Last login: Sat Mar 31 12:38:16 2018 from 79.239.240.108
[webdemode@s113 ~]$ ls -la
total 14
drwxr-x--- 3 webdemode services 4096 Mär 31 09:59 .
drwxr-xr-x 13 root root 4096 Mär 31 09:59 ..
-rw-r--r-- 1 webdemode webdemode 18 Aug 8 2017 .bash_logout
-rw-r--r-- 1 webdemode webdemode 193 Aug 8 2017 .bash_profile
-rw-r--r-- 1 webdemode webdemode 231 Aug 8 2017 .bashrc
drwxr-xr-x 3 webdemode webdemode 4096 Mär 31 09:59 public_html

Es fehlt das Verzeichnis „.ssh“, also anlegen:

[webdemode@s113 ~]$ mkdir .ssh
[webdemode@s113 ~]$ ls -la
total 18
drwxr-x--- 4 webdemode services 4096 Mär 31 10:09 .
drwxr-xr-x 13 root root 4096 Mär 31 09:59 ..
-rw------- 1 webdemode webdemode 229 Mär 31 10:39 .bash_history
-rw-r--r-- 1 webdemode webdemode 18 Aug 8 2017 .bash_logout
-rw-r--r-- 1 webdemode webdemode 193 Aug 8 2017 .bash_profile
-rw-r--r-- 1 webdemode webdemode 231 Aug 8 2017 .bashrc
drwxr-xr-x 3 webdemode webdemode 4096 Mär 31 09:59 public_html
drwxrwxr-x 2 webdemode webdemode 4096 Mär 31 10:02 .ssh

Noch hat es falsche Rechte, da würde SSH meckern :

[webdemode@s113 ~]$ chmod 700 .ssh
[webdemode@s113 ~]$ cd .ssh/
[webdemode@s113 .ssh]$ vi authorized_keys2

Dann den Fingerprint von Eurem Key in die Datei authorized_keys2 reinschreiben:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAEAQ7v3LaRyRjbm...... Rqr9L8IjxAEeT7bzZ/VH20ksRNwSEU5jnTE7S2Jcvk2u/7CnmipAp/uE2SvOdEVm7Lgku4y9EgSNlNi+QVbGFkzQ788AsiMHHULacHZRT9w== marius@meinlinuxrechner

(hier eine stark gekürzte Fassung, Eurer muß komplett da rein)

Nun noch die Rechte von der Datei ändern:

[webdemode@s113 .ssh]$ ls -la
total 10
drwx------ 2 webdemode webdemode 4096 Mär 31 11:03 .
drwxr-x--- 4 webdemode services 4096 Mär 31 10:09 ..
-rw-rw-r-- 1 webdemode webdemode 1435 Mär 31 11:03 authorized_keys2
[webdemode@s113 .ssh]$ chmod 644 authorized_keys2 
[webdemode@s113 .ssh]$

Das wars. Ab jetzt kann man mit seinem Key einloggen :

[webdemode@s113 .ssh]$ exit
Abgemeldet
Connection to webdemo.de closed.
[marius@eve ~]$ ssh webdemode@webdemo.de
Last login: Sat Mar 31 12:39:39 2018 from 79.239.240.108

Schritt 2 – SSHFS benutzen

Damit man sich seinen Webspace per SSH direkt in seinen Arbeitsbereich auf dem Desktop mounten kann, möglichst ohne dauernd Passwörter eingeben zu müssen, braucht man einen SSH-Agent z.b. den Gnome-Keyringdämonen. Diesem gebe ich meinen Key und statt mich jedesmal zu fragen, schickt der Agent dann einfach den Schlüssel an den Server.

ssh-add /pfad/zu/meinem/SSH-Schlüssel_rsa

ggf. Passwort eingeben.

sshfs webdemode@webdemo.de:/home/webdemode/ mnt

und schon kann man im Filesystem seines Desktops einfach auf den Webserver zugreifen, als wenn es Lokal wäre :

[marius@eve ~]$ ls -la mnt/
 insgesamt 52
 drwxr-x---. 1 testuser 500 4096 31. Mär 12:09 .
 drwx------. 106 marius marius 20480 31. Mär 11:57 ..
 -rw-------. 1 testuser testuser 356 31. Mär 13:05 .bash_history
 -rw-r--r--. 1 testuser testuser 18 8. Aug 2017 .bash_logout
 -rw-r--r--. 1 testuser testuser 193 8. Aug 2017 .bash_profile
 -rw-r--r--. 1 testuser testuser 231 8. Aug 2017 .bashrc
 drwxr-xr-x. 1 testuser testuser 4096 31. Mär 11:59 public_html
 drwx------. 1 testuser testuser 4096 31. Mär 13:03 .ssh

Welcher User einem da jetzt angezeigt wird, hängt von Eurem System ab, aber i.d.R. werden es nur die UID und GID des Serverusers sein. SSH kümmert sich dabei um alles, also auch, daß man die UID transponiert wird, es gibt am Ende also keine Probleme mit dem Lesen oder Schreiben von Dateien.

Das kann man dann einfach mit Gedit oder einem anderen Programm öffnen (BlueFish z.b. ):

Datei des Webservers in GEdit

Datei des Webservers in GEdit

Fedora 24: Wenn Automount nicht mehr geht

Wenn man einen USB-Stick in seinen Rechner steckt, erwartet man eigentlich, daß er als Laufwerk auftaucht. Seitdem Update auf Fedora 24 passierte das bei mir nicht mehr.

Schuld dürfte das unterbrochene Upgrade von F23 auf F24 sein, aber wer weiß.  Erstmal die Lage feststellen…

Werden die Drives gefunden ?

Als erstens schauen wir ins .. ups.. das gibt bei Euch nicht ja gar nicht mehr… /var/log/messages (Pech, ich habs noch 🙂 ) Wenn Ihr /v/l/m nicht mehr habt, dann könnt Ihr z.B. „dmesg“ befragen.

Steckt man einen USB Stick rein, muß sowas im Log erscheinen:

Nov  2 15:51:07 eve kernel: usb-storage 3-2:1.0: USB Mass Storage device detected
Nov  2 15:51:07 eve kernel: scsi host4: usb-storage 3-2:1.0
Nov  2 15:51:08 eve kernel: scsi 4:0:0:0: Direct-Access     Intenso  Rainbow Line     8.07 PQ: 0 ANSI: 4
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: Attached scsi generic sg4 type 0
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] 7907328 512-byte logical blocks: (4.05 GB/3.77 GiB)
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] Write Protect is off
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn’t support DPO or FUA
Nov  2 15:51:08 eve kernel: sdd: sdd1
Nov  2 15:51:08 eve kernel: sd 4:0:0:0: [sdd] Attached SCSI removable disk

Merkt GVFS, daß ein Gerät angeschlossen wurde ?

In einer Bash als normaler User führt Ihr mal „gvfs-mount -o -i“ aus:

Da müßte dann sowas stehen :

Drive changed:      'Intenso Rainbow Line'
  Drive(0): Intenso Rainbow Line
    Type: GProxyDrive (GProxyVolumeMonitorUDisks2)
    ids:
     unix-device: '/dev/sdd'
    themed icons:  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    symbolic themed icons:  [drive-removable-media-usb-symbolic]  [drive-removable-media-symbolic]  [drive-removable-symbolic]  [drive-symbolic]  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    is_media_removable=1
    has_media=1
    is_media_check_automatic=1
    can_poll_for_media=0
    can_eject=1
    can_start=0
    can_stop=0
    start_stop_type=shutdown
    sort_key=01hotplug/1478096885644198

Volume added:       'Daten'
  Volume(0): Daten
    Type: GProxyVolume (GProxyVolumeMonitorUDisks2)
    ids:
     class: 'device'
     unix-device: '/dev/sdd1'
     uuid: '227C9F0E7E06FAF9'
     label: 'Daten'
    themed icons:  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    symbolic themed icons:  [drive-removable-media-usb-symbolic]  [drive-removable-media-symbolic]  [drive-removable-symbolic]  [drive-symbolic]  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
    can_mount=1
    can_eject=1
    should_automount=1
    sort_key=gvfs.time_detected_usec.1478096885851240

d.b. das GVFS Kenntnis von dem neuen Gerät hat und nun an den Filemanager melden kann, daß DER es einhängen soll.

Wieso werden die dann nicht gemountet ?

Um das zu beantworten muß man etwas über Prozesskommunikation wissen. Die im OS dafür zuständige Komponente heißt D-BUS . Über den D-BUS kann Anwendung A Informationen an Anwendung B senden. Damit das auch bei Desktopanwendungen funktioniert, braucht es eine Spezialversion D-BUS X11 .

Die hatte es wohl bei meinem unterbrochenen Upgrade nicht sauber installiert, also holen wir das nach:

dnf reinstall dbus-x11

Reinstall simuliert das Entfernen und erneute Installieren in einem Rutsch. Danach noch Nautilus oder Nemo neu starten:

killall nautilus; nautilus --force-desktop

und schon tauchen die Laufwerke auch wieder auf dem Desktop und im Nautilus auf.

So leicht das hier auch klingt, in Realität hat es Stunden gedauert, bis ich das gefunden hatte.