Raspberry Pi mit externem Datenträger als WireGuard-Client, Datengrab, Downloader und Backup-Ziel

[Raubsau]

Hallo,

ich habe einen Raspberry Pi 4 mit Raspi OS (Buster) aufgesetzt.

Jetzt möchte ich folgendes realisieren:

1. Eine externe SSD am USB-Port so einrichten, dass bestimmte Nutzer darauf schreiben und lesen können.
2. Mehrere Benutzer erstellen, die per SFTP nur auf ihr Verzeichnis auf der USB-Platte zugreifen können.
3. Die Benutzer sollen keine weiteren Aktionen ausführen können, keine Bash-Befehle etc., sondern nur per SFTP Backups per Duplicati erstellen.
4. Ein Download-Benutzer soll auf die SSD schreiben und lesen können, um den Download auf die SD-Karte zu vermeiden.

Zu 1: Ich kann die Festplatte partitionieren und mit ext4 formatieren. Mir fehlt die Methode, bestimmte Verzeichnisse nur für bestimmte Nutzer freizugeben (welche chown- oder chmod-Befehle brauche ich)?
Wie binde ich die Platte so ein, dass sie auch nach einem Reboot eingebunden bleibt und der Pi bei einem Fehler nicht hängen bleibt (`fstab`-Eintrag mit `nofail`?)

Zu 2: Mit adduser kann ich die Nutzer einzeln hinzufügen, und auch in eine Gruppe `backup_users` stecken. Nun soll jeder Benutzer der Gruppe `backup_users` nur auf sein Verzeichnis unter `/mnt/ext_usb/backup_users` zugreifen dürfen (chroot!?)

Zu 3: Keine Ahnung, wo ich einstelle, dass keine Shell benutzt werden darf.

Zu 4: Die Verzeichnisse, in die die Downloads kommen, sollen ebenfalls nicht für die Nutzer in `backup_users` verfügbar sein.

Da ich nicht alle Naselang alles neu aufsetzen möchte (vor allem wenn bereits Backups angelegt wurden), würde ich mich über Eure Unterstützung freuen.


Raubsau

(Eine SAMBA-Installation und -Einrichtung verschiebe ich auf später )

 

[musv]

1. Rechte:
Dafür hast du 2 Möglichkeiten: normales Rechtesystem oder ACLs.
Normale Rechte:
Je nach Komplexität Deines Vorhabens ist das entweder das Mittel der Wahl oder artet in ein komplexes Gebilde aus.

Wenn jeder Nutzer ausschließlich auf sein eigenes Verzeichnis Zugriff haben soll, bist du am besten dran, wenn:

• die primäre Gruppe dem Nutzer entspricht, also nichts users ist. Bsp: uid=1001(userabc) gid=1001(userabc).
• die Verzeichnisrechte auf 700 und Dateirechte auf 600 gesetzt werden, d.h.
  You do not have permission to view link please Anmelden or Registrieren
  auf 0077.

Sollen alle Nutzer zumindest lesenden Zugriff auf alle Homes haben:

• primäre Gruppe (gid) auf users bei jedem User setzen
• Verzeichnisrechte auf 750, Dateirechte auf 640, Umask auf 0027

Kompliziert wird's wenn bestimmte User auf bestimmte Userverzeichnisse zugreifen können sollen und andere wiederum nicht. Dann musst du mit den sekundären Gruppen und dem

You do not have permission to view link please Anmelden or Registrieren

-Bit anfangen, um die Rechte zu vererben. Das wird aber ausführlicher. An der Stelle wären dann ACLs eher das Mittel der Wahl.

You do not have permission to view link please Anmelden or Registrieren

Du setzt die primäre Gid auf die User-ID (siehe oben). Über die ACLs kannst du dann konfigurieren, welcher Nutzer bzw.welche Gruppe dann noch Lese- und/oder Schreibrechte bekommen sollen. Wichtig ist dabei, dass du die Default-Rechte für die Verzeichnisse initial gleich mit setzt, um die Vererbung der Rechte bei neuen Dateien/Verzeichnissen zu aktivieren. ACLs erscheinen anfangs kompliziert, sind aber eigentlich sehr pflegeleicht, wenn man's einmal kapiert hat.

1. + 3.
Die Nutzer werden ganz normal erstellt. Da gibt's keine Unterscheidung. Der Rest ist hier besser erklärt, als ich das könnte:

You do not have permission to view link please Anmelden or Registrieren

Chroot in die User-Directory ist dabei das Entscheidende, was du willst.

2. Backup-User
Siehe Rechte: Du packst die Backup-Nutzer alle in die sekundäre Gruppe backup_user (gpasswd -a userabd backup_user). Dann setzt du das Backup-Verzeichnis auf die Zugehörigkeit root:backup_users mit den Rechten 1770. Die 1 dabei ist das

You do not have permission to view link please Anmelden or Registrieren

. Bei Dateien hat das keine Bedeutung mehr. Bei Verzeichnissen hat das die Wirkung, dass jeder User nur in das Verzeichnis schreiben darf, was er auch selbst angelegt hat.

Alternativ kannst du auch wieder ACLs setzen.

Vorgehensweise:
Setz Dich erst mal in Ruhe hin und schreib Dir auf, welche User es geben soll, und wer in welchem Verzeichnis lesen und schreiben können soll. Deine Schilderungen sind sowohl mit den

You do not have permission to view link please Anmelden or Registrieren

als auch mit ACLs umsetzbar. Aber du musst Dich auf alle Fälle erst mal in beide Sachen einlesen und probieren. Das Ganze ist nicht trivial.

 

[der]

