DecaTec https://decatec.de Home-Server | Linux | Nextcloud | Raspberry Pi | Programmierung | Fotografie Sat, 15 Jun 2019 12:12:07 +0000 de-DE hourly 1 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 GitHub zur Verfügung gestellt:

WordPress-Backup-Restore @ GitHub

Hinweis: Ich habe die Skript-Dateien als Open Source auf GitHub 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://github.com/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 18.05.2019)
  • 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 (den 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 "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 "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/ 2
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/ 18
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/ 7
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 15.06.2019)
  • 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.

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.

RSA-Zertifikate

Als erstes kümmern wir uns um das „klassische“ RSA-Zertifikat. Dieses kann mittels acme.sh durch folgenden beispielhaften Befehl 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 "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 den 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 "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 '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.
# secp521r1: Not supported by Chrome
# secp384r1: Not supported by Android (DAVx5)
ssl_ecdh_curve secp521r1:secp384r1:prime256v1;

# 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/ 11
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/ 16
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 15.06.2019)
  • 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.

Wichtig: Falls bereits Cronjobs (für den Root-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:

mkdir -p /etc/letsencrypt/meinedomain.de

Bevor wir nun die Zertifikate erzeugen, stellen wir zunächst noch sicher, dass beim Verzeichnis /var/www/letsencrypt die korrekten Besitzrechte gesetzt sind:

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

Die Generierung der Zertifikate erfolgt dann über einen Befehl.
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 "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.

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 '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.
# secp521r1: Not supported by Chrome
# secp384r1: Not supported by Android (DAVx5)
ssl_ecdh_curve secp521r1:secp384r1:prime256v1;

# 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/ 35
Let’s Encrypt Zertifikate mit acme.sh und nginx https://decatec.de/linux/lets-encrypt-zertifikate-mit-acme-sh-und-nginx/ https://decatec.de/linux/lets-encrypt-zertifikate-mit-acme-sh-und-nginx/#comments Wed, 30 Jan 2019 14:36:40 +0000 https://decatec.de/?p=5213 Let's Encrypt Logo

Wer eine eigene Website oder auch eine Nextcloud-Instanz betreibt, der sollte auch großen Wert auf Sicherheit legen. In der heutigen Zeit gehört dabei HTTPS zum Sicherheits-Standard, wenn es um die verschlüsselte Übertragung von Daten im Internet geht.

Um die eigene Seite mittels HTTPS abzusichern, ist zunächst einmal ein SSL-Zertifikat notwendig. Früher musste man sich ein solches Zertifikat von einer Zertifizierungsstelle für viel Geld kaufen. Im Jahr 2015 trat jedoch Let’s Encrypt auf den Plan – eine Zertifizierungsstelle, die kostenlos Zertifikate für TLS anbietet, um damit verschlüsselte Verbindungen im Web zum Standard zu machen. Gerade im privaten Bereich hat sich Let’s Encrypt zu einem de-facto Standard entwickelt.

Seitdem kann sich jedermann selbst Zertifikate für HTTPS ausstellen lassen. Dazu wird lediglich ein Let’s Encrypt Client benötigt, der die eigentliche Generierung der Zertifikate übernimmt. In meinen Tutorials habe ich bisher immer Certbot als Client für Let’s Encrypt empfohlen, da dieses Programm in den Paketquellen fast aller Distributionen enthalten ist. Dennoch könnte sich genau dieser Umstand als Nachteil erweisen. So schaltet Let’s Encrypt aus Sicherheitsgründen das Validierungsverfahren „TLS-SNI-01“ bald ab. Nutzer von Debian laufen bald Gefahr, dass die Zertifikate nicht mehr erneuert werden können, da die Version von Certbot in Debian Stable zu alt ist und keine anderen Validierungsmethoden unterstützt (siehe hier).

Ein alternativer Let’s Encrypt Client ist acme.sh. Wie der Name bereits vermuten lässt, handelt es sich hierbei um ein reines Shell-Skript, welches die Generierung der Zertifikate übernimmt. Man ist damit nicht mehr von Programmen in den Paketquellen der Linux-Distributionen abhängig. Darüber hinaus ist acme.sh ein sehr fortschrittlicher Client, der bisher alle Features von Let’s Encrypt unterstützt. Grund genug, die diesen Let’s Encrypt Client einmal genauer anzusehen.

Der Artikel basiert dabei auf Ubuntu Server 18.04 LTS, alle gezeigten Schritte sollten sich aber auch auf anderen Distributionen umsetzen lassen. Als Webserver kommt nginx zum Einsatz.

Update-Historie (letztes Update 15.06.2019)
  • 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.
  • 18.02.2019:
    • Hinweis für Meldung „-bash: /home/user/.acme.sh/acme.sh.env: Permission denied“ hinzugefügt.
  • 13.02.2019:
    • Hinweis für die Berechtigungen des Verzeichnisses /var/www/letsencrypt hinzugefügt.
  • 11.02.2019:
    • Anleitung zum Upgrade von acme.sh hinzugefügt.
    • Hinweis auf Überschreiben der Crontab durch Installation von acme.sh hinzugefügt/Sichern der bestehenden Crontab.
  • 09.02.2019:
    • Hinweis auf neuen Artikel zum Umstieg von Certbot auf acme.sh hinzugefügt.

 

Installation von acme.sh

Es handelt sich bei acme.sh nur um ein Skript, jedoch kann es in gewisser Art installiert werden. Die Installation beinhaltet hauptsächlich die Einrichtung eines Cronjobs zur automatischen Erneuerung ausgestellter Zertifikate.

Alle folgenden Befehle werden mit Root-Rechten ausgeführt:

sudo -s

Wichtig: Falls bereits Cronjobs (für den Root-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.

Diese Installation besteht eigentlich nur in der Ausführung des Skripts mit bestimmten Parametern und gestaltet sich recht einfach. Dazu gibt es eine spezielle Seite, die das Skript zur Installation beinhaltet: https://get.acme.sh.

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

Hinweis: Es ist immer gefährlich, eine unbekannte Quelle direkt in die Shell zu pipen, da man nie so genau weiß, was diese Quelle (in diesem Fall das Skript genau ausführt). Man sollte sich die Quelle (in diesem Fall https://get.acme.sh) vor der Ausführung des Befehle genau ansehen und überprüfen, ob hier nichts verdächtiges passiert. Für wen das Pipen auf die Shell nicht in Frage kommt, der findet noch ein paar alternative Installationsmöglichkeiten auf der Wiki-Seite des GitHub-Projekts.

Die "Installation" von acme.sh

Die „Installation“ von acme.sh

Nach der Installation muss das Terminal einmal geschlossen und wieder geöffnet werden. Alternativ kann man den Rechner auch einfach neu starten.

Hinweis: Es kann sein, dass nach dem Login auf der Konsole mit einem (non-Root) User eine Fehlermeldung erscheint:

-bash: /home/user/.acme.sh/acme.sh.env: Permission denied

Während der Installation wurde hier ein Alias für acme.sh konfiguriert, so dass das Skript einfach nur mit „acme.sh“ aufgerufen werden kann (ohne Angabe des vollständigen Pfades). Da die Installation im Kontext des Root-Users vorgenommen wurde, kann acme.sh für einen normalen User so nicht aufgerufen werden. Aus diesem Grund erscheint auch die Meldung beim Login. Allerdings schränkt dies dies nicht die Funktionsfähigkeit von acme.sh ein. Daher kann diese Meldung einfach ignoriert werden.

Damit ist die Installation bereits abgeschlossen. Als nächstes wird das System auf die Verwendung von SSL-Zertifikaten vorbereitet.

Vorbereitung des Systems

Zunächst richten wir dazu das Verzeichnis ein, in dem später die Zertifikate gespeichert werden:

mkdir -p /etc/letsencrypt/meinedomain.de

Ich nutze hier immer einen Unterordner, der mit der Domain übereinstimmt, für welche die Zertifikate ausgestellt werden sollen (in diesem Beispiel einfach meinedomain.de).

Als nächstes muss der Webserver in der Lage sein, über HTTP (Port 80) im Unterverzeichnis /.wellknown/acmechallenge für Let’s Encrypt erreichbar zu sein. Im virtuellen Host für die entsprechende Domain könnte dies dann folgendermaßen aussehen:

server {
	listen 80 default_server;
    listen [::]:80 default_server;
	server_name meinedomain.de 192.168.178.60;
 
	root /var/www;
	
	location ^~ /.well-known/acme-challenge {
		default_type text/plain;
		root /var/www/letsencrypt;
	}		
}

Falls noch nicht geschehen, wird noch das Verzeichnis für Let’s Encrypt angelegt und der Webserver-User wird als Owner festgelegt:

mkdir -p /var/www/letsencrypt
chown -R www-data:www-data /var/www/letsencrypt

Zertifikate mit acme.sh erzeugen

Nach den Vorbereitungen sind wir nun soweit, dass wir Zertifikate über acme.sh ausstellen lassen können.

Ich gehe im folgenden davon aus, dass auf dem System bereits nginx als Webserver installiert und eingerichtet wurde. Für die Generierung der Zertifikate wird daher der sog. Webroot-Modus genutzt. acme.sh unterstützt allerdings auch andere Modi (z.B. einen Standalone-Modus, wenn kein Webserver auf dem System läuft). Es gibt auch einen speziellen Modus für nginx, allerdings werden hier die virtuellen Hosts vom Webserver bei der Generierung/Erneuerung der Zertifikate kurzzeitig verändert/ausgetauscht. Da ich meine vHosts lieber unangetastet lassen möchte, nutze ich daher immer nur den Webroot-Modus.

Ein Zertifikat wird durch einen einzigen Befehl erzeugt.
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 "systemctl reload nginx.service"

Mit den Parametern werden die Details zu Generierung der Zertifikate angegeben:

  • Mit 
    -d meinedomain.de
      wird die Domain angegeben, für die das Zertifikat erzeugt werden soll.
  • --keylength 4096
      gibt die Schlüssellänge des RSA-Zertifikats an. Standardmäßig werden hier 2048 Bit verwendet. Das ist in der Regel ausreichend, jedoch sollte man für erhöhte Sicherheit auf eine Schlüssellänge von 4096 Bit setzen.
  • Mit
    -w /var/www/letsencrypt
      wird das Verzeichnis angegeben, in dem die Challenge-Dateien gespeichert werden. Dies muss das Verzeichnis sein, welches bei nginx als root Verzeichnis für /.well-known/acme-challenge angegeben wurde (im jeweiligen virtuellen Host).
  • acme.sh speichert die Zertifikat-Dateien im Verzeichnis ~/.acme.sh/meinedomain.de. Es wird davon abgeraten, diese Dateien direkt in den virtuellen Hosts des Webservers zu referenzieren. Aus diesem Grund wird mit den Parametern
    --key-file
    ,
    --ca-file
    ,
    --cert-file
      und
    --fullchain-file
      die Speicherorte der Dateien angegeben, wo die entsprechenden Dateien „installiert“ werden sollen. Nur diese Dateien werden dann später in den vHosts von nginx eingebunden.
  • --reloadcmd
      gibt den Befehl an, der nach erfolgreicher Ausstellung/Erneuerung der Zertifikate ausgeführt werden soll. Damit der Webserver die neuen Zertifikate korrekt einbinden kann, wird nginx hier einfach kurz neu gestartet. Wenn hier mehrere Befehle ausgeführt werden sollen, sind diese durch ein Semikolon zu trennen.

Nach dem Generieren können alle von acme.sh ausgestellten Zertifikate auf dem System durch folgenden Befehl angezeigt werden:

acme.sh --list

Ebenfalls wird durch diesen Befehl die Gültigkeitsdauer der Zertifikate angezeigt (dazu später mehr).

Diffie-Hellman-Parameter erzeugen

Die Zertifikate selbst sind der wichtigste Punkt, wenn es um die Verschlüsselung der Verbindung über HTTPS geht. Um die Sicherheit noch weiter zu erhöhen, sollten noch sog. Diffie-Hellman-Parameter genutzt werden. Ohne nun die technischen Details zu beleuchten, geht es um einen sicheren Schlüsselaustausch bei Verbindungsaufbau. Die Generierung des Schlüssels muss dabei nur einmal erfolgen.

Achtung: Die Erzeugung der Diffie-Hellman-Parameter dauert gerade auf schwächerer Hardware sehr lange. Hier muss man bis zur Fertigstellung u.U. mehrere Stunden warten. In diesem Fall kann auch eine Schlüssel mit „nur“ 2048 Bit berechnet werden (die Zahl des zweiten Befehls gibt hierbei die Länge des Schlüssels in Bit an). Auf stärkerer Hardware ist allerdings eine Schlüssellänge von 4096 Bit empfehlenswert.

mkdir -p /etc/nginx/dhparams
openssl dhparam -out /etc/nginx/dhparams/dhparams.pem 4096

Einbinden der Zertifikate in nginx

Die Zertifikate können nun einfach mit nginx verwendet werden. Ich beschränke mich hier auf das reine Einbinden der Zertifikate und der entsprechenden SSL-Einstellungen.

Damit das Ganze übersichtlich bleibt, lagere ich die SSL-Settings immer in eine spezielle Datei aus, die dann später in die virtuellen Hosts eingebunden wird. Auf diese Weise sind alle Einstellungen bzgl. SSL nur an einem Ort zu finden.

Dazu legen wir zunächst eine neue Datei an:

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

Hier werden dann ausschließlich die Anweisungen für SSL aufgeführt:

# 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 '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.
# secp521r1: Not supported by Chrome
# secp384r1: Not supported by Android (DAVx5)
ssl_ecdh_curve secp521r1:secp384r1:prime256v1;

# 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;

Neben dem Einbinden der eigentlichen Zertifikate dienen alle weiteren Anweisung ebenso der Sicherheit/Verschlüsselung. Daher bitte auch die Kommentare in der Datei beachten.

Im jeweiligen virtuellen Host für HTTPS ist dann einfach diese ssl.conf einzubinden:

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;
	server_name meinedomain.de 192.168.178.60;
	
	include /etc/nginx/snippets/ssl.conf;	
	
	#
	# Here you would add the statements for some web applications, e.g. Nextcloud.
	#
}

Wichtig: Die SSL-Anweisungen dürfen nicht doppelt im server-Block für HTTPS aufgeführt werden. Wenn hier bereits Optionen angegeben sind, die ebenfalls in der Datei ssl.conf aufgeführt sind, dann sind diese im server-Block für HTTPS zu entfernen.

Nach einem Neustart des Webservers sollten die Zertifikate korrekt eingebunden worden sein:

service nginx restart

Überprüfung der Zertifikate

Abschließend lohnt eine Überprüfung der Zertifikate. Hierzu ist der SSL Server Test von Qualys SSL Labs gut geeignet. Mit der gezeigten Konfiguration sollte ein Rating mit A+ und 100% in allen Kategorien erreicht werden:

Ergebnis des SSL-Tests

Ergebnis des SSL-Tests

Falls hier eine niedrigere Bewertung angezeigt werden sollte, liegt dies vermutlich an der SSL-Konfiguration des Webservers. In diesem Fall sollten die entsprechenden Anweisungen der Datei ssl.conf nochmals kontrolliert werden.

Erneuerung der Zertifikate

Die Zertifikate von Let’s Encrypt sind nur für die Dauer von 90 Tagen gültig (Begründung siehe hier) und müssen anschließend erneuert werden.

Bei der Installation von acme.sh wurde ein Cronjob angelegt, der regelmäßig prüft, ob Zertifikate erneuert werden müssen und diese Erneuerung dann ggf. automatisch ausführt. Im Grunde genommen muss man sich daher gar nicht weiter um die Zertifikate kümmern.

Dennoch sollte man nach dem initialen Ausstellen der Zertifikate und Ablauf der 90 Tage kontrollieren, ob die automatische Erneuerung auch wirklich durchgeführt wurde.

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

acme.sh --list

Upgrade von acme.sh

Für acme.sh werden regelmäßig auch Updates veröffentlicht (siehe GitHub Release-Page). In diesem Fall kann das Skript mit nur einem Befehl auf den neusten Stand gebracht werden:

acme.sh --upgrade

Das Reizvolle daran ist nun, dass man diese Updates komplett ohne Abhängigkeiten von den Paketquellen der jeweiligen Distributionen einspielen kann.

Fazit

acme.sh macht als Let’s Encrypt Client einen sehr soliden Eindruck. Die Bedienung gestaltet sich recht einfach und da es sich um ein reines Shell Skript handelt, ist man unabhängig von Programmversionen in den Paketquellen einzelner Linux-Distributionen. Ebenfalls wird automatisch ein Cronjob für die Erneuerung der Zertifikate angelegt, so dass man sich nach der ersten Generierung der Zertifikate nicht mehr um deren Erneuerung kümmern muss. Aus genau diesen Gründen werde ich in Zukunft auch acme.sh als Let’s Encrypt Client empfehlen.

Abschließend noch ein Hinweis für Webserver-Admins, die noch einen anderen Let’s Encrypt Client verwenden und auf acme.sh umsteigen wollen: Der nächste Artikel hier im Blog wird den Umstieg zu acme.sh im Detail beleuchten…

Update: Der Artikel zum Umstieg von Certbot auf acme.sh ist online: Let’s Encrypt: Umstieg von Certbot auf acme.sh (nginx)

Weiterführende Artikel

Links

]]>
https://decatec.de/linux/lets-encrypt-zertifikate-mit-acme-sh-und-nginx/feed/ 23
Nextcloud: Direkter Zugriff auf Dateien über das Dateisystem https://decatec.de/home-server/nextcloud-direkter-zugriff-auf-dateien-ueber-das-dateisystem/ https://decatec.de/home-server/nextcloud-direkter-zugriff-auf-dateien-ueber-das-dateisystem/#comments Tue, 15 Jan 2019 17:10:40 +0000 https://decatec.de/?p=5062 Nextcloud Logo

