ubuntuusers.de

Guten Tag!

Für Backups spiegele ich mein Home-Verzeichnis auf einen zweiten Rechner, der alle Daten über Deja Dup mit GPG verschlüsselt und mit einem Server synchronisiert.

Ausgangsfragestellung: Über SSH sollen beide Rechner Lesezugriff, aber keinen Schreibzugriff auf die jeweils anderen Daten haben.

Lösungsansatz:

a) Ein Extra-Benutzerkonto anlegen.

b) SSH-Server so konfigurieren, dass nur über dieses Extra-Konto Zugriff erfolgen kann.

c) Dem neuen Konto Lesezugriff auf das Home-Verzeichnis des Hauptusers erteilen.

Problem: Wie setze ich c elegant und möglichst einfach um?

Ich hab schon mit chmod und umask gespielt, aber ich will ja möglichst mehr Sicherheit und weniger Chaos ☺

Hallo

Da sich bisher niemand gemeldet hat, fürchte ich mal, ohne das Sicherheitskonzept aufzuweichen, wird es nicht gehen.

testuser@ubu22-BW:~$ ls -la
insgesamt 72
drwxr-x--- 14 testuser users 4096 Nov 23 11:44 .
drwxrwxrwx 14 root     root  4096 Nov 22 10:04 ..
-rw-------  1 testuser users    5 Nov 22 10:07 .bash_history
-rw-r--r--  1 testuser users  220 Nov 22 10:04 .bash_logout
-rw-r--r--  1 testuser users 3771 Nov 22 10:04 .bashrc
drwxr-xr-x  2 testuser users 4096 Nov 23 11:23 Bilder
drwx------ 12 testuser users 4096 Nov 23 11:44 .cache
drwx------ 10 testuser users 4096 Nov 23 11:46 .config
drwxr-xr-x  2 testuser users 4096 Nov 23 11:23 Dokumente
drwxr-xr-x  2 testuser users 4096 Nov 23 11:23 Downloads
drwx------  3 testuser users 4096 Nov 23 11:23 .local
drwx------  4 testuser users 4096 Nov 23 11:44 .mozilla
Code

Ich hatte mal mit chmod -R 750 das /home/user eines testusers gesetzt, was aber unerwartete Nebenwirkungen hatte.

Danke dir für deine Antwort. Was meinst du mit unerwarteten Nebenwirkungen? Meinst du, dass du nicht alle Dateien erwischt hast? ☺

Ich hatte überlegt, $HOME auf 755 zu setzen. Das war ja früher standardmäßig so, wurde aber umgestellt. Wäre das ein Sicherheitsrisiko – jenseits davon, das ggf noch zu erstellende Newbie-Accounts mit schwachem Passwort meine Daten einsehen könnten? Neue Dateien und Ordner sind bei mir offenbar normalerweise auf 664. Sollte das so sein oder habe ich da schon irgendwas durcheinander gebracht? 😬

Zweite Überlegung war, den neuen readonly User in die Hauptgruppe des primären Users hinzuzufügen und $HOME auf 750 zu setzen. Wenn ich verstanden habe, ist das die Standard-Einstellung. Gibt es Situationen, in denen die Hauptgruppe zwingend Schreibrechte benötigt? Falls das eine Option wäre: Wie setze ich das auch für neue Dateien um? (> sudo chfn -o umask=XXXX BENUTZER ?!? 😇 )

Dritte Überlegung war, mit ACL zu arbeiten. Hat mich aber überfordert und nicht funktioniert.

Vierte Überlegung war, beim SSH-Server anzusetzen, um den Schreibzugriff einzuschränken. Die Informationen hierzu im Netz waren aber nicht so einheitlich, dass ich mich da allein kompetent genug fühle, Dinge auszuprobieren. Gibt es da Erfahrungswerte eurerseits? 🐸

Insgesamt wichtig: Es muss konsistent geregelt sein, damit beim Backup keine Dateien ausgelassen werden.

Wenn das eigentlich in ein anderes Forum gehört, gerne Bescheid sagen. Das ist halt irgendwie so ein Schnittstellen-Thema und wenn es einen ganz anderen Lösungsansatz für "passive" Backups übers Netzwerk gibt bin ich offen ☺

Fanta_Fisch schrieb:

Guten Tag!

Für Backups spiegele ich mein Home-Verzeichnis auf einen zweiten Rechner, der alle Daten über Deja Dup mit GPG verschlüsselt und mit einem Server synchronisiert.

