DecaTec https://decatec.de Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie Wed, 21 Aug 2019 05:32:21 +0000 de-DE hourly 1 TLSv1.3 unter Ubuntu Server 18.04 LTS mit nginx https://decatec.de/home-server/tlsv1-3-unter-ubuntu-server-18-04-lts-mit-nginx/ https://decatec.de/home-server/tlsv1-3-unter-ubuntu-server-18-04-lts-mit-nginx/#respond Wed, 24 Jul 2019 13:45:35 +0000 https://decatec.de/?p=5974 Let's Encrypt Logo

Moderne Webserver und Browser nutzen TLS (Transport Layer Security) für die verschlüsselte Datenübertragung (z.B. mittels HTTPS). Bereits im August 2018 wurde hier der neue Standard TLSv1.3 verabschiedet. TLSv1.3 bietet viele Vorteile bzw. Sicherheit und Performance: Es kommen moderne Krypto-Algorithmen zum Einsatz, ältere (und als unsicher geltende Algorithmen werden nicht mehr unterstützt). Ebenfalls kann der Verbindungsaufbau durch einen effizienteren Handshake schneller durchgeführt werden.

Allerdings war TLSv1.3 unter Ubuntu Server 18.04 LTS (mit nginx) lange Zeit nicht nutzbar. Dies lag zum einen daran, dass unter Ubuntu 18.04 mit OpenSSL 1.1.0 ausgeliefert wurde. Die Unterstützung für TLSv1.3 wurde allerdings erst in OpenSSL 1.1.1 hinzugefügt. Dieses Update auf Version 1.1.1 wurde allerdings zu einem späteren Zeitpunkt nachgeliefert. Zum anderen wird der Webserver nginx gegen eine bestimmte Version von OpenSSL gebaut. Erst mit dem Update vom 23.07.2019 (nginx 1.17.2 – Mainline-Version) kommt nun auch hier unter Ubuntu 18.04 OpenSSL 1.1.1 zum Einsatz.

Vor diesen Updates kursierten im Internet zahlreiche Anleitungen, wie man OpenSSL und nginx für die Unterstützung von TLSv1.3 selbst kompilieren und installieren konnte. Allerdings sollte man auf solche Aktionen gerade auf Produktiv-Systemen verzichten.

Mit den nun verfügbaren Updates kann nun auch endlich TLSv1.3 unter nginx auf Ubuntu Server 18.04 LTS genutzt werden. Dieser Artikel zeigt, was dabei zu beachten ist.

Updates durchführen

Falls noch nicht geschehen, sollte das System zunächst einmal auf den aktuellen Stand gebracht werden:

apt-get update && apt-get upgrade -V && apt-get dist-upgrade && apt-get autoremove

Anschließend kann die Version von OpenSSL und nginx überprüft werden. Die Befehle dazu lauten wie folgt:

openssl version
nginx -V

Hier sollte in beiden Fällen OpenSSL 1.1.1 angezeigt werden:

Informationen zu OpenSSL/nginx

In diesem Fall ist das System bereit für TLSv1.3.

TLSv1.3 in nginx aktivieren

Die Konfiguration für TLSv1.3 muss anschließend in den virtuellen Hosts von nginx aktiviert werden.

Hinweis: Ich gehe im Folgenden davon aus, dass der Webserver bereits für HTTPS mit Zertifikaten von Let’s Encrypt konfiguriert ist. Ebenfalls kommen sowohl ECDSA-, als auch RSA-Zertifikate im Hybrid-Betrieb zum Einsatz. Details dazu sind dem Artikel RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung) zu entnehmen.

Die Konfiguration für SSL kann dabei direkt in den virtuellen Hosts erfolgen (meist zu finden unter /etc/nginx/conf.d). Für eine bessere Übersicht und die Möglichkeit, SSL-Konfigurationen für mehrere vHosts wiederzuverwenden, nutze ich hier allerdings eine eigene Konfigurations-Datei, welche anschließend in die virtuellen Hosts eingebunden wird (/etc/nginx/snippets/ssl.conf).

Für TLSv1.3 sind hier mehrere Dinge wichtig:

  • ssl_protocols TLSv1.2 TLSv1.3: Hiermit wird die Unterstützung für TLSv1.2 und TLSv1.3 aktiviert. Wichtig: TLSv1.0 und TLSv1.1 sollten an dieser Stelle nicht mit aufgelistet werden, weil diese nicht mehr als sicher gelten.
  • ssl_ciphers ‚TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384‘: Definiert die sog. Cipher Suites. Diese müssen für TLSv1.3 entsprechend angepasst werden (die ersten beiden in der Liste sind speziell für TLSv1.3). Danaben wird hier ECDSA vor RSA bevorzugt.
  • ssl_ecdh_curve secp521r1:secp384r1: Spezifiziert die „Kurve“ für ECDHE-Algorithmen. Hier sollte prime256v1 nicht mehr gelistet werden.

Alle anderen Einstellungen müssen nicht weiter angepasst werden, so dass die SSL-Konfiguration zusammenfassend so aussehen kann:

# Certificates used
# RSA
ssl_certificate /etc/letsencrypt/DOMAIN.de/rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/DOMAIN.de/rsa/key.pem;

# ECC
ssl_certificate /etc/letsencrypt/DOMAIN.de/ecc/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/DOMAIN.de/ecc/key.pem;

# This should be ca.pem (certificate with the additional intermediate certificate)
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/letsencrypt/DOMAIN.de/ecc/ca.pem;

# Diffie-Hellman parameter, recommended 4096 bits
ssl_dhparam /etc/nginx/ssl/dhparams.pem;

# Not using TLSv1 will break:
#	Android <= 4.4.40
#	IE <= 10
#	IE mobile <=10
# Removing TLSv1.1 breaks nothing else!
# TLSv1.3 is not supported by most clients, but it should be enabled.
ssl_protocols TLSv1.2 TLSv1.3;

# Prefer the SSL ciphers for ECDSA:
ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384';


# Use multiple curves.
ssl_ecdh_curve secp521r1:secp384r1;

# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;

# OCSP Stapling
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

# This is the IP if yout DNS-Server (in most cases: your router's IP)
resolver 192.168.178.1;

# SSL session handling
ssl_session_timeout 24h;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

Am Schluss muss der Webserver noch neu gestartet werden, damit die Änderungen greifen.

service nginx restart

Falls es hier zu Fehler kommen sollte, kann die genaue Stelle des Fehlers mit folgendem Befehl ermittelt werden:

nginx -t

Kontrolle der Änderungen

Nun kann man die Website im Browser aufrufen und sich die detaillierten Informationen zu der Seite anzeigen lassen. Unter Firefox geht dies beispielsweise, indem man auf das Schloss-Symbol in der Adressleiste klickt. Unter den Details zur Verbindung (Pfeil nach rechts) findet man unten die Schaltfläche Weitere Informationen. Hier sollte dann unter Technische Details ersichtlich werden, dass TLSv1.3 genutzt wird:

Firefox nutzt nun automatisch TLSv1.3

Firefox nutzt nun automatisch TLSv1.3

Eine weitere Anlaufstelle zum Testen von Websites und deren Sicherheit ist der SSL Server Test von Qualys. Beim Test der eigenen Website sollte hier ein A+ Rating und ein Hinweis auf die Unterstützung von TLSv1.3 angezeigt werden:

Beim Qualys SSL Server Test sollte man ein A+ Rating erzielen können

Beim Qualys SSL Server Test sollte man ein A+ Rating erzielen können

Hinweis: In der Kategorie Cipher Strength kann man hier momentan nur eine Wertung von 90% erzielen, auch wenn hier vorher (TLSv1.2) eine 100% Wertung aufgelistet wurde. Dies liegt darin begründet, dass der TLSv1.3-Standard eine Cipher Suite vorgibt, die nur auf 128 Bit basiert (TLS_AES_128_GCM_SHA256). Diese ist bei OpenSSL fest verdrahtet und kann nicht deaktiviert werden. Qualys wertet hier nur mit 100%, wenn alle Cipher Suites mindestens 256 Bit haben. Dies kann momentan nur umgangen werden, indem man OpenSSL selbst kompiliert und installiert. Auf einem Produktiv-System ist dies jedoch nicht zu empfehlen. Mehr Informationen zu diesem Problem findet man auf GitHub.

Wichtig beim SSL Server Tests ist aber ausschließlich das Rating von A+. Auch wenn eine Kategorie nicht mit 100% bewertet ist, stellt dies kein Sicherheits-Risiko dar.

Fazit

Mit dem Update von nginx auf v1.17.2 ist es nun auch endlich möglich, unter Ubuntu Server 18.04 LTS TLSv1.3 zu nutzen. Dies funktioniert ab sofort auch „out-of-the-box“, ohne dass man den Webserver oder OpenSSL selbst bauen und installieren muss.

TLSv1.3 bietet Vorteile bei der Sicherheit und Performance. Daher sollte man seinen Webserver auf jeden Fall für diesem modernen Standard konfigurieren.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/tlsv1-3-unter-ubuntu-server-18-04-lts-mit-nginx/feed/ 0
Verschlüsselte Festplatte (LUKS) mit USB-Stick bei Systemstart entschlüsseln https://decatec.de/linux/verschluesselte-festplatte-luks-mit-usb-stick-bei-systemstart-entschluesseln/ https://decatec.de/linux/verschluesselte-festplatte-luks-mit-usb-stick-bei-systemstart-entschluesseln/#comments Sun, 14 Jul 2019 10:28:32 +0000 https://decatec.de/?p=5914

Oftmals werden auf dem PC oder Home-Server sensible Daten gespeichert. Hier sollte man immer überlegen, ob eine Verschlüsselung der Datenträger lohnt. Wenn der Server zu Hause steht, hat prinzipiell kein Dritter physischen Zugriff auf das System. Aber was passiert, wenn der Home-Server bei einem Einbruch gestohlen wird?. Auch wenn es der Dieb eher auf die Hardware abgesehen hat, bleibt ein ungutes Gefühl, wenn die Daten auf dem Server unverschlüsselt gespeichert wurden. In der Theorie haben dann Dritte Zugriff auf das System und alle darauf gespeicherten Daten.

Die Verschlüsselung von Datenträgern ist unter Linux schnell eingerichtet. Das Mittel der Wahl ist dabei meistens LUKS („Linux Unified Key Setup“). Hier kommt dann meist ein Passwort, oder auch ein sog. Key-File (Dateien mit beliebigem Inhalt – am besten eine zufällige Byte-Folge) zum Einsatz, mit dem eine Festplatte entschlüsselt werden kann.

Die Sicherheit erkauft man sich dann allerdings durch einen Mangel an Komfort: Nach dem Start des Systems müssen verschlüsselte Festplatten erst einmal mittels Passwort/Key-File entschlüsselt und anschließend gemountet werden. Das bedeutet nach jedem (Neu-)Start des Systems Handarbeit.

Um diese Einschränkungen zu umgehen, zeigt dieser Artikel, wie ein USB-Stick zum Entschlüsseln von Datenträgern beim Systemstart genutzt werden kann. Der Clou an der Sache: Wir speichern das Key-File nicht einfach auf dem USB-Stick selbst, sondern noch vor der ersten Partition. Auf diese Weise kann der Stick noch normal verwendet (und auch formatiert) werden. Ebenfalls ist es nicht ersichtlich, dass ein Key-File auf dem Stick enthalten ist, sollte dieser mal in falsche Hände geraten.

Update-Historie (letztes Update: 11.08.2019)
  • 11.08.2019:
    • Korrektur: Beim Erzeugen der Schlüssel-Datei wurden nur 8 statt 16 Sektoren genutzt.

Voraussetzungen

Der Artikel basiert auf Ubuntu Server 18.04 LTS, sollte allerdings auch auf andere Distributionen übertragbar sein.

Es wird nur ein beliebiger USB-Stick benötigt – die Speichergröße ist hierbei egal. Ich verwende beispielsweise einen USB-Stick von SanDisk (Affiliate-Link).

Die zu verschlüsselnde Festplatte ist in diesem Artikel beispielhaft eine zweite interne Festplatte (also nicht die System-Partition). Dadurch kann der ganze Workflow vom Verschlüsseln der Festplatte selbst, bis zum Entschlüsseln mittels USB-Stick bei Systemstart gezeigt werden.

Wichtig: Beim Verschlüsseln der Festplatte gehen dabei alle Daten verloren. Sind bereits Daten auf der Festplatte vorhanden, müssen diese vorher gesichert und nach dem Prozess wieder zurück gespielt werden.
Ebenfalls ist darauf zu achten, bei sämtlichen Befehlen die richtige Festplatte/Partition auszuwählen/anzugeben. Wird eine falsches Gerät adressiert, kann man schnell das komplette System lahm legen (weil z.B. die Daten der System-Partition überschrieben/gelöscht werden). Daher bitte die Befehle nicht einfach kopieren, sondern manuell in der Kommandozeile eingeben und am besten vor dem Ausführen nochmals kontrollieren.

Generell empfiehlt es sich, ein Backup des Systems anzufertigen, bevor die Schritte des Artikels durchgeführt werden.

Festplatte mit LUKS verschlüsseln

Ich gehe im folgenden davon aus, dass die zweite Festplatte im System unter /dev/sdb erkannt wird. Ebenfalls kommt im Setup weder LVM, noch RAID zum Einsatz. Bei LUKS in Verbindung mit LVM bzw. RAID gibt es einige zusätzliche Dinge zu beachten (siehe LUKS FAQ).

Bei der Verschlüsselung mittels LUKS hat man die Wahl, ob man die Festplatte direkt („Raw Device“), oder eine auf der Festplatte zuvor angelegte Partition verschlüsseln möchte. In diesem Beispiel wird die Festplatte (ohne Partition) verschlüsselt, da ich keine Aufteilung in unterschiedliche Partitionen benötige. Wer lieber eine Partition verschlüsseln möchte, muss dies in den entsprechenden Befehlen beachten. Hier ist dann nicht das Device an sich (/dev/sdb), sondern die Partition anzugeben (z.B. /dev/sdb1).

Zunächst wird die benötigte Software installiert:

apt-get update && apt-get install crypsteup dosfstools

Mit folgendem Befehl wird kontrolliert, ob die Festplatte richtig angeschlossen ist und ob die Gerätedatei (/dev/sdb) auch korrekt ist:

fdisk -l

Am besten achtet man hier auf die Größenangaben der Festplatte. Der Output des Programms sieht dann für /dev/sdb beispielhaft so aus:

Disk /dev/sdb: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Wenn es sich um eine Festplatte handelt, die bereits vorher in Benutzung war, sollte diese vor der Verschlüsselung nochmals mit zufälligen Daten überschrieben werden. Dies macht die Verschlüsselung dann etwas sicherer, da keine unverschlüsselten Daten mehr auf der Festplatte vorliegen.

dd if=/dev/urandom of=/dev/sdb

Achtung: Dieser Vorgang kann gerade bei größeren Festplatten sehr lange dauern!

Anschließend wird ein evtl. vorhandenes Dateisystem auf der Festplatte gelöscht:

wipefs -a /dev/sdb

Nun kann auch schon das interaktive Setup von LUKS aufgerufen werden:

cryptsetup luksFormat /dev/sdb

Hier ist ein Passwort einzugeben, mit dem das Laufwerk entschlüsselt werden kann. Das Passwort sollte dabei eine ausreichende Länge haben.

Tipp: Ein Passwort-Manager (z.B. KeePassXC) hilft nicht nur dabei, Passwörter sicher aufzubewahren, sondern kann auch bei der Generierung sicherer Passwörter helfen.

Um anschließend Zugriff auf die Festplatte zu erlangen, muss diese durch einen Device-Mapper als Geräte-Datei bereit gestellt werden:

cryptsetup luksOpen /dev/sdb crypt_hdd1

crypt_hdd1 ist anschließend der Name der entschlüsselten Festplatte. Diese kann nun wie eine normale Festplatte gemountet werden:

mkdir -p /media/hdd1
mount /dev/mapper/crypt_hdd1 /media/hdd1

Der Zugriff auf die Festplatte erfolgt in diesem Beispiel dann über den Ordner /media/hdd1.

Nun kann auf der Festplatte ein Dateisystem erzeugt werden (in diesem Fall ext4):

mkfs.ext4 /dev/mapper/crypt_hdd1

Zusammenfassend nochmals die Befehle zum Einhängen/Aushängen der verschlüsselten Festplatte.

Einhängen/Mounten:

cryptsetup luksOpen /dev/sdb crypt_hdd1
mount /dev/mapper/crypt_hdd1 /media/hdd1

Hier wird man nach dem ersten Befehl nach dem Passwort gefragt. Ohne dieses lässt sich die Platte nicht mehr entschlüsseln.

Aushängen/Unmounten:

umount /mnt/crypt_hdd1
cryptsetup luksClose crypt_hdd1

Durch luksClose wird die Verschlüsselung der Festplatte wieder aktiv, so dass ohne vorheriges Entschlüsseln/Mounten kein Zugriff mehr erfolgen kann.

USB-Stick zum Entschlüsseln einrichten

Als nächstes wird der USB-Stick vorbereitet, so dass dieser zum Entschlüsseln der Festplatte genutzt werden kann.

Achtung: Auch hier gehen wieder alle Daten verloren, die auf dem USB-Stick gespeichert sind. Wie schon zuvor ist darauf zu achten, dass man das richtige Gerät wählt. In diesem Beispiel erfolgt der Zugriff auf den USB-Stick über /dev/sdc.

Zum Einrichten des USB-Sticks benutzen wir wieder fdisk:

fdisk /dev/sdc

Mit folgenden Eingaben wird der Stick vorbereitet:

  • d: Bestehende Partition löschen.
  • o: Partitionstabelle neu erstellen.
  • n: Neue Partition erstellen. Dies sollte eine primäre Partition sein (p). Beginn der Partition sollte Sektor 2048 sein, dies ist die Standard-Einstellung.
  • w: Speichern und beenden.

Der USB-Stick wird mittels fdisk vorbereitet