Heute gibt es einen praktischen Tipp für Nextcloud: Der Artikel zeigt, wie man einen direkten Zugriff auf Cloud-Dateien direkt über das Dateisystem realisieren kann, ohne den Umweg über die Weboberfläche von Nextcloud oder WebDAV nehmen zu müssen.

Das Datenverzeichnis von Nextcloud

Bei der Installation von Nextcloud wird während des Setups das Datenverzeichnis der Cloud angegeben. Das ist ein lokales Verzeichnis, in dem u.a. die Daten gespeichert werden, die die Benutzer in die Cloud hochladen.

Der Zugriff die diese Dateien erfolgt dann üblicherweise über die Weboberfläche von Nextcloud. Alternativ kann auch per WebDAV auf die Cloud-Dateien zugegriffen werden, indem z.B. ein WebDAV-Netzlaufwerk unter Windows eingebunden wird.

Eine Anforderung könnte nun sein, dass ein direkter Zugriff auf die Nextcloud-Daten über das Dateisystem möglich sein soll. Auch wenn man nicht direkt Dateien auf dem Server kopieren/verschieben wird, ist diese Szenario durchaus relevant: Eine Freigabe per Samba oder FTP ist relativ schnell eingerichtet, da könnte man auf die Idee kommen, einfach das Nextcloud-Datenverzeichnis auf diese Art zugänglich zu machen. Anschließend könnte man nun Daten z.B. per Netzwerkfreigabe oder FTP ins Datenverzeichnis von Nextcloud transferieren. Diese sollten dann auch automatisch in der Weboberfläche von Nextcloud auftauchen, oder?