Gibt's da keine NAS Oberfläche wie openmediavault oder so für den pi?
Wobei ich statt einem pi immer lieber einen odroid hc2 oder so nehmen würde.

 

[Raubsau]

Hallo @musv, danke für Deine sehr auführliche Antwort!
Vielleicht nehme ich mir dafür wirklich besser mal einen Tag Zeit und gehe strukturiert statt copy & paste vor.

@der ja, openmediavault gibt es für den Raspberry Pi. Das hatte ich zuerst auch am Wickel, allerdings hatte ich eine SSD am Rapsberry, die ich dann entfernen musste - und dann fingen die Probleme an: Freigegebene Verzeichnisse konnten nicht gelöscht werden, warum habe ich nicht herausgefunden. Mit vorhandenen Freigaben lässt sich ein Datenträger nicht entfernen, sodass ich eine als "nicht mountbar" angezeigte Platte im System hatte, dich de facto nicht mehr angeschlossen war.
Daraufhin habe ich das ganze abgebrochen und versucht, das ganze händisch zu machen (s.o.)

Testweise habe ich mal einen größeren Download auf eine (funktionierende) SSD speichern lassen, die Performance war wesentlich besser als auf die SD-Karte zu schreiben, aber nicht atemberaubend schnell. Für meine Zwecke sollte es reichen.

 

[musv]

Wenn du soweit bist und an irgendeiner Stelle Unklarheiten bestehen, kannst du das konkrete Problem hier auch noch mal schildern. Ich muss mich öfters mit dem Kram rumschlagen.

 

[thom53281]

Ich würde das ja viel einfacher lösen. Von wie vielen Benutzern sprechen wir denn? Wenn die Zahl überschaubar ist, auf der externen HDD Partitionen für jeden Benutzer anlegen, bestenfalls über LVM um flexibel zu bleiben. Das ist dann auch gleich eine gute Gelegenheit, eine Verschlüsselung zu implementieren. Die einzelnen Volumes dann in's Homeverzeichnis des jeweiligen Benutzers mounten. Dann kann der normal auch nicht mehr viel auf die SD-Karte schreiben.

 

[Steev]

OMV gibt's für'n Pi, mehr als smb habe ich damit aber bisher nicht gefrickelt bekommen. Hat aber eine intuitive leicht verständlich e (good looking) Oberfläche im Browser

 

[Raubsau]

--- EDIT ---
[src=bash]
# Once:
sudo groupadd duplicati_backups

sudo nano /etc/ssh/sshd_config:
# add block at file end:
Match Group duplicati_backups
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no

sudo service ssh restart

# For every user:
sudo mkdir -p /home/chroot/backupuser1
sudo useradd -d /home/chroot/backupuser1 -s /bin/false -G duplicati_backups backupuser1
sudo passwd backupuser1 #foo
sudo chown root:root /home/chroot/backupuser1
sudo chmod 711 /home/chroot/
sudo chmod 755 /home/chroot/backupuser1
sudo chown root:root /home/chroot/backupuser1
sudo mkdir /home/chroot/backupuser1/backup_files
sudo chown backupuser1:backupuser1 /home/chroot/backupuser1/backup_files
mkdir -p /mnt/ext_usb/duplicati_backups/backupuser1/backup_files
sudo chown backupuser1:duplicati_backups /mnt/ext_usb/duplicati_backups/backupuser1/backup_files[/src]

[src=bash]sudo nano /etc/fstab:[/src]
# add line:
[src=bash]/mnt/ext_usb/duplicati_backups/backupuser1/backup_files /home/chroot/backupuser1/backup_files none bind 0 0[/src]

[src=bash]sudo mount /home/chroot/backupuser1/backup_files[/src]

Spoiler

--- ALT ---

Hallo,

ich habe folgendes zusammengepfriemelt:
[src=bash]
sudo groupadd duplicati_backups &&
sudo mkdir /mnt/ext_usb/duplicati_backups &&
sudo mkdir /mnt/ext_usb/duplicati_backups/backupuser1
sudo mkdir /mnt/ext_usb/duplicati_backups/backupuser1/backup_files
sudo useradd -g duplicati_backups -d /mnt/ext_usb/duplicati_backups/backupuser1/backup_files -s /bin/false backupuser1
sudo passwd backupuser1 #foo
sudo chown backupuser1:duplicati_backups /mnt/ext_usb/duplicati_backups/backupuser1/backup_files

# sudo deluser --remove-home backupuser1 && sudo rm -r /mnt/ext_usb/duplicati_backups && sudo delgroup duplicati_backups
[/src]


Die sshd_config:
[src=bash]
Match User backupuser1
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
X11Forwarding no
[/src]

Mit sftp backupuser1@192.168.X.Y bekomme ich [src]packet_write_wait: Connection to 192.168.X.Y port 22: Broken pipe
Connection closed[/src]


Irgendwo liegt es an den Permissions für /ext/ext_usb/duplicati_backups; denn wenn ich den Nutzer ohne [src=bash]-d /mnt/ext_usb/duplicati_backups/backupuser1/backup_files[/src]erstelle, funktioniert es.

Was mache ich falsch?

EDIT:
Ich bekomme mittels tail -f /var/log/auth.log die Meldung: [src=Bash]fatal: bad ownership or modes for chroot directory component "/mnt/ext_usb/"[/src].
/ext_usb/ enhält aber noch andere Ordner, die ich mit einem anderen Benutzer beschreiben möchte.

Habt Ihr eine Idee? Sollte ich den Benutzer backupuser1 normal erstellen (mit $HOME in /home/backupupser1) und dann per symlink /mnt/ext_usb/duplicati_backups/ backupuser1 einbinden?