Nun kann auf dem USB-Stick ein Dateisystem angelegt werden. Ich nehme hier ein FAT32-Dateisystem, damit der Stick sowohl unter Linux, als auch unter Windows verwendet werden kann. Wenn der Stick ausschließlich unter Linux verwendet werden soll, kann natürlich auch ein ext2/3/4-Dateisystem verwendet werden.

sudo mkfs.vfat -F 32 /dev/sdc1

Nun wird auf dem USB-Stick vor der ersten Partition (also in den ersten 2048 Sektoren) eine zufällige Byte-Folge erzeugt, die nachher als Schlüssel für die verschlüsselte Festplatte dienen wird:

dd if=/dev/urandom of=/dev/sdc bs=512 seek=1 count=2046

Schlüssel zur verschlüsselten Festplatte hinzufügen

Als nächstes speichern wir den soeben erzeugten Schlüssel in einer Datei ab:

dd if=/dev/sdc bs=512 skip=1 count=16 > tempKeyFile.bin

Hier nehmen wir die ersten 16 Sektoren des USB-Sticks, somit haben wir hier eine Schlüssellänge 8192 Bytes.

Diese (temporär) erzeugte Datei wird nun über LUKS als neuer Key der Festplatte hinzugefügt:

cryptsetup luksAddKey /dev/sdb tempKeyFile.bin

Anschließend kann die Festplatte auf zwei verschiedene Weisen entschlüsselt werden:

  • Mit dem Passwort, welches bei der Verschlüsselung der Festplatte angegeben wurde.
  • Mit dem soeben erzeugten Key-File, welches auch auf dem Stick vor der ersten Partition gespeichert ist.

Das Key-File (tempKeyFile.bin) wird anschließend nicht mehr benötigt. Jedoch sollte man dies ebenfalls sicher verwahren, falls man z.B. zukünftig einen anderen USB-Stick zum entschlüsseln verwenden möchte. Das Key-File kann z.B. neben dem Passwort zum Entschlüsseln ebenfalls in einem Passwort-Manager (als Anhang) gespeichert werden.

Anschließend wird das Key-File vom System entfernt:

rm tempKeyFile.bin

Festplatte automatisch bei Systemstart entschlüsseln

Nun fehlt nur noch ein entscheidender Bestandteil der Lösung: Wir wollen die Festplatte nicht per Passwort oder Key-File, sondern mit dem Schlüssel entschlüsseln, der auf dem USB-Stick hinterlegt ist. Das ganze soll auch transparent bei Systemstart ohne weiteres Zutun den Users passieren.

UUIDs der Geräte ermitteln

Damit dies umgesetzt werden kann, müssen die UUIDs der entsprechenden Geräte ermittelt werden.
Für den USB-Stick kann dies durch folgenden Befehl geschehen:

ls /dev/disk/by-id/

Hier sollte der USB-Stick mit zwei Einträgen gelistet werden.

usb-SanDisk_Ultra_4C530000100xxxxxxxxx-0:0
usb-SanDisk_Ultra_4C530000100xxxxxxxxx-0:0-part1

Hier brauchen wir die UUID des Sticks selbst und nicht jene von der ersten Partition (zu erkennen an -part1 am Ende). Die gesuchte UUID ist in diesem Beispiel also 4C530000100xxxxxxxxx-0:0.

Nun brauchen wir nur noch die UUID der LUKS-verschlüsselten Festplatte. Hier hilft folgender Befehl:

blkid

Hier sollte man nun folgende Zeile finden (die verschlüsselte Festplatte ist ja unter /dev/sdb zu erreichen):

/dev/sdb: UUID=“10fc8291-daf2-4962-xxxx-xxxxxxxxxxxx“ TYPE=“crypto_LUKS“

Die UUID ist hier dementsprechend 10fc8291-daf2-4962-xxxx-xxxxxxxxxxxx.

crypttab/fstab editieren

Damit die Festplatte bei Systemstart entschlüsselt wird, wird nun die crypttab (Anweisungen zum Einhängen verschlüsselter Geräte) bearbeitet:

nano /etc/crypttab

Hier fügen wir am Ende folgende Zeile ein:

crypt_hdd1 UUID=10fc8291-daf2-4962-xxxx-xxxxxxxxxxxx /dev/disk/by-id/usb-SanDisk_Ultra_4C530000100xxxxxxxxx-0:0 luks,tries=3,keyfile-size=8192,keyfile-offset=512

Bei der UUID handelt es sich um jene der verschlüsselten Festplatte. Daraufhin folgen Angaben zum USB-Stick, der zum entschlüsseln verwendet werden soll. Am Schluss wird angegeben, wo der entsprechende Schlüssel zu finden ist.

Damit wird die Festplatte beim Systemstart entschlüsselt. Was nun noch fehlt ist das Einhängen der entschlüsselten Festplatte, so dass diese nach dem Systemstart sofort zur Verfügung steht. Dazu wird noch die fstab editiert:

nano /etc/fstab

Am Ende fügen wir folgende Zeile hinzu:

/dev/mapper/crypt_hdd1       /media/hdd1     ext4    defaults        0       2

Beim Systemstart werden nun erst einmal die Inhalte der crypttab abgearbeitet. Damit wird die Festplatte entschlüsselt und steht per Mapper (/dev/mapper/crypt_hdd1) zur Verfügung. Erst im Anschluss werden die Laufwerke per fstab gemountet. Hier wird der Mapper dann unter /media/hdd1 eingehängt.

Nach einem Neustart des Systems (mit angeschlossenem USB-Stick) sollte die Festplatte nun direkt unter /media/hdd1 zur Verfügung stehen. Es wird kein Passwort mehr benötigt und das Key-File ist auch nicht mehr manuell anzugeben.

Fazit

Die Einrichtung von verschlüsselten Festplatten, die beim Systemstart automatisch per USB-Stick entschlüsselt werden, ist mit einigem Aufwand verbunden. Jedoch muss man sich nach der Konfiguration nicht weiter um die Ver-/Entschlüsselung der Festplatte sorgen, da dies nun vollkommen transparent geschieht

Wichtig ist ab nun nur, dass man den USB-Stick einstecken muss, wenn die Maschine (neu) gestartet werden soll. Sollte man dies vergessen, bleibt das System schon beim Booten hängen, da die Anweisungen in der crypttab nicht abgearbeitet werden können und der Mount per fstab fehlschlägt.

Ebenso benötigt es etwas Disziplin: Wenn die Maschine erst einmal läuft, sollte der USB-Stick auf jeden Fall entfernt und sicher aufbewahrt werden (z.B. am Schlüsselbund). Im Falle eines Diebstahls der Hardware ist es nun praktisch gesehen unmöglich, auf die Daten des Systems zuzugreifen, wenn man nicht den passenden USB-Stick zur Hand hat.

Links

]]>
https://decatec.de/linux/verschluesselte-festplatte-luks-mit-usb-stick-bei-systemstart-entschluesseln/feed/ 4
WordPress: Backups erstellen und wiederherstellen – manuell oder per Skript https://decatec.de/home-server/wordpress-backups-erstellen-und-wiederherstellen-manuell-oder-per-skript/ https://decatec.de/home-server/wordpress-backups-erstellen-und-wiederherstellen-manuell-oder-per-skript/#comments Sat, 08 Jun 2019 09:02:18 +0000 https://decatec.de/?p=5817 Wordpress Logo

WordPress erfreut sich bei Bloggern nach wie vor großer Beliebtheit. Wenn man einen eigenen WordPress-Blog betreibt, sollte man sich auch um das Thema Backup kümmern.

Wird der Blog bei einem Webhosting-Provider gehostet, dann werden meist von diesem automatisch Backups des kompletten Webspace durchgeführt. Damit wird dann auch ein vorhandener WordPress-Blog mit gesichert.

Anders sieht die Sache bei selbstgehosteten Blogs aus. Hier ist der Administrator selbst für Backups des Servers und der Webseiten verantwortlich.

Voraussetzungen

Dieser Artikel richtet sich an Administratoren, die WordPress auf einem eigenen (Home-)Server betreiben.

Als Grundlage dient ein WordPress-Blog, der auf einem Ubuntu Server 18.04 LTS installiert ist. Als Webserver dient hier nginx, als Datenbank kommt MariaDB zum Einsatz.
Eine beispielhafte Konfiguration wurde bereits im Artikel Zweite Web-Anwendung neben ownCloud/Nextcloud einrichten (am Beispiel WordPress) gezeigt.

Allerdings lassen sich die gezeigten Schritte auch auf andere Umgebungen (andere Distributionen, andere Webserver, etc.) anwenden.

Grundlagen

Ein Backup von WordPress besteht immer aus zwei Teilen:

  • Dem WordPress Dateiverzeichnis: Dies sind alle Dateien, die zum Betrieb von WordPress benötigt werden (z.B. php, oder auch css-Dateien). Dies ist normalerweise unter /var/www/wordpress zu finden.
  • Der WordPress-Datenbank: WordPress benötigt eine MySQL/MariaDB-Datenbank. Diese muss ebenfalls in die Sicherung einfließen.

Sollen Backups des eigenen Blogs eingerichtet werden, müssen immer diese beiden Teile berücksichtigt werden.

Im Vorfeld sollte man sich Gedanken darüber machen, wo die Backups gespeichert werden sollen. Im Rahmen dieses Artikels nutze ich beispielhaft das Verzeichnis /media/hdd/wordpress_backup als Backup-Ziel. Dies kann in der Praxis eine zweite (externe) Festplatte oder ein NAS sein, welches im Netzwerk zur Verfügung steht.

Backup erstellen

Um ein Backup zu erstellen, stoppen wir zunächst den Webserver:

service nginx stop

Dies verhindert, dass während des Backups aktive Zugriffe auf den Blog stattfinden.

Als nächstes wird das Dateiverzeichnis von WordPress gesichert. Hier ist dies beispielhaft das Verzeichnis /var/www/wordpress. Bitte den Punkt am Ende des Befehls beachten.

tar -cpzf "/media/hdd/wordpress_backup/wordpress-filedir_`date +"%Y%m%d"`.tar.gz" -C "/var/www/wordpress" .

Als nächstes wird die Datenbank gesichert. Nach dem Absetzen des Befehls ist noch das Passwort des WordPress-Datenbank-Users einzugeben:

mysqldump --single-transaction -h localhost -u wordpress_db_user -p wordpress_db > /media/hdd/wordpress_backup/wordpress-db_`date +"%Y%m%d"`.sql

Das Backup ist damit schon komplett und der Webserver kann neu gestartet werden:

service nginx start

Backup wiederherstellen

Das Anfertigen von Backups ist aber nur der erste Schritt. Ebenso wichtig ist es, dass diese Backups auch wiederhergestellt werden können.

Dies sollte man nach dem ersten Anfertigen eines Backups auch mindestens einmal ausprobieren.

Zunächst wird der Webserver gestoppt:

service nginx stop

Anschließend wird das Dateiverzeichnis von WordPress gelöscht und neu angelegt (allerdings leer):

rm -r /var/www/wordpress/
mkdir -p /var/www/wordpress

Als nächstes werden die Inhalte des Verzeichnisses aus dem Backup wiederhergestellt. Zu beachten ist hier der richtige Dateiname (da abhängig vom Datum):

tar -xpzf /media/hdd/wordpress_backup/wordpress-filedir_20190530.tar.gz -C /var/www/wordpress/

Nun werden noch die passenden Rechte gesetzt:

chown -R www-data:www-data /var/www/wordpress

Nun muss nur noch die Datenbank wiederhergestellt werden. Dazu wird die alte Datenbank zunächst einmal entfernt und neu angelegt:

mysql -h localhost -u wordpress_db_user -p -e "DROP DATABASE wordpress_db"
mysql -h localhost -u wordpress_db_user -p -e "CREATE DATABASE wordpress_db"

Nun wird der DB-Dump aus dem Backup wieder eingespielt:

mysql -h localhost -u wordpress_db_user -p wordpress_db < /media/hdd/wordpress_backup/wordpress-db_20190530.sql

Am Schluss wird der Webserver wieder gestartet:

service nginx start

Backup/Restore mit Bash-Skript

Ein Backup kann mit diesen einfachen Schritten erstellt werden. Allerdings sind dazu immer manuelle Schritte erforderlich. Komfortabler wird die Sache, wenn man alle Schritte mit einem Bash-Skript zusammenfasst. Dieses kann dann einfach ausgeführt werden und es wird automatisch ein Backup erstellt.

Zu diesem Zweck habe ich zwei Bash-Skripte auf Codeberg zur Verfügung gestellt:

WordPress-Backup-Restore @ Codeberg

Hinweis: Ich habe die Skript-Dateien als Open Source auf Codeberg zur Verfügung gestellt. Damit sind diese frei verfügbar und können auch von jedermann angepasst und verbessert werden. Ich übernehme allerdings keinerlei Haftung für den Einsatz dieser Skripte. Diese sollen lediglich als Basis für die Erstellung eigener Backup-/Restore-Skripte für eure WordPress-Instanzen dienen.

Das Repository kann einfach über Git gecloned werden:

cd ~
git clone https://codeberg.org/DecaTec/Wordpress-Backup-Restore.git
cd Wordpress-Backup-Restore

Wichtig: Die Skripte müssen auf jeden Fall noch an die konkrete Umgebung angepasst werden. Alle Stellen, die kontrolliert bzw. angepasst werden müssen, sind in den Skripten mit dem Kommentar „TODO“ gekennzeichnet.

Bitte passt die Skripte daher auf jeden Fall an und führt diese nicht einfach „blind“ aus!

Wenn das geschafft ist, werden die Skripte noch als ausführbar markiert:

chmod +x WordpressBackup.sh
chmod +x WordpressRestore.sh

Nun können die Skripte ganz einfach wie folgt ausgeführt werden:

./WordpressBackup.sh

Das Backup wird automatisch im Verzeichnis /media/hdd/wordpress_backup erstellt. Hier wird ein Verzeichnis mit dem aktuellen Zeitstempel erstellt, z.B.: /media/hdd/wordpress_backup/20190530_081555

Wiederhergestellt werden kann ein Backup durch das Restore-Skript. Dieses erwartet den Zeitstempel eines vorhandenen Backups als Parameter:

./WordpressRestore.sh 20190530_081555

Diese Skripte sind so konzipiert, dass diese keine Benutzer-Interaktion erfordern. Daher kann die Ausführung auch einfach per Cron automatisiert werden. Besonders für das Backup-Skript ist dies sinnvoll: So kann man z.B. jede Nacht um 03:00 ein Backup des eigenen WordPress-Blogs anfertigen. Dazu kann ein Cronjob für den Webserver-User eingerichtet werden:

crontab -u www-data -e

Hier wird am Ende einfach folgender Befehl angehängt:

0 3 * * * /home/user/Wordpress-Backup-Restore/WordpressBackup.sh > /dev/null 2>&1

Dies sorgt dafür, dass jede Nacht um 03:00 ein Backup von WordPress angelegt wird. Wichtig ist hier nur, dass der absolute Pfad zu Skript angegeben wird, da die Ausführung ansonsten fehlschlagen wird.

Alternative: Backup per WordPress-Plugin

Eine Alternative zum dem gezeigten Vorgehen ist der Einsatz eines entsprechenden Plugins für WordPress. Meiner Erfahrung nach gibt es hier zwei empfehlenswerte Plugins:

Beide Plugins dienen dazu, Backups der WordPress-Instanz manuell oder automatisiert anzulegen. Das ganze wird einfach im Dashboard von WordPress konfiguriert bzw. ausgeführt. Die Plugins sind dabei mehr oder weniger selbsterklärend, so dass ich hier nicht weiter darauf eingehen werde.

Zum einen macht dies das Anfertigen von Backups einfacher. Zum anderen macht man sich allerdings in gewisser Weise abhängig von dem verwendeten Plugin. Dies ist durch ein manuelles Backup oder ein Backup per Bash-Skript nicht gegeben.

Welche Variante (manuell/per Skript oder per Plugin) die passende ist, muss jeder WordPress-Administrator für sich selbst entscheiden.

Fazit

Ein Backup einer WordPress-Instanz ist recht schnell angefertigt. Noch komfortabler geht dies mit den bereitgestellten Bash-Skripten. Mit diesen kann das Anfertigen eines Backups auch mittels Cron automatisiert werden.

Am Ende noch ein wichtiger Tipp: Nichts ist ärgerlicher, wenn man immer Backups angefertigt hat, diese aber im Ernstfall nicht wiederhergestellt werden können. Daher sollte einmal der komplette Backup- und Restore-Prozess getestet werden. Nur auf diese Weise kann man sicher sein, dass im Falle des Falles ein bestehendes Backup wiederhergestellt werden kann.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/wordpress-backups-erstellen-und-wiederherstellen-manuell-oder-per-skript/feed/ 3
Samba auf Ubuntu Server https://decatec.de/linux/samba-auf-ubuntu-server/ https://decatec.de/linux/samba-auf-ubuntu-server/#comments Mon, 27 May 2019 13:48:39 +0000 https://decatec.de/?p=5699 Samba Logo

Wenn man einen eigenen Home-Server betreibt, dann wird man diesen oftmals auch als zentrale Stelle zur Ablage von Dateien verwenden. Damit jeder Rechner im Netzwerk Zugriff auf diese  Dateien hat, muss der Server diese Daten per Netzwerk-Freigaben bereit stellen.

In einem reinen Linux-Netzwerk würde man hier vermutlich NFS verwenden. Oftmals hat man es jedoch mit gemischten Netzwerken zu tun. Hier müssen neben Linux- auch Windows- oder Mac-Clients Zugriff auf die Netzwerk-Freigaben haben. Hier nutzt man dann am besten das SMB-Protokoll, welches auf allen Plattformen unterstützt wird. Als Server-Implementierung steht unter Linux das Softwareprojekt Samba zur Verfügung.

Dieser Artikel zeigt, wie auf Ubuntu Server 18.04 LTS eine Samba-Server installiert und konfiguriert werden kann. Allerdings können alle Schritte auch auf andere Distributionen übertragen werden.

Eine wichtige Anforderung bei Netzwerk-Shares ist immer auch die Freigabe für mehrere Benutzer: Auf eine Freigabe sollen u.U. mehrere Benutzer Schreib- und Leserechte haben. Dies wird in diesem Artikel durch das Setzen von ACLs gelöst.