Leider ist die Sache nicht ganz so einfach. Wenn man versucht, Dateien auf diese Art Nextcloud „unterzujubeln“, dann wird man diese in der Weboberfläche nicht zu sehen bekommen. Die Begründung dafür ist recht einfach: Jede Datei und jedes Verzeichnis besteht nicht nur aus einem Eintrag im Dateisystem, sondern auch aus einem Eintrag in der Datenbank von Nextcloud. Ist die Datei nun auf dem Dateisystem vorhanden, aber es existiert kein Eintrag in der Datenbank, dann ist diese Datei für Nextcloud quasi nicht vorhanden.

Da dies nicht automatisch funktioniert, muss man nun Nextcloud veranlassen, das ganze Datenverzeichnis nach neuen und geänderten Dateien zu durchsuchen. Dazu bemühen wir einfach occ:

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

Je nach Umfang der Cloud kann dieser Befehl einige Zeit in Anspruch nehmen, aber nach dem Scan sind nun auch Dateien sichtbar, die man einfach manuell über das Dateisystem zum Datenverzeichnis hinzugefügt hat.

Für die Praxis ist dies leider keine gute Lösung, da man nun den Scan-Vorgang immer wieder anwerfen muss, wenn Dateien „hinten rum“ in das Datenverzeichnis kopiert wurden.