Mir ist dein beschriebener Ablauf noch nicht so richtig klar.
Der 2. Rechner ist über ssh mit dem Server verbunden.

Wo befindet sich der Server?

• in deinem Netz

• ist es ein SSH-Server im Internet

Der Ablauf ist so aufgebaut:

• Auf meinem Laptop läuft ein SSH-Server. Der Laptop befindet sich im Heimnetzwerk.

• Ein zweiter Rechner holt sich die Daten von dort per Rsync.

• Der zweite Rechner macht verschlüsselte Backups der Daten von beiden Rechnern mit Deja Dup.

• Diese Backups werden mit Rsync über SSH mit einem Cloud-Server im Internet synchronisiert.

Im rsync Paket ist dafür ein 'rrsync' Script enthalten, das nur Lesezugriff erlauben soll.

In Verbindung mit SSH und einem eigenen SSH-Key kann man rrsync als vordefinierten Befehl setzen.

Das ist einfacher als deine Idee da irgendwelchen Benutzerkonten über ACLs oder sonstwie irgendwelche Leserechte einzuräumen.

Die einzige Frage ist dann wie wasserdicht das rrsync Script dann wirklich ist, aber da es teil des offiziellen rsync Pakets ist, sollte das ganz gut passen.

Danke dir für deine Antwort. Was meinst du mit unerwarteten Nebenwirkungen?

Ich weiß es leider nicht mehr genau, aber ich denke, z.B auf die .fetchmailrc und die .bashrc sollte aussser dem Besitzer niemand Zugriff haben.

Dass so die Rechte gesetzt sind, wird schon einen Grund haben

drwx------ 10 testuser users 4096 Nov 23 11:46 .config

Fanta_Fisch schrieb:

Ausgangsfragestellung: Über SSH sollen beide Rechner Lesezugriff, aber keinen Schreibzugriff auf die jeweils anderen Daten haben.

Rechner1 und Rechner2 sollen nur Lesezugriff auf den Cloud-Server haben. Das "Schreiben" der Daten erfolgt über den Weg:

1. Rechner 1

2. Rechner 2

3. Cloud-Server

Die Aufgabe des Rechner 2 ist also vom gespiegelte Home des Rechners 1, ein Backup per Deja Dup zu erstellen und diese Backup mit dem Cloud-Server aktuell zu halten.
Richtig oder falsch?

Fanta_Fisch schrieb:

Der Ablauf ist so aufgebaut:

• Auf meinem Laptop läuft ein SSH-Server. Der Laptop befindet sich im Heimnetzwerk.

• ...

• Diese Backups werden mit Rsync über SSH mit einem Cloud-Server im Internet synchronisiert.

Ist der 2. Rechner im gleichen Heimnetzwerk?

@frostschutz: Danke für den Tipp! ☺ Ich das schonmal auf Reddit oder so gelesen und ohne Nennung von Gründen wurde das als nicht sicher eingestuft. Dazu kommt, dass ich gerne auch über SFTP von einem Rechner auf den anderen zugreifen möchte - nicht nur per Rsync.

@Berlin_1946: Uah, so ähnlich ☺

Also Rechner 1+2 sind im gleichen Heimnetzwerk. Es geht darum, dass Rechner 2 Lesezugriff, aber keinen Schreibzugriff auf Rechner 1 erhält (und umgekehrt - für Dateiaustausch auch jenseits von Backups). Das Heimnetzwerk teile ich mir mit Nachbar*innen, ist also ein Stück weit offen.

Der Cloud-Server erhält bislang keinen Zugriff auf Rechner 2, sondern der Rechner lädt die Daten hoch. Rechner 2 hat dementsprechend Schreibzugriff auf die Cloud. Die Cloud ist ein Stück weit durch regelmäßige schreibgeschützte Snapshots geschützt. Das wäre dann der nächste Schritt zu schauen, ob sich zwischen Rechner 2 und Cloud noch was optimieren lässt 🦆

Hoffe, es ist so verständlicher ☺

Fanta_Fisch schrieb:

Also Rechner 1+2 sind im gleichen Heimnetzwerk. Es geht darum, dass Rechner 2 Lesezugriff, aber keinen Schreibzugriff auf Rechner 1 erhält (und umgekehrt - für Dateiaustausch auch jenseits von Backups). Das Heimnetzwerk teile ich mir mit Nachbar*innen, ist also ein Stück weit offen.