Installation Samba

Zunächst wird das System auf dem neusten Stand gebracht:

apt-get update && apt-get upgrade -V && apt-get dist-upgrade && apt-get autoremove

Anschließend kann Samba installiert werden:

apt-get install samba-common samba

Das Paket samba-common sollte auf jeden Fall mit installiert werden, da dies wichtige Tools (wie z.B. smbpasswd) beinhaltet.

Benutzer hinzufügen

Damit ein Benutzer später auf die Samba-Netzwerk-Freigaben zugreifen kann, muss dieser Benutzer zunächst einmal angelegt werden. Wichtig ist ist in diesem Zusammenhang, dass der Benutzer sowohl als System-Benutzer, als auch als Samba-Benutzer angelegt werden muss.

Wenn es den Benutzer noch nicht als System-Benutzer gibt, dann wird dieser angelegt und danach ein Passwort für den Benutzer hinterlegt:

adduser bob

Alternative: Normalerweise legt man diese Benutzer nur an Home-Server an, damit diese später Zugriff auf die Samba-Freigaben haben. In diesem Fall macht es keinen Sinn, dass sich diese Benutzer direkt am System anmelden. Hier kann man den User folgendermaßen anlegen, so dass sich dieser nicht am Server selbst anmelden kann:

adduser --no-create-home --disabled-login --shell /bin/false bob

Anschließend wird noch ein Passwort für den System-Benutzer hinterlegt:

passwd bob

Anschließend muss der entsprechende User noch als Samba-User angelegt und aktiviert werden:

smbpasswd -a bob

Empfehlenswert ist hier, das gleiche Passwort wie schon für den System-Benutzer zu vergeben, dies ist jedoch nicht zwingend erforderlich.

Für jeden weiteren Benutzer ist der Vorgang zu wiederholen. Neben Bob gibt es in diesem Artikel als weiteren User auch Alice:

adduser --no-create-home --disabled-login --shell /bin/false alice
passwd alice
smbpasswd -a alice

Verzeichnisse für Netzwerk-Shares vorbereiten

Als nächstes werden beispielhaft drei Verzeichnisse vorbereitet, die später im Netzwerk verfügbar sein sollen. Auf das erste Verzeichnis sollte nur der Benutzer Bob Zugriff haben, daher werden anschließend gleich die entsprechenden Besitzrechte gesetzt:

mkdir -p /media/hdd1/networkshares/bob
chown -R bob /media/hdd1/networkshares/bob

Das gleiche wird für ein Verzeichnis für Alice wiederholt:

mkdir -p /media/hdd1/networkshares/alice
chown -R alice /media/hdd1/networkshares/alice

Ein drittes Verzeichnis soll nachher für beide Benutzer zur Verfügung stehen. Hier wird lediglich das Verzeichnis erzeugt:

mkdir -p /media/hdd1/networkshares/shared

Nun haben wir allerdings ein Problem mit den Verzeichnisrechten: Beide Benutzer sollen hier Vollzugriff haben. Per chown kann allerdings nur ein User als Owner definiert werden.

Hier gibt es nun zwei Varianten, wie die entsprechenden Rechte gesetzt werden können: Per ACL oder per Gruppen.

Rechte für mehrere Benutzer setzen – Variante 1: Per ACL

ACL (Access Control List) ergänzen das normale Rechtesystem von Linux. Man kann sich dies als zusätzliche „Schicht“ über dem normalen Rechtesystem vorstellen. Dies ist eine einfache Möglichkeit, Benutzern/Gruppen gezielt Zugriffsrechte auf Dateien und Verzeichnisse zu geben bzw. zu entziehen.

Hinweis: Beim Setzen der Rechte über ACLs gestaltet sich die Konfiguration der Netzwerk-Shares über Samba im weiteren Verlauf etwas einfacher. Daher ist dies meine bevorzugte Variante.

ACL wird während der Installation von Ubuntu Server automatisch installiert. Wenn dies nicht der Fall sein sollte, dann kann das zu einem späteren Zeitpunkt nachgeholt werden:

apt-get install acl

Nun können ACLs für das Verzeichnis gesetzt werden, auf das später beide Benutzer Zugriff haben sollen:

setfacl -R -d -m u:bob:rwx,u:alice:rwx /media/hdd1/networkshares/shared

Dieser Befehl bewirkt folgendes:

  • Die Rechte werden rekursiv gesetzt (-R).
  • Mittels -d wird ein Default gesetzt, der auch bei zukünftig angelegten Dateien und Verzeichnissen wirkt.
  • Mit dem Parameter -m werden evtl. bereits vorhandene Rechte modifiziert und nicht einfach überschrieben.
  • Die genauen Rechte für einen User werden z.B. durch u:bob:rwx gesetzt: Hier sollen die Benutzer Bob und Alice Vollzugriff auf das Verzeichnis haben.

Ein weiteres Setzen der Rechte über chown/chmod ist nicht erforderlich.

Rechte für mehrere Benutzer setzen – Variante 2: Per Gruppe

Für die zweite Variante nutzen wir Gruppen um die entsprechenden Rechte zu setzen.

Hinweis: Die Variante mit Gruppen macht die Einrichtung der Netzwerk-Shares später etwas komplizierter. Daher bevorzuge ich mittlerweile die erste Variante (ACL) zum Setzen der Rechte.

Beide Benutzer werden dazu in eine Gruppe aufgenommen. Dann wird der Gruppe die entsprechenden Besitzrechte gegeben und anschließend per chmod die passenden Zugriffsrechte gesetzt:

addgroup bobundalice
usermod -aG bobundalice bob
usermod -aG bobundalice alice
chown -R bob:bobundalice /media/hdd1/networkshares/shared
chmod -R 775 /media/hdd1/networkshares/shared

Samba Konfiguration

Bleibt eigentlich nur noch die Einrichtung des Samba-Servers. Die Konfiguration befindet sich in folgender Datei:

nano /etc/samba/smb.conf

Allgemeine Einstellungen

Zunächst werden in der Sektion [Global] ein paar Werte gesetzt. map to guest ist meist schon vorhanden, die anderen Werte werden einfach darunter eingefügt:

map to guest = never
security = user
encrypt passwords = true
invalid users root

Im einzelnen wird damit folgendes konfiguriert:

  • map to guest = never deaktiviert den Gast-Zugriff auf den Samba-Server. Ohne diese Einstellung könnte man sich am Samba-Server auch als Gast anmelden.
  • security = user gibt an, dass die Authentifizierung am Samba-Server mittels Username/Passwort erfolgt.
  • encrypt passwords = true sorgt dafür, dass Passwörter nur verschlüsselt übertragen werden.
  • invalid users root deaktiviert den Zugriff auf die Samba-Shares für den Root-User.

Weiter unten in der Konfigurations-Datei findet man Sektionen, mit den Drucker-Freigaben eingerichtet werden. Diese sind standardmäßig aktiv. Möchte man keine Drucker freigeben, dann kommentiert man die beiden Sektionen [printers] und [print$] am besten aus.

Freigabe für einen Benutzer

Bob und Alice sollen jeweils eine eigene Freigabe haben, auf die kein anderer Benutzer Zugriff hat. Dazu werden in der smb.conf ganz am Ende folgende Blöcke eingefügt:

[bob]
valid users = bob
path = /media/hdd1/networkshares/bob
guest ok = no
writeable = yes

[alice]
valid users = alice
path = /media/hdd1/networkshares/alice
guest ok = no
writeable = yes

Folgende Angaben sind hier zu machen:

  • [bob]: Der Sektions-Name legt fest, wie die Freigabe heißen soll.Über diesen Namen werden die Netzwerk-Shares dann später auf den Client-Rechnern eingerichtet.
  • valid users: Hier werden die Benutzer festgelegt, welche Zugriff auf die Freigabe haben sollen. Bei Einzel-Freigaben ist dies auch immer nur ein User.
  • path: Legt den lokalen Pfad fest, auf dem die Freigabe auf den lokalen Rechner liegen soll.
  • guest ok = no: Hiermit wird festgelegt, dass sich Gäste nicht auf diese Freigabe verbinden können.
  • writeable = yes: Dies wird nochmals explizit angegeben, dass der Benutzer unter valid users Schreibzugriff auf die Freigabe haben soll.

Freigabe für mehrere Benutzer – Variante 1: ACL

Bei den Freigaben für mehrere Benutzer gibt es wieder zwei Varianten, abhängig davon, wie zuvor die Rechte auf Dateisystem-Ebene gesetzt wurden (ACL oder Gruppen).

Ich bevorzuge das Setzen der Rechte per ACL. In diesem Fall sieht die Konfiguration der Freigabe folgendermaßen aus. Der Name der Freigabe lautet hier shared:

[shared]
valid users = bob alice
path = /media/hdd1/networkshares/shared
guest ok = no
writeable = yes

Wie man sieht, unterscheidet sich diese Variante kaum von der Einrichtung einer Freigabe für einen einzelnen User. Es werden lediglich mehrere Benutzer unter valid users angegeben.

Freigabe für mehrere Benutzer – Variante 2: Gruppen

Wenn keine ACLs gesetzt wurden, sondern beide Benutzer in eine Gruppe hinzugefügt wurden, müssen für das Konfigurieren der Freigabe ein paar zusätzliche Angaben gemacht werden:

[shared]
valid users = @bobundalice
path = /media/hdd1/networkshares/shared 
guest ok = no
write list = @bobundalice
directory mask = 0775
create mask = 0775

Folgendes gilt es hier zu beachten:

  • valid users: Hier wird die Gruppe der User angegeben, die Zugriff auf die Freigabe haben soll. Vor dem Gruppen-Namen muss dazu ein @ Symbol stehen.
  • write list: Hier wird wiederum die Gruppe angegeben, die Schreibzugriff auf die Freigabe haben soll.
  • directory mask/create mask: Hier werden die Datei- bzw. Verzeichnisrechte gesetzt, ähnlich wie beim Befehl chmod. Dies sorgt dafür, dass die Dateien mit den entsprechenden Rechten versehen werden, wenn diese (durch die Benutzer der Freigabe) erstellt werden.

Konfiguration der Freigaben abschließen

Damit wäre die Konfiguration von Samba abgeschlossen. Mit folgenden Befehlen wird die aktuelle Konfiguration getestet und Samba anschließend neu gestartet:

testparm
service smbd restart

Falls die Firewall ufw auf dem System aktiv ist, muss hier noch eine Freigabe für Samba erfolgen. Am einfachsten funktioniert dies mit einem Applikations-Filter:

ufw allow from 192.168.178.0/24 to any app Samba

In diesem Beispiel erfolgt die Freigabe nur für das lokale Netzwerk (192.168.178.0/24). Damit haben nur Clients innerhalb des gleichen Netzwerks Zugriff auf die Samba-Freigaben.

Einbinden der Netzwerk-Shares

Nach der Einrichtung von Samba können die Freigaben nun ganz einfach auf den Client-Rechnern eingebunden werden.

Linux

Unter Linux kann die Freigabe entweder temporär oder dauerhaft eingebunden werden.

Temporärer Zugriff auf die Freigaben per Datei-Manager

Auf die Freigaben kann man mit jedem Datei-Manager zugreifen, indem man in die Adressziele den SMB-Speicherort eingibt, z.B. smb://192.168.178.60.

Direkter Zugriff auf die Freigaben (Manjaro/Thunar)

Direkter Zugriff auf die Freigaben (Manjaro/Thunar)

Hier werden alle Freigaben angezeigt. Bei einem Zugriff muss dann noch die Eingabe von Username/Passwort erfolgen.

Temporäres Einbinden per Kommandozeile

Hier wird das Paket cifs-utils benötigt:

apt-get install cifs-utils

Damit nicht immer das Passwort beim Mounten der Freigabe eingegeben werden muss, sollte sich der entsprechende Nutzer in seinem Home-Verzeichnis eine Datei anlegen, in der Username und Passwort gespeichert ist:

cd ~
nano .smbcredentials

Der Inhalt der Datei ist dabei recht einfach:

username=<User>
password=<Password>

Auf diese Datei sollte nur der entsprechende User Zugriff haben:

sudo chmod 600 .smbcredentials

Als nächstes werden die Verzeichnisse angelegt, in die die Freigaben gemountet werden sollen:

mkdir -p /mnt/bob
mkdir -p /mnt/shared

Soll die Freigabe nun temporär gemountet werden, können dazu folgende Befehle genutzt werden:

mount -t cifs -o credentials=~/.smbcredentials //192.168.178.60/bob /mnt/bob
mount -t cifs -o credentials=~/.smbcredentials //192.168.178.60/shared /mnt/shared

Hier wird folgendes angegeben:

  • -o credentials=~/.smbcredentials: Hier werden Benutzername/Passwort mit der soeben angelegten Datei übergeben.
  • //192.168.178.60/bob: IP des Samba-Servers und Name der Freigabe, wie auf dem Samba-Server in der Datei smb.conf als Sektions-Name angegeben.
  • /mnt/bob: In diesen Ordner wird die Freigabe gemountet.

Ein Aushängen (unmount) der Freigabe kann folgendermaßen durchgeführt werden:

umount /mnt/bob

Auch nach einem Neustart des Systems ist die Freigabe aber wieder verschwunden.

Dauerhaftes Mounten per fstab

Die Freigaben können aber auch per fstab gemountet werden. Damit stehen die Freigaben dann direkt nach einem System-Neustart zur Verfügung:

nano /etc/fstab

Am Ende der Datei wird nun folgendes hinzugefügt (die bereits bestehenden Einträge in der Datei sollte man nicht verändern):

//192.168.178.60/bob /mnt/bob cifs credentials=/home/bob/.smbcredentials,noperm,_netdev,noauto,x-systemd.automount 0 0
//192.168.178.60/shared /mnt/shared cifs credentials=/home/bob/.smbcredentials,noperm,_netdev,noauto,x-systemd.automount 0 0

Das Einbinden erfolgt ähnlich wie schon beim temporären Einbinden, jedoch gibt es einige Unterschiede:

  • Die Pfadangabe für die Datei mit den Credentials muss absolut erfolgen.
  • Mit noperm wird angegeben, dass die Credentials nicht Client-seitig, sondern nur auf dem Server geprüft werden.
  • _netdev gibt an, dass der Mount abhängig von einer Netzwerk-Verbindung ist.
  • Die Parameter noauto,x-systemd.automount sorgen dafür, dass die Freigabe erst beim ersten Zugriff gemountet wird. Dies macht das Einbinden etwas effizienter.

Ob das Mounten erfolgreich durchgeführt werden kann, testet man anschließend mit folgendem Befehl (als Root-User):

mount -a

Nun stehen die Freigaben direkt nach dem Systemstart zur Verfügung.

Windows

Auch unter Windows kann man die Freigaben temporär oder dauerhaft einbinden.

Temporärer Zugriff auf die Freigaben per Explorer

Um im Explorer direkten Zugriff auf die Freigaben zu erhalten, gibt man einfach die entsprechende Adresse des Samba-Servers ein, z.B. \\192.168.178.60. Nach der Eingabe von Benutzername und Passwort werden die Freigaben angezeigt:

Direkter Zugriff auf die Freigaben (Windows)

Direkter Zugriff auf die Freigaben (Windows)

Dauerhaftes Einbinden unter Windows

Um die Eingaben dauerhaft einzubinden, nutzt man im Explorer einfach die Funktion Netzlaufwerk verbinden:

Windows: Netzlaufwerk verbinden

Windows: Netzlaufwerk verbinden

Im zweiten Schritt werden die Daten des Netzlaufwerks angegeben:

Windows: Verbindung mit Netzlaufwerk herstellen

Windows: Verbindung mit Netzlaufwerk herstellen

Neben dem zuzuweisenden Laufwerks-Buchstaben und dem Netzwerk-Pfad der Freigabe sollte die Option Verbindung mit anderen Anmeldeinformationen herstellen gewählt werden. Anschließend gibt man Benutzername und Passwort des Linux/Samba-Users an.

Fazit

Ein Samba-Server ist schnell auf einem Linux Server installiert. Die Konfiguration erfordert etwas Handarbeit. Gerade für Freigaben, die mehreren Benutzern zur Verfügung stehen sollen, sind zwei Varianten möglich (ACL und Bilden von Gruppen). Ich bevorzuge hier die Nutzung von ACLs, da das Konfigurieren der Freigaben bei Samba sehr viel einfacher erfolgen kann.

Wenn der Samba-Server fertig konfiguriert ist, steht dieser dauerhaft als Speicherort im Netzwerk zur Verfügung. Durch das weit verbreitete SMB-Protokoll können diese Freigaben dann auf beliebigen Systemen eingebunden werden.

Links

]]>
https://decatec.de/linux/samba-auf-ubuntu-server/feed/ 3
Nextcloud: Die eigenen Cloud auf neue Domain umziehen https://decatec.de/home-server/nextcloud-die-eigenen-cloud-auf-neue-domain-umziehen/ https://decatec.de/home-server/nextcloud-die-eigenen-cloud-auf-neue-domain-umziehen/#comments Thu, 16 May 2019 15:04:47 +0000 https://decatec.de/?p=5622 Nextcloud Logo

In diesem Artikel soll es um die Änderung der Domain einer bestehenden Nextcloud-Instanz gehen. Dies sollte zwar im Normalfall nicht notwendig sein, dennoch gibt es einige denkbare Szenarien, bei dem der Umzug auf eine andere Domain erforderlich sein kann.

Beispiel: Beim Self-Hosting kommt im privaten Bereich oftmals eine DynDNS-Adresse zum Einsatz. Einmal im Router eingerichtet, wird die DynDNS-Domain dann auf die (öffentliche) IP-Adresse des Routers gemappt. Folglich ist der eigene Server dann direkt aus dem Internet über die DynDNS-Domain erreichbar.

Allerdings ist man nun in gewissem Maße vom DynDNS-Anbieter abhängig. Ist ein solcher Dienst dann mal nicht verfügbar (z.B. durch technische Probleme beim Anbieter) oder wird komplett eingestellt (was bei kostenlosen Anbietern durchaus mal passieren kann), dann ist die eigenen Cloud nicht mehr aus dem Internet erreichbar.