Die bessere Lösung: Verwendung von externem lokalem Speicher

Nextcloud überwacht sein Datenverzeichnis als nicht von selbst auf geänderte Dateien. Diese Option ist allerdings bei externem Speicher verfügbar. Hier kann man Nextcloud anweisen, bei jedem aktiven Zugriff auf neue und geänderte Dateien zu achten. Genau diese Option machen wir uns nun zu Nutze, damit man Dateien auch direkt über das Dateisystem der eigenen Cloud hinzufügen kann.

Lokalen externen Speicher einbinden

Zum Einbinden von lokalem externen Speicher benötigen wir erst einmal ein Verzeichnis auf dem lokalen Dateisystem, auf das Nextcloud (d.h. der Webserver-Benutzer) zugreifen kann:

mkdir -p /var/nextcloud_external_data
chown -R www-data:www-data /var/nextcloud_external_data

Auch PHP braucht natürlich Zugriff auf dieses Verzeichnis, so dass wir noch die Variable open_basedir anpassen müssen.

Für PHP FPM muss dazu der virtuelle Host für Nextcloud (siehe hier) modifiziert werden. Das soeben angelegte Verzeichnis wird bei fastcgi_param PHP_VALUE einfach bei open_basedir hinzugefügt. Der komplette Block kann dann z.B. so aussehen.