• Rechner 2 Lesezugriff, aber keinen Schreibzugriff auf Rechner 1 erhält

• Rechner 1 Lesezugriff, aber keinen Schreibzugriff auf Rechner 2 erhält

Das hat jetzt aber nichts mit ssh zu tun.

Der Cloud-Server erhält bislang keinen Zugriff auf Rechner 2, sondern der Rechner lädt die Daten hoch.

Was ist in diesem Zusammenhang mit "keinen Zugriff auf Rechner 2" gemeint?

Du hast also auf Rechner 2 eine Kopie des Home von Rechner 1 und eine Dateisicherungsdatei von Deja Dup des Home von Rechner 1.
Auf dem Cloud-Server liegt zusätzlich die Dateisicherungsdatei von Deja Dup des Home von Rechner 1

Zwei Sicherungen und an zwei Orten.

Hast du das schon mal getestet, die Daten vom Server auf den Rechner 1 wieder herzustellen?

Mit der Option an einem anderen Ort (sonst überschreibst du dein Home).

Das macht doch nur Sinn, dass wenn Rechner 2 auffällt, Rechner 1 per Deja Dup sein Home wieder herstellen kann.

Déjà Dup (Abschnitt „Alle-Daten-wiederherstellen“) siehe Hinweis.

Rechner 1 und Rechner 2 müssen immer die gleiche Version haben. So verstehe ich den Hinweis. Sonst passen das von Rechner 2 erzeugte Backup nicht zur Wiederherstellung auf Rechner 1.

Das hat jetzt aber nichts mit ssh zu tun.

Was meinst du genau - also wie kann ich das am besten lösen? (vgl. Antwort um 11:23 Uhr) ☺

Was ist in diesem Zusammenhang mit "keinen Zugriff auf Rechner 2" gemeint?

Damit ist gemeint, dass die Daten vom Heimnetzwerk aus in die Cloud übertragen werden. Rechner 2 erstellt mit Deja Dup ein verschlüsseltes Backup aller Daten inklusive der Daten, die von Rechner 1 übertragen wurden. Dieses Backup wird auf einer 2. Festplatte gespeichert. Die Backup-Dateien werden dann per SSH/Rsync in die Cloud hochgeladen.

Das mit dem Zugriff hab ich geschrieben, weil es theoretisch ja auch Sinn machen könnte, vom Cloud-Server aus auf die Backups auf Rechner 2 zuzugreifen und diese quasi von dort aus "herunterzuladen". Damit wäre dann auch die Gefahr gebannt, dass ein Trojaner von Rechner 2 aus die Daten in der Cloud überschreibt... falls das technisch überhaupt geht 😇

Hast du das schon mal getestet, die Daten vom Server auf den Rechner 1 wieder herzustellen?

Nein. Den Server habe ich mir erst kürzlich gemietet. Ich hoffe doch sehr, es klappt 😬

Das macht doch nur Sinn, dass wenn Rechner 2 auffällt, Rechner 1 per Deja Dup sein Home wieder herstellen kann.

Hierfür würde ich die Backupdateien aus der Cloud herunterladen. Diese würden dann alle Dateien von Rechner 2 enthalten, inklusive der Dateien, die von Rechner 1 übertragen würden. Davon könnte ich dann gezielt alle Daten wiederherstellen, die ich benötige. Grundsätzlich ist Deja Dup auf Rechner 1 installiert und sollte auch jeweils immer aktuell sein ☺

Zwei Sicherungen und an zwei Orten.

Genau - das Setup ist aktuell so:

• Rechner 1: Sicherungen auf drei Datenträgern (SSD/HDD/Cloud) an zwei Orten (Rechner 2 & Cloud-Anbieter).

• Rechner 2: Sicherungen auf zwei Datenträgern (HDD/Cloud) an zwei Orten (Rechner 2 & Cloud-Anbieter).

Fanta_Fisch schrieb:

Grundsätzlich ist Deja Dup auf Rechner 1 installiert und sollte auch jeweils immer aktuell sein ☺

aus dem Wiki:

Déjà Dup ist nur innerhalb einer Ubuntuversion abwärtskompatibel zu sich selbst. Wurde also nach einem Datenverlust "die Gelegenheit genutzt" und die nächsthöhere Version installiert, so sollte die Wiederherstellung von einem Livemedium der ursprünglich installierten Version erfolgen.