Genau dann kann es erforderlich sein, den DynDNS-Provider zu wechseln, was meistens eine neue Domain für die Cloud bedeutet.

Update-Historie (letztes Update 17.08.2019)
  • 17.08.2019:
    • acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher wird für die Ausführung von acme.sh ein spezieller User angelegt.
  • 18.05.2019:
    • dynv6 als weiteren empfohlenen DynDNS-Dienst hinzugefügt.

 

Voraussetzungen

Als Basis dient folgendes System:

  • Betriebssystem: Ubuntu Server 18.04
  • Webserver: nginx
  • Let’s Encrypt Client: acme.sh
  • Nextcloud 16

Allerdings können auch andere Distributionen, Webserver und Let’s Encrypt Clients zum Einsatz kommen. Die gezeigten Schritte sind also generell auch auf andere Systeme übertragbar, auch wenn hier ggf. Anpassungen an die jeweilige Umgebung erfolgen muss.

Ich gehe im folgenden davon aus, dass das bestehende Nextcloud-Setup voll funktionsfähig ist und nur auf eine andere Domain umgezogen werden soll. Grundlage dafür ist der Artikel Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban.

Für die Generierung der HTTPS-Zertifikate nutze ich das Shell-Script acme.sh, mehr Infos dazu findet man im Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx. Ebenfalls nutze ich hier sowohl RSA- als auch ECDSA-Zertifikate („hybrid“). Was es damit auf sich hat, findet man im Artikel RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung).

Wie immer empfiehlt es sich, vor Änderungen an Nextcloud ein komplettes Backup der Cloud vorzunehmen. Mehr Informationen zu dem Thema findet man im Artikel Nextcloud: Backups erstellen und wiederherstellen – manuell oder per Skript.

Die neue Domain

Die Cloud soll also umgezogen werden? Ein Backup ist erstellt? Dann kann es losgehen…

Im Rahmen des Artikels nutze ich beispielhaft die Domains alt.meinedomain.de und neu.meinedomain.de. Damit ist jederzeit klar, welche Domain (alt oder neu) gerade gemeint ist.

Zunächst braucht man jedoch überhaupt eine neue Domain, die man als DynDNS-Domain verwenden kann. Dazu gibt es sog. DynDNS-Dienste. Viele davon sind kostenlos, einige verlangen einen geringen Preis für ihre Dienste. Es gibt auch Webspace-Provider, die die Möglichkeit bieten, Domains als DynDNS-Domains zu deklarieren. Ein (aus eigener Erfahrung) empfehlenswerter Anbieter ist hier All-Inkl.com (Affiliate Link) (ab dem Paket „Privat Plus“).

Bei den kostenlosen DynDNS-Diensten gibt es mittlerweile sehr viele Anbieter. Aus Gründen des Datenschutzes sollte man bei der Auswahl darauf achten, Anbieter mit Serverstandort Deutschland zu wählen.
Meiner Meinung nach sind beispielsweise folgende Anbieter empfehlenswert:

Zum Thema kostenlos vs. kostenpflichtig: Die meisten kostenlosen DynDNS-Dienste werden privat, oder durch kleine Vereine/Unternehmen betreut. Hier kann es passieren, dass ein Dienst mal eine Zeit lang (z.B. durch eine technische Störung) nicht erreichbar ist und es ein paar Stunden oder gar Tage dauert, bis wieder alles wie gewohnt funktioniert. Auch könnten solche Dienste einfach vom einen auf den anderen Tag eingestellt werden.
Bei kostenpflichtigen Diensten gibt es meist einen (professionellen) Support, der im Fehlerfall auch schnell helfen kann. Auch ist es hier unwahrscheinlich, dass ein solcher Dienst von heute auf morgen einfach eingestellt wird.
Das soll nun aber keineswegs heißen, dass man mit kostenpflichtigen DynDNS-Diensten besser bedient ist als mit kostenlosen Diensten. Auch kostenlose DynDNS-Anbieter können eine hohe Verfügbarkeit und einen guten Support bieten.

Neue Domain im Router hinterlegen

Wenn eine neue Domain vorliegt, muss diese erst einmal als neue DynDNS-Domain im Router hinterlegt werden. Leider hängt das genaue Vorgehen sowohl von Marke/Modell des Routers, als auch vom DnyDNS-Domain-Provider ab, so dass ich hier keine detaillierte Beschreibung liefern kann.

Wichtig ist, dass nach dieser Änderung sämtliche Webdienste (v.a. Nextcloud) nicht mehr über die alte Domain erreichbar sind.

Für produktive Nextcloud-Instanzen sollte man hier im Vorfeld die Benutzer darauf aufmerksam machen, dass ein Domain-Umzug stattfindet und die Cloud für einen gewissen Zeitraum nicht mehr erreichbar ist. Recht komfortabel kann man die mit der Nextcloud-App Announcement center lösen, indem man als Administrator eine Benachrichtigung an alle Cloud-User schickt.

Hier ist es generell empfehlenswert, die Nextcloud direkt vor dem Domain-Umzug in den Maintenance-Mode zu versetzten. Das sorgt dafür, dass keine Verbindungen zur Cloud möglich sind und beugt Datenverlusten vor, wenn Cloud-Benutzer gerade aktiv mit der Cloud arbeiten:

sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --on

Neue Domain im Webserver hinterlegen und HTTPS-Zertifikate erzeugen

Also nächstes müssen die vHost(s) von nginx so konfiguriert werden, dass diese auf den neuen Domain-Namen hören. Angepasst werden muss hier nur der Gateway-Host:

nano /etc/nginx/conf.d/meinedomain.de.conf

Hier muss die Variable server_name auf den neuen Domain-Namen angepasst werden:

server_name neu.meinedomain.de 192.168.178.60;

Dies muss sowohl im server-Block für HTTP, als auch im server-Block für HTTPS angepasst werden.

Anschließend wird der Webserver neu gestartet:

service nginx restart

Hier sollten keine Fehlermeldungen angezeigt werden.

Anschließend muss das Let’s Encrypt-Zertifikat für die neue Domain erzeugt werden.

Hinweis: acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher sollte ein spezieller User eingerichtet werden, mit dem die Zertifikate generiert/verwaltet werden. Wie hierfür vorzugehen ist, kann dem Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx entnommen werden.

Diesen Befehl am besten kopieren und mittels Suchen und Ersetzen in einem beliebigen Texteditor die eigene Domain einfügen – das beugt Tippfehlern vor:

acme.sh --issue -d neu.meinedomain.de --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/neu.meinedomain.de/key.pem --ca-file /etc/letsencrypt/neu.meinedomain.de/ca.pem --cert-file /etc/letsencrypt/neu.meinedomain.de/cert.pem --fullchain-file /etc/letsencrypt/neu.meinedomain.de/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Wenn RSA und ECDSA-Zertifikate parallel eingesetzt werden sollen, dann ist der Befehl nochmals für ECDSA zu wiederholen:

acme.sh --issue -d neu.meinedomain.de --keylength ec-384 -w /var/www/letsencrypt --key-file /etc/letsencrypt/neu.meinedomain.de/key.pem --ca-file /etc/letsencrypt/neu.meinedomain.de/ca.pem --cert-file /etc/letsencrypt/neu.meinedomain.de/cert.pem --fullchain-file /etc/letsencrypt/neu.meinedomain.de/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Zum Schluss müssen die neuen Zertifikate noch dem Webserver bekannt gemacht werden. Dazu wird die Datei editiert, mit der auf die Zertifikate für den vHost verwiesen wird. Ich nutze hier eine spezielle Datei, in der alle SSL-Einstellungen enthalten sind, diese können aber auch direkt im Gateway-Host enthalten sein.

nano /etc/nginx/snippets/ssl.conf

Hier werden einfach die neuen Zertifikate angegeben:

# Certificates used
# RSA
ssl_certificate /etc/letsencrypt/neu.meinedomain.de/rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/neu.meinedomain.de/rsa/key.pem;
 
# ECC
ssl_certificate /etc/letsencrypt/neu.meinedomain.de/ecc/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/neu.meinedomain.de/ecc/key.pem;
 
# This should be ca.pem (certificate with the additional intermediate certificate)
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/letsencrypt/neu.meinedomain.de/ecc/ca.pem;
 
# Diffie-Hellman parameter, recommended 4096 bits
ssl_dhparam /etc/nginx/dhparams/dhparams.pem;

Wie schon zuvor: Wenn sowohl RSA- als auch ECDSA-Zertifikate genutzt werden, sind beide Varianten anzugeben.

Im Listing ist auch die Einbindung der Diffie-Hellman-Parameter zu sehen. Diese müssen bei einem Domain-Umzug nicht neu erzeugt werden, sondern können wiederverwendet werden.

Nach diesen Änderungen ist der Webserver neu zu starten:

service nginx restart

Der Webserver ist nun für den Domain-Umzug vorbereitet, nun kann es mit der Nextcloud-Konfiguration weitergehen.

Nextcloud für neue Domain konfigurieren

Neben der Anpassung des Webservers sind ebenfalls Änderungen in Nextcloud durchzuführen.

Hierzu öffnet man einfach die config.php von Nextcloud:

nano /var/www/nextcloud/config/config.php

Prinzipiell sind hier alle Werte anzupassen, die auf die alte Domain verweisen. Hier wird dementsprechend der neue Domain-Name gesetzt. Meistens sind das die folgenden zwei Variablen: trusted_domains und overwrite.cli.url:

<span class="s1">'overwrite.cli.url'</span> <span class="o">=&gt;</span> <span class="s1">''</span><span class="p">,</span>

'trusted_domains' =>
  array (
    '192.168.178.60',
    'neu.meinedomain.de',
  ),
'overwrite.cli.url' => 'neu.meinedomain.de',

Nun ist es an der Zeit, den Maintenance-Mode der Nextcloud wieder zu deaktivieren, damit die Cloud wieder im Internet erreichbar ist:

sudo -u www-data php /var/www/nextcloud/occ maintenance:mode --off

Mit einem Aufruf der Nextcloud im Browser sollten nun keine Fehlermeldungen erscheinen. Ebenso sollte man einen kurzen Blick in die Admin-Oberfläche der Cloud werfen (Einstellungen > Verwaltung > Übersicht). Unter Sicherheits- & Einrichtungswarnungen sollten keine Warnungen angezeigt werden.

In der Nextcloud Admin-Oberfläche sollten keine Warnungen angezeigt werden

In der Nextcloud Admin-Oberfläche sollten keine Warnungen angezeigt werden

Auch im Nextcloud-Log (Einstellungen > Verwaltung > Protokollierung) sollten keine Meldungen bzgl. der neuen Domain zu finden sein.

Damit der der Domain-Umzug erst einmal abgeschlossen.

Abschließende Tätigkeiten

Nach dem erfolgreichen Domain-Umzug ist es wichtig, dass alle Clients ab sofort nur noch die neue Domain nutzen können. Somit müssen sämtliche Clients aller Benutzer der Nexcloud-Instanz auf die neue Domain umgestellt werden. Hier sollte man als Admin mit erhöhtem „Support-Aufkommen“ rechnen.

Wenn dies erledigt ist und man sicher ist, dass die alten Zertifikate nicht mehr gebraucht werden, dann können die Zertifikate der alten Domain vom Server entfernt werden. Mit folgendem Befehl sollten zunächst sowohl die neuen, als auch noch die alten Zertifikate angezeigt werden:

acme.sh --list

Diese alten Zertifikate können nun entfernt werden:

acme.sh --remove -d alt.meinedomain.de

Wenn neben RSA-Zertifikaten auch ECDSA-Zertifikate zum Einsatz kommen, muss das ECDSA-Zertifikat separat entfernt werden:

acme.sh --remove -d alt.meinedomain.de --ecc

Nach der Ausführung dieser Befehle ist das Zertifikat acme.sh nicht mehr bekannt und es wird auch nicht mehr per Cronjob erneuert. Die Zertifikats-Dateien verbleiben jedoch noch auf der Festplatte des Systems. in welchem Verzeichnis die nicht mehr genutzten Zertifikate liegen, zeigt acme.sh beim Entfernen der Zertifikate an (z.B. /etc/letsencrypt/alt.meinedomain.de). Dieses Verzeichnis kann anschließend entfernt werden:

rm -r /etc/letsencrypt/alt.meinedomain.de

Eine erneute Auflistung der installierten Zertifikate über den List-Befehl von acme.sh sollte nun nur noch das neue Zertifikat anzeigen.

Fazit

Der Artikel hat gezeigt, wie man die eigene Cloud in wenigen Schritten auf eine neue Domain umziehen kann. Das sollte im Normalfall eigentlich nicht notwendig sein, aber wenn wirklich mal eine neue Domain benötigt wird, dann braucht man Nextcloud nicht nochmals komplett neu aufsetzen. Das spart dem Admin Arbeit und die Benutzer können ihre gewohnte Nextcloud-Umgebung weiterhin nutzen – lediglich unter einer neuen Domain.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-die-eigenen-cloud-auf-neue-domain-umziehen/feed/ 4
Eigener Firefox Sync Server mit nginx https://decatec.de/home-server/eigener-firefox-sync-server-mit-nginx/ https://decatec.de/home-server/eigener-firefox-sync-server-mit-nginx/#comments Thu, 02 May 2019 13:17:44 +0000 https://decatec.de/?p=5492 Firefox Logo

Ein Browser ist auf fast allen Plattformen wohl das am meisten genutzte Programm. Nach den Browserkriegen sind leider viele Browser auf der Strecke geblieben, so dass es heutzutage nur noch zwei ernstzunehmende Alternativen gibt: Firefox und Chrome.

Wer Wert auf Datenschutz und Privatsphäre legt, wird allerdings um Chrome einen großen Bogen machen und stattdessen lieber Firefox nutzen.

Firefox bietet schon sehr lange ein Feature mit dem alle Browser-Einstellungen in der Cloud synchronisiert werden: Firefox Sync. Dazu wird ein Firefox-Konto benötigt, mit dem man sich im Browser einloggt. Anschließend können alle Firefox-Einstellungen (Lesezeichen, Chronik, verwendete Addons, etc.) mit der Mozilla-Cloud synchronisiert werden und sind so auch auf mehreren Endgeräten immer auf dem aktuellsten Stand.

Damit vertraut man der Mozilla Foundation seine Daten an. Die Speicherung erfolgt dabei meistens auf US-Servern. Wer dies nicht möchte, kann zunächst einmal keine Synchronisierung bei Firefox verwenden, so dass alle Einstellungen und Addons mit jeder Browser-Installation immer manuell konfiguriert werden müssen.

Allerdings kann man auch auf dem eigenen Server einen Firefox Sync Server installieren und über diesen synchronisieren. In diesem Fall profitiert man von den Sync-Funktionen des Browsers und stellt sicher, dass alle Daten nur auf dem privaten Server gespeichert werden.

Dieser Artikel zeigt nun die Installation und Konfiguration eines eigenen Firefox Sync Servers.

Hinweis: Dieser Artikel ist eher etwas für Fortgeschrittene. Den Firefox Sync Server kann man nicht einfach installieren, sondern dieser muss erst aus dem entsprechenden Repository auf GitHub gecloned und anschließend selbst gebaut werden. Auch die Konfiguration ist alles andere als trivial. Daher sollte man schon etwas Erfahrung mit Linux mitbringen.

Übrigens: Wem es hauptsächlich nur um die Synchronisierung von Lesezeichen im Browser geht, der muss nicht unbedingt einen eigenen Firefox Sync Server betreiben. In diesem Fall können bei einer vorhandenen Nextcloud-Instanz die Lesezeichen auch einfach über die private Cloud synchronisiert werden. Wie das genau funktioniert, wurde bereits in einem anderen Artikel erklärt: Nextcloud: Lesezeichen synchronisieren mit Chrome/Firefox

Update-Historie (letztes Update 08.05.2019)
  • 08.05.2019:
    • Hinwies hinzugefügt, dass die Angabe eines eigenen Sync Servers für Firefox auf iOS nicht funktioniert (siehe hier).
  • 05.05.2019:
    • Ergänzende Informationen hinzugefügt, falls andere Datenbank-Systeme für den Sync Server zum Einsatz kommen sollen (PostgreSQL oder MySQL/MariaDB).

 

Voraussetzungen

Alle Schritte wurden mit Ubuntu Server 18.04 LTS durchgeführt, sollten aber auch mit anderen Distributionen funktionieren.

Voraussetzung ist auf jeden Fall ein bereits fertig konfigurierter Webserver (in diesem Fall nginx). Dieser muss bereits so eingerichtet sein, dass Verbindungen mittels HTTPS möglich sind.

Die gezeigte Konfiguration basiert darauf, dass der Firefox Sync Server auf einer eigenen Subdomain (firefox-sync.meinedomain.de) betrieben wird. Es ist allerdings auch möglich, den Server in einem Unterverzeichnis des Webservers zu betreiben (z.B. meinedomain.de/firefox-sync). Hier unterscheidet sich lediglich die Webserver-Konfiguration (vHost). Dies wird im Abschnitt über die Webserver-Konfiguration behandelt.

Da eine detaillierte Beschreibung der Webserver-Konfiguration den Rahmen des Artikels sprengen würde, verweise ich an dieser Stelle auf weitere Artikel, die für das Thema relevant sind:

Installation

Wie bereits erwähnt, kann der Firefox Sync Server nicht einfach über die Paketverwaltung installiert werden, sondern es sind einige manuelle Handgriffe notwendig.

Wir beginnen wie üblich damit, das System auf den neusten Stand zu bringen:

apt-get update && apt-get upgrade -V

Anschließend werden die Pakete installiert, die wir zum Bauen des Sync Servers benötigen:

apt-get install make python-dev git-core python-virtualenv g++

Nun wird das entsprechende GitHub-Repository gecloned und der Sync Server gebaut:

cd /opt
git clone https://github.com/mozilla-services/syncserver
cd syncserver
make build

Die Dateien für den Sync Server liegen dann unter /opt/syncserver.

Konfiguration

Nun geht es an die Konfiguration des Sync Servers.