fastcgi_param PHP_VALUE "open_basedir=/var/www:/tmp/:/var/nextcloud_data:/dev/urandom:/proc/meminfo:/var/nextcloud_external_data/
	upload_max_filesize = 10G
	post_max_size = 10G
	max_execution_time = 3600
	output_buffering = off";

Damit auch der Cronjob von Nextcloud Zugriff auf das Verzeichnis hat, wird dieses ebenfalls in der entsprechenden php.ini Datei unter open_basedir hinzugefügt:

nano /etc/php/7.2/cli/php.ini

Der Eintrag kann hier z.B. dann so aussehen:

open_basedir = /var/www/:/tmp/:/var/nextcloud_data/:/var/nextcloud_external_data/

In den Einstellungen von Nextcloud kann dieses Verzeichnis nun als externer lokaler Speicher eingebunden werden. Dies kann jedoch nur in den Admin-Einstellungen erfolgen, da Benutzer nicht selbst externen lokalen Speicher einbinden können.

Nextcloud: Lokalen externen Speicher einbinden

Nextcloud: Lokalen externen Speicher einbinden

Folgende Optionen sind hier wichtig:

  • Ordnername: Kann beliebig vergeben werden. In der Dateiübersicht von Nextcloud erscheint der externe Speicher dann unter diesem Namen.
  • Konfiguration: Hier ist der Order auf dem lokalen Dateisystem anzugeben. In diesem Beispiel also /var/nextcloud_external_data.
  • Verfügbar für: Hier werden die Benutzer/Gruppen hinterlegt, für die der externe Speicher zugänglich sein soll.
  • Auf Änderungen prüfen: Diese Einstellung verbirgt sich in den erweiterten Optionen (Menü mit drei Punkten). Wichtig ist hier die Angabe Einmal bei jedem Direktzugriff.