So wie ich das auslege, müssen auf beide Rechner die gleiche Ubuntuversion und die gleiche Programmversion von Deja Dup haben, sonst könnte es sein, dass keine oder nur einer die Daten wieder herstellen kann.

Datensicherung (Abschnitt „Abschliessend-das-Ergebnis-der-Datensicherung-kontrollieren“)

daraus zitiert:

• Lassen sich die gesicherten Dateien zurückspielen?

Achtung!

Letzterer Punkt stellt sich immer wieder als Schwachpunkt vieler Backup-Strategien heraus. Man sollte immer daran denken, dass man eine Wiederherstellung der Daten sicherstellen will und keine Daten, die nicht mehr zurückgespielt werden können!

Haha danke nochmal für die Sensibilisierung! Auf beiden Rechner läuft die gleiche Ubuntu-Version. Ich habe das auch schon einmal gedanklich durchgespielt aber du hast vollkommen recht, es ist besser, das auch nochmal praktisch Schritt für Schritt auszuprobieren. Mache ich noch, versprochen!

Realistischer wäre es aber wahrscheinlich, dass ich das Backup von Rechner 2 aus herunterlade und dann auch direkt dort wieder herstelle. Und dann per Rsync Home von Rechner 1 wieder zurückspiele. Also je nachdem was alles verbrannt/geklaut/verloren ist ☺

Beschäftigen tut mich aber immer noch das mit dem Lese-Zugriff... 🤓

PS: Grundsätzlich wäre es auch möglich, eine andere Backup-Software mit mehr "Wiederherstellungs-Stabilität" zu verwenden. Mir geht es eigentlich vor allem darum, dass die Daten ordentlich verschlüsselt und komprimiert werden, bevor sie in der Cloud landen.

PPS: Über diesen Artikel bin ich auf die Sache mit den Dateirechten gekommen: https://www.golem.de/news/security-wie-man-mit-ransomware-hackern-verhandelt-2312-180677-3.html Als Grundprinzip wird da empfohlen, dass kein User seine*ihre eigenen Backups löschen können sollte.

Eventuell hilft dir ACL weiter.

dingsbums schrieb:

Eventuell hilft dir ACL weiter.

Du meinst, dass ich per ACL dem zweiten Nutzerkonto rekursiv Leserechte auf Home einräume, oder? Ich habe das mal mit Eixiel und mit Dolphin ausprobiert - hat leider nicht geklappt. Und hinterher gab es mit einzelnen Dateien Rechte-Probleme. Und dann wäre da noch die Frage, wie zuverlässig das funktioniert (siehe Wiki-Artikel ganz unten). Gerade bei Backups möchte ich ja sicher gehen, dass z.B. keine Rechte-Probleme bei neuen Dateien auftreten, damit alles gesichert ist.

Aktuell habe ich Home auf 755 gesetzt.

• Alle User können nun lesen: Sicherheitsproblem?

• Manche sicherheitsrelevante Dateien (z.B. ~/.ssh, Signal-Messenger) lassen diese Rechte nicht zu und werden dementsprechend im aktuellen Setup nicht gesichert.

Im Netz habe ich noch einen anderen Lösungsvorschlag gefunden:

• Mit mount --bind den Home-Ordner an anderer Stelle schreibgeschützt einbinden - z.B. /readonly/home

• Für SSHD ein chroot einrichten, die den Zugriff auf /readonly/home beschränkt

Ergebnis

• Es bräuchte kein Extra-Nutzerkonto und keine Anpassung der Datei-Rechte. Alles könnte über SSH kopiert werden.

• Dateien könnten – unabhängig von den vergebenen Rechten – niemals über SSH gelöscht werden.

Was denkt ihr über diesen neuen Ansatz? Ich habe das noch nicht ausprobiert, weil er von der Einrichtung etwas anspruchsvoller ist - und da dachte ich, ich hole mir lieber nochmal eine zweite Meinung ☺

Zum Thema backward compability bzw. Wiederherstellungssicherheit - @Berlin_1946: Wäre restic eine zuverlässigere Alternative zu Deja Dup/duplicity?

We guarantee backward compatibility of all repositories within one major version; as long as we do not increment the major version, data can be read and restored. We strive to be fully backward compatible to all prior versions.

(https://restic.readthedocs.io/en/stable/090_participating.html#compatibility)