Als erstes benötigen wir ein „Secret“, welches dann später in der Konfiguration angegeben wird. Auch wenn es so wirkt: Dieser Schritt ist nicht optional, ohne Angabe des Secrets wird der Sync Server später nicht funktionieren.
Um das Secret zu erzeugen, nutzen wir einfach folgenden Befehl (anschließend in die Zwischenablage kopieren):

head -c 20 /dev/urandom | sha1sum

Danach kann es auch schon an die Bearbeitung der Konfiguration gehen:

cd /opt/syncserver
nano syncserver.ini

Hier zunächst die komplette Datei zur Übersicht:

[server:main]
use = egg:gunicorn
host = 127.0.0.1
port = 5000
workers = 1
timeout = 30

[app:main]
use = egg:syncserver

[syncserver]
# This must be edited to point to the public URL of your server,
# i.e. the URL as seen by Firefox.
public_url = https://firefox-sync.meinedomain.de

# By default, syncserver will accept identity assertions issued by
# any BrowserID issuer.  The line below restricts it to accept assertions
# from just the production Firefox Account servers.  If you are hosting
# your own account server, put its public URL here instead.
identity_provider = https://accounts.firefox.com/

# This defines the database in which to store all server data.
sqluri = sqlite:////opt/syncserver/syncserver.db

# This is a secret key used for signing authentication tokens.
# It should be long and randomly-generated.
# The following command will give a suitable value on *nix systems:
#
#    head -c 20 /dev/urandom | sha1sum
#
# If not specified then the server will generate a temporary one at startup.
secret = b6ff9a32108ca32272bcf8322b5274e93031fb90

# Set this to "false" to disable new-user signups on the server.
# Only requests by existing accounts will be honoured.
# allow_new_users = true

# Set this to "true" to work around a mismatch between public_url and
# the application URL as seen by python, which can happen in certain reverse-
# proxy hosting setups.  It will overwrite the WSGI environ dict with the
# details from public_url.  This could have security implications if e.g.
# you tell the app that it's on HTTPS but it's really on HTTP, so it should
# only be used as a last resort and after careful checking of server config.
force_wsgi_environ = true

Erläuterungen zu den einzelnen Einstellungen:

  • host = 127.0.0.1: Sorgt dafür, dass der Sync Server nur lokal aufgerufen werden kann – die Kommunikation „nach außen“ übernimmt später ja nginx.
  • public_url = https://firefox-sync.meinedomain.de: Dies ist die öffentliche URL des Sync Servers. Die konkrete URL hängt dabei von der Webserver-Konfiguration ab (siehe nächster Abschnitt).
  • identity_provider = https://accounts.firefox.com/: Zur Authentifizierung wird ein vorhandener Firefox-Account eingesetzt.
  • sqluri = sqlite:////opt/syncserver/syncserver.db: Angabe der Datenbank, in der die synchonisierten Objekte gespeichert werden. Hier verwenden wir einfach eine SQLite Datenbank, es wäre aber auch möglich, eine PostgreSQL oder MySQL/MariaDB Datenbank zu verwenden (Erläuterungen siehe unten).
  • secret = b6ff9a32108ca32272bcf8322b5274e93031fb90: Hier wird einfach der Wert eingetragen, den wir gerade über die Kommandozeile generiert haben.
  • allow_new_users = true: Dies sorgt dafür, dass automatisch neue Benutzerkonten angelegt werden, wenn sich diese zum erstem Mal mit diesem Sync Server verbinden. Wenn dieser Wert auf false gesetzt wird, wird die Synchronisierung für neue Accounts nicht mehr funktionieren (dazu später mehr).
  • force_wsgi_environ = true: Diese Einstellung muss in der gezeigten Konfiguration auf true gesetzt werden und sogt dafür, dass der Sync Server auch dann noch funktioniert, wenn die Public URL (die über nginx konfiguriert wird) von der URL abweicht, die der Sync Server intern „sieht“. Durch die Verwendung von nginx als Proxy für den Sync Server werden diese beiden URLs in diesem Kontext nie gleich sein, daher muss der Wert an dieser Stelle angepasst werden.

Ergänzende Informationen bei anderen Datenbanken

Für kleinere Sync Server Instanzen reicht die SQLite-Datenbank vollkommen aus. Ebenso ist diese am einfachsten zu konfigurieren, da hier keine zusätzlichen Schritte erforderlich sind.

Allerdings können auch andere Datenbank-Systeme zum Speichern der Daten eingesetzt werden, z.B. PostgreSQL oder MySQL/MariaDB. Empfehlenswert dürfte dies nur bei Servern sein, die sehr viele Nutzer bedienen müssen, oder wenn das entsprechende Datenbank-System bereits auf dem Server installiert ist. Aus diesem Grund gehe ich bei den folgenden Schritten davon aus, dass PostgreSQL bzw. MySQL/MariaDB bereits auf dem System installiert und konfiguriert ist.

PostgreSQL

Um eine Verbindung zu PostgreSQL herstellen zu können, sind ein paar zusätzliche Programme zu installieren:

apt-get install postgresql-server-dev-10 python-pip
cd /opt/syncserver
./local/bin/pip install psycopg2

Nun muss noch eine Datenbank speziell für den Sync Server erstellt werden. Am besten geschieht das über die PostgreSQL Kommandozeile:

sudo -u postgres psql

Die Datenbank mit dem entsprechenden User wird dann folgendermaßen angelegt:

CREATE USER firefox_sync_db_user WITH PASSWORD 'MeInPaSsw0rT';
CREATE DATABASE firefox_sync_db WITH OWNER firefox_sync_db_user TEMPLATE template0 ENCODING 'UTF8'

Beendet wird die PostgreSQL Kommandozeile durch die Eingabe von /q.

In der syncserver.ini wird die Verbindung zur Datenbank dann mittels dieser Einstellung konfiguriert:

sqluri = postgresql://firefox_sync_db_user:MeInPaSsw0rT@localhost/firefox_sync_db

MySQL/MariaDB

Ähnliche Schritte sind durchzuführen, wenn MySQL/MariaDB zum Einsatz kommt:

apt-get install python-pip
cd /opt/syncserver
./local/bin/pip install PyMySQL

Anschließend öffnet man die MySQL-Kommandozeile:

mysql -u root -p

Nun folgt die Anlage der Datenbank:

CREATE USER firefox_sync_db_user@localhost IDENTIFIED BY 'MeInPaSsw0rT';
CREATE DATABASE firefox_sync_db CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
GRANT ALL PRIVILEGES on firefox_sync_db.* to firefox_sync_db_user@localhost;
FLUSH privileges;
exit;

In der syncserver.ini wird die Datanbnak dann folgendermaßen angesprochen:

sqluri = pymysql://firefox_sync_db_user:MeInPaSsw0rT@localhost/firefox_sync_db

Webserver konfigurieren

Bevor das System nun einsatzfähig ist, muss zunächst noch der Webserver entsprechend konfiguriert werden. Die genauen Details zur Konfiguration des Webservers würden leider den Rahmen des Artikels sprengen, daher erwähne ich hier nur zwei mögliche Webserver-Konfigurationen.

Wichtig ist hier nur, dass der Webserver bereits so konfiguriert ist, dass dieser mittels HTTPS angesprochen werden kann und die Verbindung damit stets verschlüsselt ist.

Nach der Anpassung des Webserver muss dieser in jedem Fall noch neu gestartet werden:

service nginx restart

Wichtig: Je nach verwendeter Konfiguration unterscheidet sich die URL, unter der der Sync Server erreichbar ist. Dies muss im weiteren Verlauf des Tutorials beachtet werden, da entsprechende URLs angepasst werden müssen.

Sync Server mit eigener Subdomain

Wenn der Sync Server mit einer eigenen Subdomain betrieben werden soll (https://firefox-sync.meinedomain.de), dann benötigt man einen separaten vHost, der für diese Subdomain verantwortlich ist.

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name firefox-sync.meinedomain.de;

        root /var/www;

	location / {
		return 301 https://$host$request_uri;
	}
}

server {
        listen 443 ssl http2;
        listen [::]:443 ssl http2;
        server_name firefox-sync.meinedomain.de;

        # Include SSL configuration (and certificates)
        include /etc/nginx/snippets/ssl.conf;

	# Include headers
        include /etc/nginx/snippets/headers.conf;

        #
        # Configuration for Firefox Sync Server
        #

        location / {
		proxy_set_header Host $http_host;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_redirect off;
                proxy_read_timeout 120;
                proxy_connect_timeout 10;
                proxy_pass http://127.0.0.1:5000/;
        }
}

Sync Server in einem Unterverzeichnis des Webservers

Man kann den Sync Server allerdings auch in einem Unterverzeichnis einer bereits bestehenden (Sub-)Domain installieren. Die URL lautet dann beispielsweise https://meindomain.de/firefox-sync

Hierzu muss ein bereits bestehender vHost, der für die Domain meinedomain.de verantworlich ist, um folgenden location-Block erweitert werden. Die hinzuzufügenden Zeilen sind hier markiert:

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;
	server_name meinedomain.de;

	# Include SSL configuration
	include /etc/nginx/snippets/certs_pub.conf;
	include /etc/nginx/snippets/ssl.conf;

	# Include headers
	include /etc/nginx/snippets/headers.conf;

	location ^~ /firefox-sync/ {
		proxy_set_header Host $http_host;
		proxy_set_header X-Forwarded-Proto $scheme;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_redirect off;
		proxy_read_timeout 120;
		proxy_connect_timeout 10;
		proxy_pass http://127.0.0.1:5000/;
	}
}

Sync Server starten

Manueller Start

Nun kann der Sync Server über folgenden Befehl gestartet werden:

cd /opt/syncserver
make serve

Hier sollten keine Fehler angezeigt werden. Die Anzeige ist allerdings „live“, d.h. es scheint erst einmal so, als ob nichts weiter passieren würde:

./local/bin/gunicorn –paste ./syncserver.ini
[2019-04-27 17:23:21 +0000] [2292] [INFO] Starting gunicorn 19.6.0
[2019-04-27 17:23:21 +0000] [2292] [INFO] Listening at: http://127.0.0.1:5000 (2292)
[2019-04-27 17:23:21 +0000] [2292] [INFO] Using worker: sync
[2019-04-27 17:23:21 +0000] [2296] [INFO] Booting worker with pid: 2296

Daher stoppen wir nach diesem kurzen Test den Prozess mit STRG+C.

Nun ist es natürlich nicht optimal, wenn man den Sync Server immer manuell starten muss und dieser dann immer die Konsole blockiert. Hier könnte man sich zwar mit einem Screen weiterhelfen, aber das ist auch nicht die beste Lösung. Der Sync Server sollte im Idealfall direkt bei Systemstart automatisch mitgestartet werden.

Autostart

Um dies zu erreichen, legen wir zunächst einen eigenen User für den Sync Server an:

useradd firefox-sync -s /bin/false --no-create-home

Dieser User muss der Owner des Programmverzeichnisses sein:

chown -R firefox-sync:firefox-sync /opt/syncserver

Nun kann auch schon eine systemd Unit angelegt werden:

nano /etc/systemd/system/firefox-sync.service

Mit folgenden Zeilen wird die Unit definiert:

[Unit]
Description=Firefox Sync Server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
User=firefox-sync
Group=firefox-sync
Umask=007
Restart=on-abort
ExecStart=/opt/syncserver/local/bin/gunicorn --paste /opt/syncserver/syncserver.ini

[Install]
WantedBy=multi-user.target

Nun sollte der Service über folgenden Befehl gestartet werden können (anschließend mit service firefox-sync status testen):

service firefox-sync start

Damit der Service nun immer automatisch bei Systemstart hochgefahren wird, ist noch ein Befehl notwendig:

systemctl enable firefox-sync

Am besten auch hier nochmal das System neu starten und dann mit service firefox-sync status prüfen, ob der Autostart auch wirklich klappt.

Browser-Konfiguration