Nach dem Speichern der Einstellungen sollte der externe Speicher erfolgreich eingebunden worden sein.

Hinzufügen von Dateien direkt über das Dateisystem

Durch die Option, dass Nextcloud den soeben eingebundenen externen Speicher bei jedem Zugriff auf Änderungen durchsuchen soll, können nun einfach Dateien über das Dateisystem hinzugefügt werden. Für einen schnellen Test legen wir einfach eine einfache Textdatei an:

nano /var/nextcloud_external_data/test.txt

Der Inhalt spielt für den Funktionstest keine Rolle, daher einfach irgendwas eingeben und die Datei speichern.

Wenn man nun wieder über die Nextcloud-Oberfläche im Browser das Verzeichnis des externen Speichers öffnet, wird die neu erzeugte Datei von Nextcloud erkannt und kann auch direkt bearbeitet werden.

Der nächste Schritt würde nun darin bestehen, einen „Direktzugriff“ auf das Verzeichnis des externen Speichers zu legen, beispielsweise per Samba-Freigabe oder auch per FTP.

Anschließend hat man einen direkten Zugriff auf die Dateien von Nextcloud (zumindest auf jene, die auf dem externen lokalen Speicher liegen).

Aus der Praxis – OCR von gescannten Dokumenten

Nun fragt sich der eine oder andere sicher: „Was bringt mir das?“