Bevor nun Firefox den neuen Sync Server nutzen kann, sollte noch ein kurzer Test erfolgen, ob der Sync Server wie gewünscht zu erreichen ist. Dazu einfach die URL des eigenen Sync Servers in die Adress-Leiste des Browsers eingeben (https://firefox-sync.meinedomain.de). Der Browser sollte dies mit einer simplen Meldung „it works!“ quittieren. Wenn es noch nicht wie erwartet funktioniert, wird eine Meldung ausgegeben, die einen Hinweis auf das Problem liefern sollte. In diesem Fall muss zunächst dieses Problem beseitigt werden, da ansonsten kein Browser mit dem Sync Server synchronisieren kann.

Wenn der Sync Server einwandfrei läuft, kann man nun Firefox so konfigurieren, dass dieser auch den eigenen Sync Server nutzt.

Wenn der Browser schon über ein Firefox-Konto synchronisiert wurde, muss die Verknüpfung mit diesem Konto zunächst einmal getrennt werden, da sich ansonsten kein neuer Sync Server konfigurieren lässt. Dazu einfach in die Browser-Einstellungen gehen, unter Firefox-Konto findet man die Schaltfläche zum Trennen des Kontos.

Nun fragt Firefox, ob er die bereits synchronisierten Daten  auch lokal entfernen soll. Hier sollte man keine Optionen anhaken, sondern einfach nur auf Nur trennen klicken.

Die Verbindung zum Firefox-Konto wird erst einmal getrennt

Die Verbindung zum Firefox-Konto wird erst einmal getrennt

Für die Angabe des eigenen Sync Servers muss man nun in die erweiterte Browser-Konfiguration wechseln, indem man in der Adress-Leiste about:config eingibt.

Hier suchen wir nun nach folgendem Wert: identity.sync.tokenserver.uri

Mit einem Doppelklick kann der Wert geändert werden und wir geben hier die URL des eigenen Sync Servers an: https://firefox-sync.meinedomain.de/token/1.0/sync/1.5

Über about:config wird der eigene Sync-Server angegeben

Über about:config wird der eigene Sync-Server angegeben

Wichtig ist, dass neben der eigentlichen Domain, die man in der syncserver.ini angegeben hat, noch die Erweiterung token/1.0/sync/1.5 notwendig ist.

Nachdem die Einstellung gesetzt ist, muss der Browser kurz beendet und neu gestartet werden. Nun kann man wieder in die Account-Einstellungen in Firefox gehen und die Verbindung zum Firefox-Konto wieder herstellen. Der Account an sich ist dabei der gleiche, aber der verwendete Sync Server ist nun ein anderer.

Nach ein paar Augenblicken sollte die erste Synchronisierung erfolgreich durchgelaufen sein. Allerdings erhält man keine Fehlermeldung, wenn der Sync aus irgendeinem Grund nicht klappen sollte. Daher gibt man am besten nach der ersten Synchronisierung about:sync-log in die Adress-Zeile des Browsers ein. Hier sollten dann keine Einträge zu finden sein, die zeitlich zur ersten Synchronisierung passen.

Falls doch, kann man dem Eintrag öffnen und Firefox gibt technische Details zu diesem Fehler preis. Damit sollte man den Fehler dann weiter eingrenzen können.

Diese Schritte zur Verbindung vom Firefox zum eigenen Sync Server müssen dann auf allen Rechnern wiederholt werden, damit nur noch der eigene Sync Server genutzt wird.

Auf Mobilgeräten (z.B. Firefox auf Android) funktioniert das Vorgehen übrigens analog: Firefox-Konto trennen, about:config bearbeiten und erneut mit dem Firefox-Konto anmelden. Leider funktioniert die Angabe eines eigenen Sync Servers unter Firefox für iOS (noch) nicht (siehe hier).
Die mobile Version von Firefox zeigt hier übrigens in den Einstellungen Details zum verwendeten Sync Server an (bei Firefox für den Desktop ist das leider nicht der Fall).

Firefox auf Android zeigt die URL des verwendeten Sync Servers an

Firefox auf Android zeigt die URL des verwendeten Sync Servers an

Abschließende Schritte

Wenn man nun alle Firefox-Konten auf den eigenen Sync Server umgehoben hat, sollten noch ein paar Schritte durchgeführt werden.

Sync Server auf bekannte Accounts beschränken

Der Sync Server wäre nun öffentlich über das Internet erreichbar. Damit niemand sonst den Server nutzen kann, wird das Anlegen neuer User im Sync Server einfach unterbunden:

cd /opt/syncserver
nano syncserver.ini

Hier ändern wir einfach den entsprechenden Konfig-Eintrag:

allow_new_users = false

Ab jetzt können sich keine neuen Accounts mehr am Sync Server anmelden. Wenn man hier nachträglich doch noch andere Firefox-Accounts hinzufügen möchte (z.B. für Familienmitglieder), dann muss man diesen Wert natürlich temporär wieder auf true ändern.

Abschließend wird der Sync Server neu gestartet:

service firefox-sync restart

Daten auf den Mozilla-Servern entfernen

Ganz zum Schluss kann man ebenfalls sämtliche Daten von den Mozilla-Servern entfernen. Hier kann ein einfaches Script genutzt werden. Wenn die Zwei-Faktor-Authentifizierung für den Firefox-Account aktiv ist, muss diese zuvor alledings deaktiviert werden, da das Skript ansonsten auf Fehler läuft. Nach dem Ausführen des Skripts kann diese wieder aktiviert werden.

apt-get update && apt-get install python-pip
cd /opt/syncserver
pip install PyFxA
python ./bin/delete_user_data.py meine@email.de

Die E-Mail-Adresse muss natürlich die Adresse des eigenen Mozilla-Accounts sein.

Sync Server updaten

Von Zeit zu Zeit können Updates für den Sync Server erscheinen. In diesem Fall kann man das Update auch lokal „nachziehen“.

Zunächst wird dazu der Service gestoppt:

service firefox-sync stop

Da Update an sich funktioniert dann wieder über git:

cd /opt/syncserver
git stash
git pull
git stash pop
make build

Nun werden noch die Rechte entsprechend angepasst:

chown -R firefox-sync:firefox-sync /opt/syncserver

Der Service sollte sich danach problemlos mit service firefox-sync start gestartet werden können. Auch das automatische Starten nach Systemstart sollte weiterhin funktionieren.

Fazit

Zugegeben: Die Einrichtung eines eigenen Firefox Sync Servers ist nicht gerade einfach, da dieser nicht einfach aus der Paketverwaltung der verwendeten Distribution installiert werden kann. Da ist schon einiges an Handarbeit notwendig.

Wenn man die Schritte durchgearbeitet hat, kann man aber sicher sein, dass die Browser-Daten nicht mehr in „irgendeiner Cloud“ synchronisiert werden, sondern ausschließlich auf dem eigenen Server gespeichert werden.

Es wird zur Synchronisierung zwar weiterhin ein Firefox-Konto benötigt, dieses dienst von nun an allerdings nur noch zur Authentifizierung. Die Daten werden nur noch mit dem eigenen Firefox Sync Server abgeglichen.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/eigener-firefox-sync-server-mit-nginx/feed/ 20
Passwörter verwalten mit Nextcloud/KeePass https://decatec.de/home-server/passwoerter-verwalten-mit-nextcloud-keepass/ https://decatec.de/home-server/passwoerter-verwalten-mit-nextcloud-keepass/#comments Sun, 21 Apr 2019 07:39:59 +0000 https://decatec.de/?p=5399 Nextcloud KeePassXC Logo

Man liest es in letzter Zeit häufiger: Irgendein Online-Dienst wurde gehackt und es wurden Nutzerdaten entwendet. Jüngstes Beispiel ist wohl der Hack der offiziellen Server des Messenger-Dienstes Matrix.org. Die User werden dann meistens dazu aufgefordert, umgehend ihre Passwörter zu ändern.

Wenn man aber nun für mehrere Dienste immer das gleiche Passwort verwendet, dann ist nach einem solchen Hack immer die Wahrscheinlichkeit gegeben, dass die Daten für anderen Online-Dienste, Webshops, etc. missbraucht werden. Daher sollte es sich mittlerweile herumgesprochen haben, dass man für jeden Online-Dienst ein eigenes Passwort verwenden soll.

Der folgende Artikel zeigt, wie man Passwörter einfach und effizient mit KeePass und Nextcloud verwalten kann.

Passwörter mit System

Aus den o.g. Gründen sollte „Passwort-Recycling“ also vermieden werden. Folglich muss man sich aber auch immer mehr Passwörter merken, je mehr Online-Dienste genutzt werden. Hierzu gibt es verschiedene Ansätze. Einer davon ist, dass man sich einen leicht zu merkenden Satz ausdenkt: „Grillen kann man nicht nur bei schönem Wetter, sondern auch wenn es regnet“. Nun nimmt man die Anfangsbuchstaben der einzelnen Wörter und erhält somit: gkmnnbswsawer. Nun kommen noch Groß-/Kleinbuchstaben, evtl. Sonderzeichen und weitere Ersetzungen zum Einsatz: gKm2nbSws4w3R – hier wurde das „nn“ einfach durch 2n“ und ein paar Buchstaben durch Zahlen (Leetspeak) ersetzt.
„gKm2nbSws4w3R“ ist nun das Basis-Passwort, dass man nun noch mit einem „Dienst-Teil“ ergänzt (z.B. die Anfangsbuchstaben des Dienstes). Für Amazon wäre das fertige Passwort also z.B. „aMgKm2nbSws4w3R“, für eBay z.B. „eBgKm2nbSws4w3R“.

Mit einem solchen System ist man nun etwas sicherer unterwegs. Dennoch besteht die Möglichkeit, dass das System dahinter erkannt werden kann, z.B. wenn von mehreren Diensten Daten entwendet wurden. In diesem Fall ist ein solches System auch nicht mehr als sicher anzusehen.

Besser wären Passwörter in der Form „k;%([uhk[3@!o6?m’2SQ}>MLN/Bf,ngPb“ – also eine zufällige Folge aus Buchstaben/Zahlen/Sonderzeichen. Jeder Dienst bekommt dann ein eigenes Passwort, d.h. dass hier kein System dahinter steckt, dem man auf die Schliche kommen kann.
Nun hat man allerdings ein Problem: Kein Mensch kann sich solche Passwörter merken…

Passwort-Verwaltung mit KeePass

Hier kommen dann sog. Passwort-Safes wie z.B. KeePass zum Einsatz. Passwörter können hier ganz einfach mit beliebigen Zusatzinformationen gespeichert werden, z.B. Benutzernamen oder Notizen, sogar Datei-Anhänge sind möglich. Verwaltet werden diese Passwort-Einträge in einer speziellen Datei (kdbx), die komplett verschlüsselt ist. Öffnen lässt sich der Passwort-Safe dann nur mit dem Master-Passwort, einer Schlüsseldatei, oder auch weiteren Verfahren (z.B. mittels eines YubiKeys). Auch eine Kombination der Verfahren zum Entschlüsseln ist möglich, so dass man z.B. sowohl das Master-Passwort eingeben, als auch eine Schlüsseldatei bereitstellen muss.

Man muss sich nun also nur noch das Master-Passwort merken. Die Passwörter für die einzelnen Dienste werden dann nur noch über den Passwort-Manager verwaltet und können beliebig lang/komplex sein. Ebenso kann man mit KeePass Passwörter erzeugen lassen, so dass man sich nicht mal mehr eigene Passwörter ausdenken muss.

Neben dem originalen KeePass gibt es eine Reihe weiterer Programme, die mit KeePass kompatibel sind. Mein Favorit darunter ist das Programm KeePassXC, welches aus einem Fork aus KeePass hervorgegangen ist.

Geöffnete Passwort-Datenbank mit KeePassXC

Geöffnete Passwort-Datenbank mit KeePassXC

Ebenso gibt es KeePass kompatible Clients für mobile Systeme. Unter Android verwende ich hierzu gern die App Keepass2Android.

Auf der Download-Seite von KeePass findet man hierzu eine Liste an alternativen Programmen/Apps.

Ebenfalls gibt es für KeePassXC Browser-Addons (Firefox, Chrome), die Passwörter aus einer (geöffneten) kdbx-Datenbank auslesen und bei der Anmeldung im Browser automatisch ausfüllen können.

KeePass und Nextcloud

Für den Zugriff auf die eigenen Passwörter braucht man also nur die KeePass-Datenbank (kdbx-Datei) und einen KeePass-Client. Wenn man nun allerdings von mehreren Geräten Zugriff auf die Passwörter haben möchte, muss man immer erst noch die aktuelle Version der kdbx-Datei auf das jeweilige Gerät kopieren. Das ist mühselig und auch fehleranfällig: Wo liegt nun nochmal die aktuelle Version der KeePass-Datenbank? Habe ich diese zuletzt auf dem Notebook oder auf dem PC bearbeitet?

Hier kommt dann Nextcloud ins Spiel: Für eine solche Cloud-Anwendung ist das Synchronisieren von Dateien eine der leichtesten Übungen. Am besten lädt man direkt nach der Erstellung des Passwort-Safes die kdbx-Datei in die eigene Nextcloud-Instanz in einen eigenen Ordner (z.B. „Passwörter“) hoch. Ab nun liegt immer die aktuellste Version dieser Datei in der Cloud.

Ab jetzt befindet sich die aktuellste Version der KeePass-Datenbank immer in der Nextcloud

Ab jetzt befindet sich die aktuellste Version der KeePass-Datenbank immer in der Nextcloud

Nun muss man nur noch sicher stellen, dass jedes Gerät immer mit der aktuellsten Version der Datei arbeitet. Am PC/Notebook nutzt man dazu am besten den Desktop-Sync-Client von Nextcloud: Man fügt einfach für den Order „Passwörter“ eine Synchronisation hinzu:

Nextcloud-Client: Synchronisation für den Passwort-Ordner hinzufügen

Nextcloud-Client: Synchronisation für den Passwort-Ordner hinzufügen

Nun ist auf diesem Gerät die aktuellste kdbx-Datei immer im jeweiligen Sync-Order für Nextcloud vorhanden, also z.B. /home/user/Nextcloud/Passwörter/Passwörter.kdbx.
Über KeePassXC öffnet man nun einfach diese Datei. Nach dem Bearbeiten der Einträge wird die Datei gespeichert. Sofort springt der Sync-Client von Nextcloud an und lädt die veränderte Version in die Cloud.

Wichtig: Falls man die KeePass-Datenbank mit Passwort und Schlüsseldatei gesichert hat, sollte man die Schlüsseldatei natürlich nicht neben der kdbx-Datei in der Cloud bereit stellen, sondern getrennt davon abspeichern: Am besten nur auf den jeweiligen Geräten selbst, auf einem USB-Stick, etc.

Auf einem Mobilgerät (z.B. mit Keepass2Android) läuft die Sache etwas anders ab: Hier wird die KeePass-Datenbank direkt per WebDAV geöffnet. Beim Öffnen der App gibt man daher den direkten Link zur kdbx-Datei ein, also z.B. https://meinedomain.de/nextcloud/remote.php/dav/files/user/Passwörter/Passwörter.kdbx.
Gespeichert wird wiederum per WebDAV, so dass die kdbx-Datei nach der Bearbeitung direkt in der Cloud aktualisiert wird.

KeePass-Datei direkt in Nextcloud öffnen

Es geht allerdings noch komfortabler: Mit KeeWeb existiert ein weiterer KeePass-Client, der auch im Web lauffähig ist. Und genau diesen Client (in der Web-Version) gibt es auch als eigenständige Nextcloud-App:
Im Nextcloud App Store findet man dazu in der Kategorie „Werkzeuge“ die App Keeweb.

Nach der Installation aus dem App Store ist allerdings noch ein kleiner Schritt notwendig, damit die in der Cloud gespeicherten kdbx-Dateien direkt per Klick geöffnet werden können. Dazu legen wir eine neue Datei im gleichen Order an, in dem auch schon die config.php von Nextcloud enthalten ist, also z.B.:

nano /var/www/nextcloud/config/mimetypemapping.json

Hier fügen wir folgenden Inhalt ein:

{
  "kdbx": ["application/x-kdbx"]
}

Damit die Änderungen greifen, muss noch ein Datei-Scan von Nextcloud angestoßen werden:

sudo -u www-data php /var/www/nextcloud/occ files:scan --all

Nun kann die Passwort-Datei in der Nextcloud-Instanz ganz einfach per Klick geöffnet werden:

Geöffnete KeePass-Datei in Nextcloud/Keeweb

Geöffnete KeePass-Datei in Nextcloud/Keeweb

Damit kann man sich die Synchronisierung der kdbx-Datei auf die einzelnen Geräte eigentlich sparen, da man nun jederzeit direkt in der eigenen Nextcloud an die gespeicherten Passwörter kommt. Einen „echten“ Desktop-Client wie KeePassXC braucht man eigentlich nur noch, wenn man z.B. die Integration mittels Browser-Addon benötigt.

Die Alternativen

Für Nextcloud-User, die KeePass bereits nutzen, ist die Integration der bestehenden Passwort-Verwaltung in die eigenen Cloud sicherlich sinnvoll. An dieser Stelle soll allerdings auch erwähnt werden, dass es darüber hinaus noch zwei Alternativen gibt:

Im Nextcloud App Store befinden sich mit Passman und Passwords noch zwei weitere Apps, mit den Passwörter in der eigenen Nextcloud verwaltet werden können. Beide Apps speichern ihre Einträge dabei direkt in der Cloud und nicht in kdbx-Dateien, daher sind die Apps auch nicht kompatibel mit KeePass. Dennoch bieten die Apps z.T. erweiterte Features, wie z.B. das direkte Teilen von einzelnen Passwörtern mit anderen Nextcloud-Benutzern oder per Link. Mit der KeePass-Lösung kann man nur die gesamte kdbx-Datei teilen, daher gilt hier das Motto „alles oder nichts“.

Fazit

In diesem Artikel wurde gezeigt, wie man seine Passwörter ganz einfach in der eigenen Nextcloud-Instanz verwalten kann. Nutzer von KeePass oder alternativen Clients können im einfachsten Fall die Funktionen zur Datei-Synchronisierung von Nextcloud nutzen, aber auch eine direkte Integration ist per App möglich, so dass kdbx-Dateien direkt in der Cloud geöffnet und bearbeitet werden können.

Darüber hinaus gibt es mit den Apps Passman und Passwords noch Alternativen für die Passwort-Verwaltung mit Nextcloud. Welche Lösung hier die beste (oder komfortabelste) ist, muss jedoch jeder für sich selbst herausfinden. Dazu können die Apps auch erst einmal im Parallelbetrieb installiert/getestet werden.

Wenn man sich für eine Lösung entschieden hat, werden die eigenen Passwörter zukünftig in der eigenen Cloud verwaltet. Durch den Einsatz eines Online-Password-Managers muss man sich nun nie mehr komplizierte Passwörter ausdenken und schon gar nicht merken.

Ich bin zwar kein Fan von Wechsel dein Passwort-Tagen, aber vielleicht ist dieser Artikel mal ein Anreiz, den Umgang mit eigenen Passwörtern zu überdenken und ggf. anzupassen.

Was haltet ihr davon? Wie verwaltet ihr eure Passwörter? Hinterlasst mir dazu doch einfach einen Kommentar.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/passwoerter-verwalten-mit-nextcloud-keepass/feed/ 9
RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung) https://decatec.de/home-server/rsa-und-ecdsa-zertifikate-mit-nginx-hybrid-loesung/ https://decatec.de/home-server/rsa-und-ecdsa-zertifikate-mit-nginx-hybrid-loesung/#comments Sun, 17 Mar 2019 14:13:33 +0000 https://decatec.de/?p=5314 Let's Encrypt Logo

Wer Webdienste wie Nextcloud betreibt, der sollte auf jeden Fall sicher stellen, dass die Verbindung zum Server stets mittels HTTPS verschlüsselt ist. Damit dies funktioniert, benötigt man ein TLS-Zertifikat. Dank Let’s Encrypt kann man solche Zertifikate kostenlos beziehen und die Generierung geht leicht von der Hand.

Zum Thema TLS-Zertifikate und v.a. auch Let’s Encrypt sind hier im Blog schon einige Beiträge veröffentlicht worden. Heute soll es um eine spezielle Optimierung gehen:

RSA und ECDSA-Zertifikate im Hybrid-Betrieb mit dem Webserver nginx. Damit kommen moderne Zertifikate (ECDSA) zum Einsatz und gleichzeitig wird die Kompatibilität zu älteren Clients mittels RSA-Zertifikaten sicher gestellt.

Update-Historie (letztes Update 17.08.2019)
  • 17.08.2019:
    • acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher wird für die Ausführung von acme.sh ein spezieller User angelegt.
  • 26.07.2019:
    • Hinweis hinzugefügt, dass das Verzeichnis, in dem die Zertifikate installiert werden, vor der Generierung der Zertifikate angelegt werden muss.
  • 24.07.2019:
    • Anpassungen für TLSv1.3 (ssl_ciphers und ssl_ecdh_curve).
  • 15.06.2019:
    • ECDHE-RSA-AES256-SHA384 aus den ssl_ciphers entfernt (wird beim Qualys SSL Labs Test als „weak“ eingestuft).
  • 18.05.2019:
    • Hinweis hinzugefügt, dass bei der Generierung der Zertifikate am besten Copy&Paste und „Suchen & Ersetzen“ genutzt wird.

 

Ein kleiner Ausflug in die Kryptografie

Zunächst soll erst einmal mit einfachen Worten geklärt werden, was sich hinter RSA bzw. ECDSA verbirgt.

Ohne nun zu weit in die Theorie abzuschweifen, sind beides asymmetrische kryptografische Verfahren, die zum Verschlüsseln, also auch zum digitalen Signieren genutzt werden. Dabei wird ein Schlüsselpaar bestehend aus einem öffentlichen und einem privaten Schlüssel genutzt. Ganz allgemein ausgedrückt können mittels des öffentlichen Schlüssels Nachrichten verschlüsselt werden, die nur mit dem privaten Key wieder entschlüsselt werden können.
Ein Anwendungsgebiet ist dabei die Kommunikation über HTTPS: Der öffentliche Schlüssel ist im Zertifikat enthalten, so dass ein Client (z.B. Browser) damit eine Nachricht verschlüsseln kann. Der private Schlüssel ist nur dem Webserver bekannt, so dass nur dieser die HTTPS-Nachrichten entschlüsseln kann.

RSA ist dabei das ältere Verfahren, welches schon in den 1970er Jahren zum Einsatz kam. Für die Sicherheit spielt hier die Schlüssellänge eine entscheidende Rolle. Momentan werden meist Schlüssellängen von 4096 empfohlen. Dennoch wird sich das vermutlich in Zukunft ändern, da immer leistungsstärkere Rechner zum Einsatz kommen, mit dem eine solche Verschlüsselung irgendwann geknackt werden kann. Hier helfen dann nur längere Schlüssel, da zum Ver- und Entschlüsseln mehr Rechenleistung benötigt wird, je länger der verwendete Schlüssel ist.

ECDSA ist ein neueres asymmetrisches Verfahren, welches auf elliptischen Kurven basiert. Der Vorteil bei ECDSA ist, dass sehr viel kürzere Schlüssellängen (bei gleicher oder gar besserer Sicherheit) zum Einsatz kommen können. So entspricht eine Schlüssellänge von 384 Bit bei ECDSA einer Schlüssellänge von 7680 bei RSA (siehe OpenSSL Wiki).

Ich möchte hier nun nicht weiter auf die technischen/mathematischen Details beider Krypto-Verfahren eingehen. Wer es genau wissen möchte, findet in den entsprechenden Artikeln bei Wikipedia genug Informationen.

Zusammengefasst kann man sagen, dass ECDSA-Zertifikate effizienter sind als RSA-Zertifikate, da durch eine kürzere Schlüssellänge weniger Rechenleistung für die Ver- und Entschlüsselung benötigt werden.

Warum sollte man nun RSA- und ECDSA-Zertifikate parallel einsetzen? Dies liegt darin begründet, dass ECDSA das neuere Verfahren ist, welches gerade von älteren Clients nicht immer unterstützt wird. Das ECDSA-Zertifikat sollte bevorzugt zum Einsatz kommen. Falls jedoch ein Client ECDSA nicht unterstützt, kommt das RSA-Zertifikat sozusagen als Fallback zum Zug.

Voraussetzungen

In diesem Artikel liegt der Fokus nur auf der Erzeugung der passenden Zertifikate und deren Einbindung in nginx. Damit das Ganze funktioniert, müssen ein paar Voraussetzungen erfüllt sein:

  • Es muss eine Domain vorhanden sein (Let’s Encrypt kann Zertifikat nur auf Domains, nicht jedoch auf IP-Adressen ausstellen). Im Heim-Bereich wird dies in den meisten Fällen eine DynDNS-Adresse sein, unter der der eigene Router aus dem Internet erreichbar ist. In diesem Artikel wird dazu beispielhaft die Domain meinedomain.de verwendet.
  • Der Router muss in diesem Fall so konfiguriert sein, dass ein Portweiterleitung für die Ports 80 und 443 für die Maschine eingerichtet ist, auf der der Webserver läuft.
  • Webserver: nginx (ab Version 1.11.0)
  • Ein Let’s Encrypt Client, der sowohl RSA-, als auch ECDSA-Zertifikate unterstützt. Ich empfehle hier den Client acme.sh.
  • Der Webserver muss bereits so eingerichtet sein, dass Zertifikate von Let’s Encrypt bezogen werden können. Dazu müssen Verbindungen über Port 80 zur URL http://meinedomain.de/.wellknown/acmechallenge möglich sein.

Details zur möglichen Einrichtung des Webservers und der Verwendung des Let’s Encrypt Clients acme.sh sind im Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx zu finden.

Einrichtung acme.sh und Vorbereiten der Verzeichnisstruktur

Hinweis: acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher sollte ein spezieller User eingerichtet werden, mit dem die Zertifikate generiert/verwaltet werden.

Dieser wird folgendermaßen angelegt und anschließend der Gruppe www-data hinzugefügt:

adduser letsencrypt
usermod -a -G www-data letsencrypt

Der User braucht nun die Berechtigungen, um nginx später ohne Passwort neu laden zu können:

visudo

Am Ende wird folgende Zeile hinzugefügt:

letsencrypt ALL=NOPASSWD: /bin/systemctl reload nginx.service

Für die Installation von acme.sh wechseln wird nun den User:

su - letsencrypt

Anschließend kann acme.sh installiert werden:

curl https://get.acme.sh | sh

Am Ende wechseln wir wieder auf den normalen User:

exit

Nun sollte noch die die Verzeichnisstruktur vorbereitet werden:

mkdir -p /var/www/letsencrypt/.well-known/acme-challenge 
chown -R www-data:www-data /var/www/letsencrypt 
chmod -R 775 /var/www/letsencrypt 
mkdir -p /etc/letsencrypt/meinedomain.de/rsa
mkdir -p /etc/letsencrypt/meinedomain.de/ecc
chown -R www-data:www-data /etc/letsencrypt 
chmod -R 775 /etc/letsencrypt

Generierung der Zertifikate

Wenn alle Voraussetzungen erfüllt sind, dann kann es an die Generierung der Zertifikate gehen.

Da zwei unterschiedliche kryptografische Verfahren für die Zertifikate zum Einsatz kommen, müssen dementsprechend auch zwei Zertifikate getrennt voneinander erzeugt werden.

Hinweis: Da wir einen speziellen User nutzen, müssen die Befehle zum Generieren der Zertifikate unter diesem Benutzer ausgeführt werden:

su - letsencrypt

RSA-Zertifikate

Als erstes kümmern wir uns um das „klassische“ RSA-Zertifikat.

Hier kann mittels acme.sh mit folgendem beispielhaften Befehl das Zertifikat erstellt werden.

Tipp: Am besten übernimmt man den Befehl mittels Copy&Paste in einen beliebigen Text-Editor, mit dem man dann die Domain mit „Suchen und Ersetzen“ einfach durch die tatsächlich verwendete Domain einfügt. Auf diese Weise kann man Tippfehler vermeiden.

acme.sh --issue -d meinedomain.de --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/meinedomain.de/rsa/key.pem --ca-file /etc/letsencrypt/meinedomain.de/rsa/ca.pem --cert-file /etc/letsencrypt/meinedomain.de/rsa/cert.pem --fullchain-file /etc/letsencrypt/meinedomain.de/rsa/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Durch die Angabe

--keylength 4096
wird ein RSA-Zertifikat mit der Schlüssellänge von 4096 Bit erzeugt.

Wenn die Konfiguration des Webservers passt, sollte das Zertifikat nach wenigen Augenblicken generiert worden sein.

ECDSA-Zertifikate

Der zweite Schritt ist nun die Erzeugung des ECDSA-Zertifikats.

Auch hier nutzen wir wieder folgenden beispielhaften Befehl:

acme.sh --issue -d meinedomain.de --keylength ec-384 -w /var/www/letsencrypt --key-file /etc/letsencrypt/meinedomain.de/ecc/key.pem --ca-file /etc/letsencrypt/meinedomain.de/ecc/ca.pem --cert-file /etc/letsencrypt/meinedomain.de/ecc/cert.pem --fullchain-file /etc/letsencrypt/meinedomain.de/ecc/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Dieser Befehl sieht eigentlich genau so aus wie der vorhergehende. Lediglich über den Parameter

--keylength ec-384
wird angegeben, dass diesmal ein ECDSA-Zertifikat (384 Bit) angefordert wird.

Zertifikate einbinden

Wenn die Zertifikate ohne Fehler erzeugt wurden, können diese anschließend in der Webserver-Konfiguration eingebunden werden. Ich lagere dabei alle SSL-spezifischen Einstellungen immer in eine gesonderte Datei aus. Dies ist kein Muss, sondern dient nur der besseren Übersichtlichkeit.

nano /etc/nginx/snippets/ssl.conf

Hier der gesamte Inhalt:

# Certificates used
# RSA
ssl_certificate /etc/letsencrypt/meinedomain.de/rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain.de/rsa/key.pem;

# ECC
ssl_certificate /etc/letsencrypt/meinedomain.de/ecc/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain.de/ecc/key.pem;

# This should be ca.pem (certificate with the additional intermediate certificate)
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/letsencrypt/meinedomain.de/ecc/ca.pem;

# Diffie-Hellman parameter, recommended 4096 bits
ssl_dhparam /etc/nginx/dhparams/dhparams.pem;

# Not using TLSv1 will break:
#	Android <= 4.4.40
#	IE <= 10
#	IE mobile <=10
# Removing TLSv1.1 breaks nothing else!
# TLSv1.3 is not supported by most clients, but it should be enabled.
ssl_protocols TLSv1.2 TLSv1.3;

# Prefer the SSL ciphers for ECDSA:
ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384';
 
# Use multiple curves.
ssl_ecdh_curve secp521r1:secp384r1;

# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;

# OCSP Stapling
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

# This is the IP if yout DNS-Server (in most cases: your router's IP)
resolver 192.168.178.1;

# SSL session handling
ssl_session_timeout 24h;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

Wichtig für die Kombination RSA/ECDSA-Zertifikate sind hier besonders folgende Einstellungen:

  • Zunächst werden mit ssl_certificate und ssl_certificate_key die Zertifikate eingebunden. Diese Anweisungen sind doppelt (einmal für RSA, einmal für ECDSA) aufgeführt, da wir ja auch zwei Zertifikate parallel einbinden wollen.
  • Welches Zertifikat vorzugsweise zum Einsatz kommt, wird durch die ssl_ciphers gesteuert: Dadurch, dass die Ciphers ECDHE-ECDSA-CHACHA20-POLY1305 (speziell für ECDSA) am Anfang aufgeführt sind, wird erst mal versucht, damit eine Verbindung aufzubauen. Wenn das klappt, kommt automatisch das ECDSA-Zertifikat zum Einsatz. Falls das nicht klappen sollte, kommen die anderen Ciphers (und damit das RSA-Zertifikat) zum Zug. Dadurch haben wir einen effizienten Fallback-Mechanismus, falls z.B. der Client keine ECDSA-Zertifikate unterstützt.
  • Alle anderen Einstellungen bzgl. SSL sind nicht spezifisch für RSA/ECDSA und sind hier einfach nur für maximale Sicherheit ausgelegt.

Die Datei mit den SSL-spezifischen Einstellungen kann dann in den virtuellen Hosts von nginx durch eine einzige Zeile eingebunden werden (im server-Block für den HTTPS-Server):

include /etc/nginx/snippets/ssl.conf;

Nach der Durchführung der Änderungen muss der Webserver natürlich noch neu gestartet werden:

service nginx restart

Hier sollten keine Fehler auftreten. Falls doch, liegt vermutlich in der Konfiguration noch ein Fehler vor. Um das genaue Problem zu ermitteln, hilft in diesem Fall folgender Befehl, der die genaue Zeile in den vHosts anzeigen sollte, wo die Ursache des Fehlers zu finden ist:

nginx -t

Wenn alles geklappt hat, läuft nginx im „Zerifikat-Hybrid-Betieb“ und wir können uns ansehen, wie sich das in der Praxis auswirkt.

Test der Zertifikate

Zum Testen der Zertifikate nutze ich immer gern den SSL-Test von Qualys SSL Labs. Hier sollte zunächst einmal ein A+ Rating erzielt werden können (inkl. 100% bei allen Kategorien). Das wäre aber auch mit einem reinen RSA-Zertifikat möglich. Durch das zusätzliche ECDSA-Zertifikat sollte der Test nun allerdings zwei Zertifikate anzeigen: Ein RSA-Zertifikat mit der Schlüssellänge von 4096 Bit und ein ECDSA-Zertifikat mit der Schlüssellänge von 384 Bit.

Beim SSL-Test werden zwei Zertifikate angezeigt (RSA und ECDSA)

Beim SSL-Test werden zwei Zertifikate angezeigt (RSA und ECDSA)

Falls beim SSL-Test kein A+ Rating erreicht wurde, sollten nochmals die SSL-Einstellungen des Webservers überprüft werden.

Auch im Browser (z.B. Firefox) sollte man nun bei den Details zum verwendeten Zertifikat sehen, dass ein ECDSA-Zertifikat zum Einsatz kommt.

Firefox nutzt nun automatisch das ECDSA-Zertifikat

Firefox nutzt nun automatisch das ECDSA-Zertifikat

Welches Zertifikat genutzt wird, lässt sich übrigens Client-seitig nicht festlegen. Der Client wird hier immer den ersten SSL-Cipher nehmen, mit dem er kompatibel ist. ECDSA wird hier vom Webserver bevorzugt behandelt, da die entsprechenden Ciphers am Anfang der Cipher-Liste aufgeführt sind.

Fazit

Der Artikel hat gezeigt, wie man mit dem Webserver nginx auf einfache Weise RSA- und ECDSA-Zertifikate im Hybrid-Betrieb installieren kann.

Was bringt das nun? In der Praxis wird man hier kaum einen Unterschied feststellen können, ob nun ein (traditionelles) RSA-, oder ein (moderneres) ECDSA-Zertifikat zum Einsatz kommt. Trotzdem ist bei einem ECDSA-Zertifikat weniger Rechenleistung für die Ver- und Entschlüsselung notwendig.

Durch den allgemeinen Anstieg der Leistung moderner Rechner ist zu erwarten, dass immer längere Schlüssel für TLS-Zertifikate benötigt werden – vielleicht ist hier in Zukunft ein RSA-Zertifikat mit 4096 Bit auch schon nicht mehr ausreichend. Mit dem Hybrid-Betrieb RSA/ECDSA ist man auf jeden Fall mit einem modernen Schlüsselaustausch (ECDSA) bestens für die Zukunft gerüstet, währenddessen der Einsatz von RSA die Kompatibilität mit älteren Clients sicherstellt.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/rsa-und-ecdsa-zertifikate-mit-nginx-hybrid-loesung/feed/ 13
Linux: Einfach E-Mails versenden mit msmtp https://decatec.de/linux/linux-einfach-e-mails-versenden-mit-msmtp/ https://decatec.de/linux/linux-einfach-e-mails-versenden-mit-msmtp/#comments Wed, 27 Feb 2019 14:57:15 +0000 https://decatec.de/?p=5049 Linux Mail Logo

Oftmals macht es Sinn, wenn man von einem Linux-System direkt eine E-Mail senden kann. Anwendungsbeispiele wären z.B. der Versand einer Mail, wenn ein Cronjob fehlschlägt oder auch eine Benachrichtigung, wenn durch fail2ban eine IP auf Grund zu vieler fehlgeschlagener Anmeldeversuche gebannt wurde.

Nun könnte man einfach einen Mail Transfer Agent, wie z.B. Sendmail oder Postfix auf dem System aufsetzen. Allerdings ist es recht umständlich einen „echten“ Mail-Server zu betreiben, v.a. wenn man nur einfache Mails zur Benachrichtigung versenden will.

Hierzu gibt es dann einfache Programme, die nicht mit einem echten Mailserver zu vergleichen sind, sondern die einfach Mails an einen bereits bestehenden STMP-Server senden können – dazu braucht man einfach nur einen SMTP-Client).

Vor einiger Zeit habe ich in diesem Blog schon mal den SMTP-Client sSMTP vorgestellt. Heute will ich eine Alternative dazu vorstellen: msmtp

Auch wenn der Artikel auf Ubuntu 18.04 basiert, sollte es kein Problem sein, das gezeigte Vorgehen auf anderen Systemen/Distributionen umzusetzen.

Update-Historie (letztes Update 16.05.2019)
  • 16.05.2019:
    • Reihenfolge der auszuführenden Schritte verändert: Der Alias muss noch vor dem Versenden der Test-Mail gesetzt werden.

 

sSMTP läuft doch problemlos – was spricht dagegen?

Ich habe mit sSMTP immer gute Erfahrungen gemacht. Jedoch wird dieses Programm nicht mehr weiterentwickelt (Quelle: Arch Wiki). Dadurch kann ich sSMTP nicht mehr ohne Einschränkungen empfehlen. Wenn beispielsweise Bugs oder Sicherheitslücken gefunden werden, ist es fraglich, ob diese noch ausgebaut werden.

Generell sollte man aus diesen Gründen Abstand von Software nehmen, die nicht mehr aktiv weiterentwickelt wird. Trotzdem soll das nun nicht heißen, dass man sSMTP ab sofort nicht mehr verwenden sollte: Wer sSMTP bereits eingerichtet hat und damit keine Probleme hat, muss sich nun nicht sofort nach einer Alternative umsehen – trotzdem sollte man über kurz oder lang über ein „Update“ zu msmtp nachdenken.

Wer aber gerade auf der Suche nach einem leichtgewichtigen SMTP-Client ist, der sollte lieber gleich zu msmtp greifen.

Installation und Konfiguration vom msmtp

Zunächst bringen wir das System wie immer auf den neusten Stand:

apt-get update && apt-get upgrade -V

Anschließend wird msmtp installiert:

apt-get install msmtp msmtp-mta mailutils

Das Paket mailutils wird zwar nicht unbedingt benötigt, jedoch ist dies beim späteren Verwenden von Mails sehr hilfreich,.

Für die Konfiguration des Programms gibt es zwei unterschiedliche Konfigurations-Dateien:

  • Eine systemweite Konfiguration
  • Eine benutzerspezifische Konfiguration.

Wo diese unterschiedlichen Konfigurations-Dateien gespeichert sind, ermittelt man einfach mit folgendem Befehl:

msmtp --version

Für das weitere Vorgehen nutzen wir hier die systemweite Konfiguration, da E-Mails nur vom System selbst verschickt werden sollen (z.B. bei fehlgeschlagenen Cronjobs).

msmtp: Speicherort der Konfigurations-Dateien

msmtp: Speicherort der Konfigurations-Dateien

Beide Dateien sind nach einer neuen Installation nicht vorhanden (so dass man diese einfach nur auf die eigenen Bedürfnisse abändern könnte), allerdings gibt es auf der Website von msmtp eine Beispiel-Konfiguration.

Für die systemweite Konfiguration wird nun folgende Datei bearbeitet:

nano /etc/msmtprc

Der Inhalt kann beispielsweise so aussehen (hier am Beispiel eines fiktiven Mail-Accounts meinedomain.de):

# Set default values for all following accounts.
defaults

# Use the mail submission port 587 instead of the SMTP port 25.
port 587

# Always use TLS.
tls on

# Set a list of trusted CAs for TLS. The default is to use system settings, but
# you can select your own file.
tls_trust_file /etc/ssl/certs/ca-certificates.crt

# If you select your own file, you should also use the tls_crl_file command to
# check for revoked certificates, but unfortunately getting revocation lists and
# keeping them up to date is not straightforward.
#tls_crl_file ~/.tls-crls

# Mail account
# TODO: Use your own mail address
account bob@meindedomain.de

# Host name of the SMTP server
# TODO: Use the host of your own mail account
host smtp.meindedomain.de

# As an alternative to tls_trust_file/tls_crl_file, you can use tls_fingerprint
# to pin a single certificate. You have to update the fingerprint when the
# server certificate changes, but an attacker cannot trick you into accepting
# a fraudulent certificate. Get the fingerprint with
# $ msmtp --serverinfo --tls --tls-certcheck=off --host=smtp.freemail.example
#tls_fingerprint 00:11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33

# Envelope-from address
# TODO: Use your own mail address
from bob@meindedomain.de

# Authentication. The password is given using one of five methods, see below.
auth on

# TODO: Use your own user name fpr the mail account
user bob@meindedomain.de

# Password method 1: Add the password to the system keyring, and let msmtp get
# it automatically. To set the keyring password using Gnome's libsecret:
# $ secret-tool store --label=msmtp \
#   host smtp.freemail.example \
#   service smtp \
#   user joe.smith

# Password method 2: Store the password in an encrypted file, and tell msmtp
# which command to use to decrypt it. This is usually used with GnuPG, as in
# this example. Usually gpg-agent will ask once for the decryption password.
#passwordeval gpg2 --no-tty -q -d ~/.msmtp-password.gpg

# Password method 3: Store the password directly in this file. Usually it is not
# a good idea to store passwords in plain text files. If you do it anyway, at
# least make sure that this file can only be read by yourself.
# TODO: Use the password of your own mail account
password pAssW0Rd123

# Password method 4: Store the password in ~/.netrc. This method is probably not
# relevant anymore.

# Password method 5: Do not specify a password. Msmtp will then prompt you for
# it. This means you need to be able to type into a terminal when msmtp runs.

# Set a default account
# TODO: Use your own mail address
account default: bob@meindedomain.de

# Map local users to mail addresses (for crontab)
aliases /etc/aliases

Alle Einstellungen, die man individuell anpassen muss, sind hier mit „# TODO“ gekennzeichnet. Bitte auch die Kommentare in der Datei beachten.

Noch ein Hinweis auf die Authentifizierungs-Methode: In diesem Beispiel nutzen wird die einfachste Form der Authentifizierung, indem das Passwort des Mail-Accounts direkt in der Konfiguration gespeichert wird. msmtp unterstützt hier allerdings auch weitere Authentifizierungs-Methoden. Mehr Informationen dazu findet man in der Dokumentation zu msmtp.

Als nächstes sorgen wir dafür, dass nicht jeder Zugriff auf die Datei hat (besonders wichtig, wenn das Passwort direkt in der Konfiguration gespeichert ist):

chmod 600 /etc/msmtprc

Zum Schluss wird noch ein Alias angelegt, so dass die Empfänger-Adresse des Root-Accounts (oder des Accounts, mit dem später E-Mail versendet werden sollen) bekannt ist. Dies wird in der Datei angegeben, die auch schon ganz am Ende der Konfiguration von msmtp aufgeführt wurde:

nano /etc/aliases

Hier wird nun die Empfänger-Adresse des Root-Accounts angegeben. An diese Adresse werden nun E-Mails verschickt, wenn z.B. ein Cronjob fehlschlagen sollte. Daneben wird noch eine allgemeine „Fallback-Empfänger-Adresse“ angegeben, falls System-Meldungen nicht im Kontext des Root-Accounts auftreten:

root: admin@meinedomain.de
default: admin@meinedomain.de

Nach der erfolgten Konfiguration vom msmtp können E-Mails nun ganz einfach über die Kommandozeile verschickt werden:

echo "Inhalt der E-Mail" | mail -s "Betreff" test@mail.de

Am besten gleich mal ausprobieren, indem ihr euch selbst eine Test-E-Mail schickt.

Weitere Konfiguration (Fail2ban)

E-Mails können nun also über die Kommandozeile verschickt werden. Allerdings wird man dies auf einem Server nicht sonderlich häufig machen. Hier ist es eher wichtig, per E-Mail bei wichtigen Meldungen des Systems benachrichtigt zu werden.

Damit Mails über msmtp auch bei der Ausführung von Cronjobs oder bei einem erfolgten Ban von Fail2ban verschickt werden, sind noch ein paar wenigen Schritte notwendig.

Dazu muss msmtp noch als Mail-Programm festgelegt werden. Dies geschieht durch folgende Datei:

nano /etc/mail.rc

Der Inhalt sieht dabei folgendermaßen aus:

set sendmail="/usr/bin/msmtp -t"

Anschließend können auch von Fail2ban E-Mails gesendet werden, wenn z.B. eine IP auf Grund von zu vielen ungültigen Anmeldeversuchen gebannt wurde.

Fazit

Mit msmtp ist es einfach möglich, von einem Linux-System E-Mails zu versenden, ohne einen „schwergewichtigen“ Mail-Server aufsetzen zu müssen. Es wird einfach ein vorhandener Mail-Account (z.B. eines Freemailers) benutzt und die Konfiguration gestaltet sich auch sehr einfach.

Neben dem Mail-Versand von der Kommandozeile erhält man nun auch ganz komfortabel Benachrichtigungen per E-Mail, wenn beispielsweise ein Cronjob ausgeführt wurde, oder auch eine IP-Adresse von Fail2ban gebannt wurde.

Weiterführende Artikel

Links

]]>
https://decatec.de/linux/linux-einfach-e-mails-versenden-mit-msmtp/feed/ 22
Let’s Encrypt: Umstieg von Certbot auf acme.sh (nginx) https://decatec.de/linux/lets-encrypt-umstieg-von-certbot-auf-acme-sh-nginx/ https://decatec.de/linux/lets-encrypt-umstieg-von-certbot-auf-acme-sh-nginx/#comments Sat, 09 Feb 2019 14:19:10 +0000 https://decatec.de/?p=5268 Let's Encrypt Logo