In der Praxis hat sich bei mir das gezeigte Vorgehen bei der Verwaltung von (gescannten) Dokumenten bewährt.

Dazu habe ich zwei lokale externe Speicher eingebunden: Scan Eingang und Dokumente Eingang. In das Verzeichnis Scan Eingang werden nun Dokumente oder Bilder gespeichert, die vom Scanner erfasst wurden (z.B. als PDF). Diese Dokumente besitzen noch keinen Text-Layer (OCR).

Um diesen Text-Layer hinzuzufügen nutze ich nun das Script OCRmyFiles. Details zu diesem Script habe ich bereits im Artikel Linux: OCR-Texterkennung für PDF-Dateien und Bilder beschrieben. Dieses Script wird nun regelmäßig per Cronjob aufgerufen (z.B. alle 30 Minuten). Das Script ist so konfiguriert, dass es als Eingangs-Verzeichnis den Order /var/nextcloud_external_data/scan_eingang nutzt (Eingebunden als Order Scan Eingang in Nextcloud). Als Ausgabeordner nutze ich /var/nextcloud_external_data/dokumente_eingang (In Nextcloud als Dokumente Eingang eingebunden).

Nun sorgt das Script dafür, dass Dokumente ohne Text-Layer erfasst werden, per OCR mit Text versehen werden und anschließend in den Order Dokumente Eingang in der eigenen Cloud verschoben werden.

Das ganze wäre nicht möglich, wenn die OCR-Dokumente direkt in das Nextcloud-Datenverzeichnis verschoben werden würden. Erst durch die Nutzung von lokalem externen Speicher bekommt Nextcloud mit, dass im Ordner Dokumente Eingang neue gescannte Dokumente mit Text-Layer verfügbar sind.

Zu guter Letzt werden die Dokumente dann vom Ordner Scan Eingang dann in den jeweils passenden Order verschoben (über die Weboberfläche von Nextcloud).

Fazit

Der direkte Zugriff auf Nextcloud-Dateien über das Dateisystem mag zunächst nicht sonderlich aufregend klingen. In der Praxis merkt man allerdings schnell, dass das Nextcloud-Datenverzeichnis nicht aktiv auf Änderungen überwacht wird.

Der kleine Umweg über lokalen externen Speicher lohnt allemal: Damit wird es zum einen möglich, dass Benutzer Dateien direkt über eine Samba-Freigabe oder auch FTP der Cloud hinzufügen können. Zum anderen eröffnen sich dadurch auch weitere Möglichkeiten, die Cloud-Infrastruktur durch Scripte, o.ä. für Automatisierungen zu nutzen.

Weiterführende Artikel

Links

]]>
https://decatec.de/home-server/nextcloud-direkter-zugriff-auf-dateien-ueber-das-dateisystem/feed/ 15