Im letzten Artikel ging es um das Erstellen von TLS-Zertifikaten von Let’s Encrypt. Als Client kam hier acme.sh zum Einsatz. In meinen bisherigen Artikeln habe ich bisher immer Certbot als Client für Let’s Encrypt empfohlen. Da acme.sh meiner Meinung nach allerdings einige Vorteile bietet, wird dies vermutlich auch meine zukünftige Empfehlung zur Generierung von TLS-Zertifikaten von Let’s Encrypt sein.

Da aber etliche Leser meines Blogs wohl noch Certbot nutzen, möchte ich in diesem Artikel einen Leitfaden zum Umstieg auf acme.sh nachliefern.

Besonders wichtig dürfte die Umstellung auf acme.sh für Debian-Nutzer sein, da die in den Paketquellen enthaltene Certbot-Version nur ein Validierungsverfahren beherrscht, welches Let’s Encrypt bald nicht mehr unterstützen wird (mehr Infos dazu gibt es hier).

Wer Certbot bisher noch nicht verwendet hat: Dieser Artikel richtet sich ausschließlich an Umsteiger von Certbot zu acme.sh. Wer das erste mal TLS-Zertifikate erzeugen möchte, der sollte sich an den Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx halten.

Update-Historie (letztes Update 17.08.2019)
  • 17.08.2019:
    • acme.sh sollte nicht mit Root-Rechten ausgeführt werden, daher wird für die Ausführung von acme.sh ein spezieller User angelegt.
  • 24.07.2019:
    • Anpassungen für TLSv1.3 (ssl_ciphers und ssl_ecdh_curve).
  • 15.06.2018:
    • ECDHE-RSA-AES256-SHA384 aus den ssl_ciphers entfernt (wird beim Qualys SSL Labs Test als „weak“ eingestuft).
  • 18.05.2019:
    • Hinweis hinzugefügt, dass bei der Generierung der Zertifikate am besten Copy&Paste und „Suchen & Ersetzen“ genutzt wird.
  • 13.02.2018:
    • Hinweis für die Berechtigungen des Verzeichnisses /var/www/letsencrypt hinzugefügt.
  • 11.02.2019:
    • Hinweis auf Überschreiben der Crontab durch Installation von acme.sh hinzugefügt/Sichern der bestehenden Crontab.
  • 10.02.2019:
    • Reihenfolge der im Tutorial ausgeführten Schritte angepasst – das Umkopieren der alten Zertifikate war nicht notwendig, da diese von Certbot in einem anderen Verzeichnis gespeichert wurden.

 

Voraussetzungen

Ich gehe im Folgenden davon aus, dass die TLS-Zertifikate mit Certbot gemäß dem Artikel Nextcloud auf Ubuntu Server 18.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban erstellt wurden.

Im Detail heißt dies:

  • Certbot wurde installiert und der automatisch eingerichtete Cronjob zur Erneuerung der Zertifikate wurde genutzt.
  • Es wurden durch Certbot bereits Zertifikate generiert (d.h. der Webserver ist fertig eingerichtet und im Router sind die entsprechenden Port-Weiterleitungen bereits eingerichtet).
  • Die Zertifikate sind im Verzeichnis /etc/letsencrypt/live/meinedaomin.de gespeichert (meinedomain.de dient hier nur als Beispiel-Domain) und bestehen aus den Dateien cert.pem, chain.pem, fullchain.pem und privkey.pem.
  • Diffie-Hellman-Parameter sind ebenfalls bereits vorhanden (/etc/nginx/ssl/dhparams.pem).

Vorbereitungen – alte Zertifikate kopieren

Bevor die neuen Zertifikate erstellt werden können, müssen die alten Zertifikate erst einmal an eine andere Stelle kopiert werden. Dies ist notwendig, da bei der späteren Deinstallation von Certbot der komplette Order /etc/letsencrypt entfernt wird.

mkdir -p /etc/certs-temp
cp -r /etc/letsencrypt/* /etc/certs-temp

Damit diese Kopie der Zertifikate (temporär) vom Webserver verwendet wird, sind die SSL-Einstellungen im Gateway-Host zu bearbeiten:

nano /etc/nginx/conf.d/meinedomain.de.conf

Hier sind die Verzeichnis-Angaben für die Zertifikat-Dateien anzupassen:

ssl_certificate /etc/certs-temp/live/meinedomain.de/fullchain.pem;
ssl_certificate_key /etc/certs-temp/live/meinedomain.de/privkey.pem;
ssl_trusted_certificate /etc/certs-temp/live/meinedomain.de/chain.pem;

Ein Neustart von nginx sollte dann problemlos verlaufen und die (temporären) Zertifikate werden genutzt:

service nginx restart

Certbot deinstallieren

Nun kann Certbot komplett vom System entfernt werden. Mit der Installation von Certbot wurden nicht nur die Programm-Dateien installiert, sondern es wurde darüber hinaus noch ein Cronjob eingerichtet, der für die automatische Erneuerung der Zertifikate sorgt. Diesen Cronjob kann man mit folgendem Befehl ermitteln:

systemctl list-timers

In der Auflistung sollte dann der Cronjob von Certbot auftauchen:

systemctl list-timers listet den Cronjob von Certbot

systemctl list-timers listet den Cronjob von Certbot

Als erstes sollte Certbot deinstalliert werden. Dies geschieht über folgenden Befehl:

apt-get purge certbot

Dies deinstalliert neben den Programm-Dateien auch noch sämtliche Konfigurationen, Abhängigkeiten und auch die alten Zertifikate.

Anschließend sollte ein systemctl list-timers den Cronjob für Certbot nicht mehr aufführen und Certbot ist restlos vom System entfernt worden.

Neue Zertifikate generieren

Der Einfachheit halber werden am besten gleich ganz neue Zertifikate über acme.sh erstellt. Das sollte kein Problem darstellen, wenn man die alten Zertifikate nicht ein paar Tage zuvor mit Certbot erstellt hat – Let’s Encrypt hat gewisse „Rate Limits“, d.h. man kann in einem bestimmten Zeitraum nur eine gewisse Anzahl an Zertifikaten beantragen (siehe hier).

Details zu dem Vorgehen und zur „Installation“ von acme.sh sind im Artikel Let’s Encrypt Zertifikate mit acme.sh und nginx zu finden, daher hier im Schnelldurchlauf.

Hinweis: acme.sh sollte nicht mit Root-Rechten ausgeführt werden. Am besten legt man dafür einen speziellen User an. Wie man dazu vorgehen kann, ist im oben genannten Artikel detailliert erklärt.

Wichtig: Falls bereits Cronjobs (für den entsprechenden User) eingerichtet sind, dann solltet ihr euch vorher die aktuelle Crontab sichern, da acme.sh diese bei der Installation ungefragt überschreibt:

crontab -l > crontab.bak

Nach der Installation von acme.sh können mittels dieser Datei die „alten“ Cronjobs wieder mit contab -e hinzugefügt werden.

Nun legen wir zunächst das Verzeichnis an, in dem später die Zertifikate gespeichert werden und passen die Rechte an:

mkdir -p /var/www/letsencrypt/.well-known/acme-challenge 
chown -R www-data:www-data /var/www/letsencrypt 
chmod -R 775 /var/www/letsencrypt
mkdir -p /etc/letsencrypt/meinedomain.de
chown -R www-data:www-data /etc/letsencrypt
chmod -R 775 /etc/letsencrypt

Die Generierung der Zertifikate erfolgt dann über einen Befehl. Dieser muss mit dem speziell eingerichteten User ausgeführt werden:

su - letsencrypt

Tipp: Am besten übernimmt man den Befehl mittels Copy&Paste in einen beliebigen Text-Editor, mit dem man dann die Domain mit „Suchen und Ersetzen“ einfach durch die tatsächlich verwendete Domain einfügt. Auf diese Weise kann man Tippfehler vermeiden.

acme.sh --issue -d meinedomain.de --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/meinedomain.de/key.pem --ca-file /etc/letsencrypt/meinedomain.de/ca.pem --cert-file /etc/letsencrypt/meinedomain.de/cert.pem --fullchain-file /etc/letsencrypt/meinedomain.de/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Da wird am Webserver ansonsten nichts bzgl. Let’s Encrypt geändert haben, sollte die Generierung der Zertifikate erfolgreich abgeschlossen werden können.

Anschließend kann man wieder auf den normalen User wechseln:

exit

Die Diffie-Hellman-Parameter müssen nicht neu generiert werden, sondern können wiederverwendet werden. Dennoch kopieren wir die Datei an einen anderen Speicherort, somit ist das Vorgehen zum vorherigen Artikel identisch:

mkdir -p /etc/nginx/dhparams
cp /etc/nginx/ssl/dhparams.pem /etc/nginx/dhparams/dhparams.pem

Einbinden der neuen Zertifikate

Nun können die neu Generierten Zertifikate auch schon eingebunden werden. Für eine bessere Übersichtlichkeit lagern wir dazu aber auch noch sämtliche Webserver-Einstellungen bzgl. SSL in eine eigene Datei aus.

Wichtig: Diese Datei darf nicht in dem Verzeichnis gespeichert werden, in dem nginx die virtuellen Hosts erwartet (also /etc/nginx/conf.d).

mkdir -p /etc/nginx/snippets
nano /etc/nginx/snippets/ssl.conf

Hier werden nun die folgenden Anweisungen aufgenommen:

# Certificates used
ssl_certificate /etc/letsencrypt/meinedomain.de/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/meinedomain.de/key.pem;

# This should be ca.pem (certificate with the additional intermediate certificate)
# See here: https://certbot.eff.org/docs/using.html
ssl_trusted_certificate /etc/letsencrypt/meinedomain.de/ca.pem;

# Diffie-Hellman parameter, recommended 4096 bits
ssl_dhparam /etc/nginx/dhparams/dhparams.pem;

# Not using TLSv1 will break:
#	Android <= 4.4.40
#	IE <= 10
#	IE mobile <=10
# Removing TLSv1.1 breaks nothing else!
# TLSv1.3 is not supported by most clients, but it should be enabled.
ssl_protocols TLSv1.2 TLSv1.3;

# Cipher suite from https://cipherli.st/
# Max. security, but lower compatibility 
ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384';

# Cipher suite from https://wiki.mozilla.org/Security/Server_Side_TLS
#ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

# (Modern) cipher suite from https://mozilla.github.io/server-side-tls/ssl-config-generator/
#ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

# Use multiple curves.
ssl_ecdh_curve secp521r1:secp384r1;

# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;

# OCSP Stapling
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

resolver 192.168.178.1;

# SSL session handling
ssl_session_timeout 24h;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;

Die markierten Zeilen betreffen die neuen Zertifikat-Dateien, alle anderen Anweisungen sind identisch zu den Anweisungen im Gateway-Host.

Damit die SSL-Einstellungen nur noch aus der Datei ssl.conf gezogen werden, muss der Gateway-Host angepasst werden:

nano /etc/nginx/conf.d/meinedomain.de.conf

Sämtliche Einstellungen, die schon in der ssl.conf aufgeführt werden, sind aus dem Gateway-Host zu entfernen. Diese werden dann durch eine einzige Zeile ersetzt (am besten direkt nach der Direktive server_name):

include /etc/nginx/snippets/ssl.conf;

Ein Neustart des Webservers bindet nun die neuen Zertifikate ein und sollte ohne Fehlermeldung ablaufen. Falls hier dennoch Fehler auftreten, sind vermutlich noch ein paar SSL-Anweisungen doppelt vorhanden (im Gateway-Host und in der ssl.conf). Welche Anweisungen zum Fehler führen, kann man einfach mit folgendem Befehl herausfinden:

nginx -t

Abschlussarbeiten

Zum Schluss können noch die (kopierten) alten Zertifikate und Diffie-Hellman-Parameter entfernt werden:

rm -r /etc/certs-temp
rm -r /etc/nginx/ssl

Überprüfung der neuen Zertifikate

Zum Schluss können die neuen Zertifikate noch getestet werden. Hierzu ist der SSL Server Test von Qualys SSL Labs gut geeignet. Hier sollte ein Rating mit A+ und 100% in allen Kategorien erreicht werden können:

Ergebnis des SSL-Tests

Ergebnis des SSL-Tests

Falls die Bewertung schlechter ausfällt, sollten sollten nochmals die Einstellungen des Webservers kontrolliert werden, v.a. die Anweisungen in der ssl.conf.

Erneuerung der Zertifikate

Die Zertifikate von Let’s Encrypt nur eine begrenzte Gültigkeit von 90 Tagen (Begründung siehe hier), danach müssen sie erneuert werden.

acme.sh hat aber bereits bei der Installation einen Cronjob eingerichtet, der sich um die automatische Erneuerung der Zertifikate kümmert – hier ist also nach dem ersten Generieren der Zertifikate nichts weiter zu tun.

Die Gültigkeitsdauer der installierten Zertifikate kann übrigens mit folgendem Befehl ermittelt werden:

acme.sh --list

Fazit

Der Artikel hat gezeigt, wie man von Certbot auf acme.sh für die Generierung von Let’s Encrypt Zertifikaten umsteigen kann. Darüber hinaus wurde die Verwaltung der SSL-Einstellungen am Webserver vereinfacht, indem die entsprechenden Anweisungen in eine eigene Datei ausgelagert wurden.

Nach Erfolgreicher Umstellung sollte man nur mal nach ca. 90 Tagen (Gültigkeitsdauer der Let’s Encrypt Zertifikate) kontrollieren, ob die Zertifikate auch automatisch erneuert wurden. Ist dies der Fall, kann man sich entspannt zurück lehnen und muss sich nicht mehr manuell um die Zertifikate oder deren Erneuerung kümmern.

Weiterführende Artikel

Links

]]>
https://decatec.de/linux/lets-encrypt-umstieg-von-certbot-auf-acme-sh-nginx/feed/ 37