sftp server mounten: sshfs ohne Passwort-Eingabe ?

[pit234a]

Einer meiner EMaill-Provider hatte mir irgendwann wegen meiner großen Geduld (als langjähriger Kunde) einen Web-Space von 100G geschenkt.
Das hatte ich erst mal fleißig ignoriert, beginne aber nun damit zu spielen.
Dieser Webspace ist ein SFTP-Server für den ich Nutzername und Passwort erhalten habe.
Das ist gut, es ist irgendwie genau das, was ich überhaupt haben möchte.

Also, einloggen über Konsole oder Filezilla ist kein Problem, entsprechend auch das Hin- und Herladen von Daten nicht.
Das habe ich getan und will diese Daten dann auch mal aktualisieren. Dafür nutze ich dann SSHFS aus der Konsole und ebenfalls kein Problem. Anschließend RSYNC aus der Konsole, etwas lahmer, als erwartet, aber alles gut.

So weit so gut, aber nun möchte ich die Aktualisierung mit rsync gerne in einem Script automatisieren und scheitere daran, dass ich sshfs nicht ein Passwort mitgeben kann.
Versucht habe ich es mit sshpass, erfolglos.
Gelesen habe ich von der sshfs Option -o IdentityFile, wo ich scheinbar auch (außer keys) ein Passwort hinterlegen könnte, aber in der FreeBSD-man zu sshfs sehe ich von dieser Option nichts.

Mir käme es also darauf an, die SFTP-Freigabe über Script oder (nicht so gerne) Eintrag in der fstab zu mounten, ohne dabei aktiv mein erhaltenes Passwort tippen zu müssen.
Wenn das ohne Umweg über sshfs geht, würde mir das noch besser gefallen.
Wenn ich sshfs nutzen muss, bleibt die Frage: wie geht das denn inaktiv und automatisiert?

 

[double-p]

Was geht denn an sshpass nicht?

Sonst noch so frei sshfs -o password_stdin

 

[turrican]

Funktioniert das nicht wie ne normale 'passwordless' ssh-Connection?
Also, z.B. nen ed25519 Pubkey generieren, zum Server übertragen und ab da dann passwortlos einloggen, rsyncen, sshfs-en?


Ansonsten, leg mal ein ~/.ssh/config File an, Inhalt der Host, der Username und das Keyfile für diesen Host:

Host <servername.domain.tld>
  User <username>
  IdentityFile ~/pfad/zum/keyfile/fuer/diesen/host

 

[KobRheTilla]

Funktioniert das nicht wie ne normale 'passwordless' ssh-Connection?

Dieser Webspace ist ein SFTP-Server für den ich Nutzername und Passwort erhalten habe.

Die Frage ist zuerst: kann man beim Anbieter einen Schlüssel hinterlegen?

Rob

 

[Azazyel]

Ein Versuch mit ssh-copy-id kann nicht schaden, der nimmt auch automatisch das passende Verzeichnis auf dem Server.

Falls du uns den Anbieter verrätst, können wir vielleicht auch genauer Auskunft erteilen...

 

[GrandDixence]

Das habe ich getan und will diese Daten dann auch mal aktualisieren. Dafür nutze ich dann SSHFS aus der Konsole und ebenfalls kein Problem. Anschließend RSYNC aus der Konsole, etwas lahmer, als erwartet, aber alles gut.

Wäre hier nicht der Einsatz von Rclone angebracht? Siehe dazu die Rclone-Hinweise unter:

Zugriff auf Android Smartphone über Heimnetzwerk irgendwie möglich?

Ich würde gerne über ein FreeBSD Terminal von meinem Hauptrechner aus auf mein Smartphone zugreifen können, z.B. um auf einfachem Wege (ohne ein USB-Kabel einstöpseln zu müssen) auf Bilder zugreifen zu können. Die IP Adresse von dem Smartphone ist 192.168.1.38, doch in einem Scan mit nmap...

www.bsdforen.de

SFTP

SFTP

rclone.org

FreshPorts -- net/rclone: Sync files to and from various cloud services

Sync files to and from Google Drive, S3, Swift, Cloudfiles, Dropbox and Google Cloud Storage

www.freshports.org

Zum Thema "Public-Key-Authentifizierung" gibt es von Heise einen kostenpflichtigen, ausführlichen und lesenswerten Artikel:

Schlüsselmeister

Die Secure Shell (SSH) ist eines der wichtigsten Werkzeuge für alle, die beruflich oder privat Server administrieren und regelmäßig Systeme fernwarten. Mit ein paar Kniffen gestalten Sie Ihren SSH-Alltag komfortabler und nehmen Schlüssel dank FIDO2 mit auf Reisen, ohne Kompromisse bei der...

www.heise.de

 

[foxit]

Einfach den Public Teil deines SSH Keys in die Datei: .ssh/authorized_keys kopieren. Danach kann man sshfs ohne Passwort nutzen, wenn ein SSH Agent auf dem System läuft natürlich!
PS: Daten sind hoffentlich verschlüsselt, bevor sie auf den Webspace kopiert werden!

 

[pit234a]

danke schon mal für die Antworten.
Es ist so, dass ich natürlich zunächst versuche, nicht mit neuen Anwendungen zu arbeiten, sondern das einsetze, was ich schon habe und halbwegs kenne.
Auf der HP des Providers war ich noch gar nicht unter Wegs, es ist IONOS, der Nachfolger? von 1und1 und ich weiß nicht, ob die die Sache mit den keys können bzw anbieten. Ich habe das bisher noch nie gemacht und deshalb anders angefangen, bin aber durchaus nicht auf meine Methode festgelegt.

Die Sache mit sshpass verstehe ich auch nicht wirklich.
Mein Befehl ist ja:

sshpass -p "passwort" sshfs user@homesowieso.1and1-data.host:/Backups /media/sshfs

und das geht nicht.
Wenn ich mir dann ansehen will, wieso es nicht geht und ein -d anhänge und zusehe, dann geht es plötzlich doch. Deshalb vermute ich hier, dass ich es nicht richtig mache. Da muss ich mir die man noch mal ansehen.

Bisher teste/spiele ich noch damit und habe keine interessanten Daten dort hinterlegt.
Ob ich das mal nutzen werde und wie, ist noch nicht entschieden. Dass dann die Daten dort verschlüsselt sein sollten, ist klar, aber auch hier weiß ich noch nicht, wie ich das dann machen will. Ich liebe ja GNU-PG, aber das ist da nicht so performant bei vielen Daten. So eine "on-the-fly" Verschlüsselung wäre hier vielleicht mein Wunsch. Mal sehen.

 

[pit234a]

Das Ding hat für mich derzeit nicht die höchste Priorität, aber irgendwo drückt es dann doch, wenn ich nicht das machen kann, was mir so vorschwebt und was alle Anderen anscheinend leicht können.

Das hat nun funktioniert:

sshfs user@homewieauchimmer.1and1-data.host:/Backups /media/sshfs -o ssh_command='sshpass -p password ssh' -o delay_connect -C

Alle meine Versuche mit sshfs und -o password_stdin scheiterten bislang, entweder, weil ein ssh_askpass nicht gefunden wird, oder weil die Option angeblich nicht von fuse unterstützt wird. Auch hier ist sicher meine Syntax nicht korrekt.
Das ist aber alles auch nicht einfach.

Bevor ich was Anderes vielleicht noch teste, will ich erst noch einige weitere Optionen von sshfs durch spielen.
Stück für Stück, Schritt für Schritt und erst habe ich nun mal einen brauchbaren Ansatz für eine Automatisierung.
Danke nochmal.

 

[pit234a]

Nachdem ich dann die vorhergehenden Tips nochmal gelesen habe, kam mich das Passwortless-SSH gar nicht so so kompliziert vor.
Einen Key hatte ich offenbar bereits generiert, oder ist der immer da?

ssh-copy-id -i ~/.ssh/id_rsa.pub user@homewerweiß.1and1-data.host

hat funktioniert und ich konnte dann zunächst ohne Passwort über ssh einloggen.

Weiter gehe ich noch nicht, weil derzeit eine Datenübertragung auf das Share läuft.

Das ist ziemlich cool und ich frage mich, wieso ich davor immer solche Hemmungen hatte.
Nur: wie geht das von anderen PCs aus?
Muss ich jedes mal einen neuen Key generieren und verteilen, oder kann ich einfach die Key-Files übernehmen und gut ist?
Klar, das ist ein einfacher Test, mit dem ich mir die Frage dann selbst beantworten kann. Muss dann aber erst einen Rechner aus-kramen und noch starten und sehen, was passiert.

 

[medV2]

Du kannst entweder das Keyfile auf alle deine Rechner verteilen, oder für jeden PC ein eigenes Keypair generieren und die jeweiligen Publickeys in die .ssh/authorized_keys eintragen. Oder eben mit ssh-copy-id kopieren.

Letzteres ist sicher die bessere Lösung da du, wenn du einem Key nicht mehr traust (weil z.b. das Notebook oder das Handy gestohlen wurde), nur den entsprechenden Publickey löschen musst.



Bezüglich Verschlüsselung: Am einfachsten und transparentesten wäre es wohl einfach ein verschlüsselndes FS nochmal als Layer über das sshfs zu legen. Für Freebsd hast du da mit PEFS builtin Möglichkeit, über FreeBSD Grenzen hinaus wären da encFS und gocryptFS. Beides läuft über FUSE, encFS ist älter und hat wohl Sicherheitsprobleme wenn verschiedene Versionen gleicher Datein verschlüsselt gespeichert werden. GocryptFS ist der inoffizielle Nachfolger, ist noch jünger aber deutlich moderner in der Architektur.

 

[schorsch_76]

Mit sshfs geht es wenn man den key in der .ssh/config hinterlegt. Dann geht ein

sshfs georg@vdr:/data/media /mnt

ohne Passwort Eingabe.

Host vdr
    User georg
    Hostname ipipip
    IdentityFile ~/.ssh/mykey

 

[pit234a]

Ich bin ja noch am Spielen und überlegen.
Nun denke ich, dass ich im Grunde das Remote-Verzeichnis gar nicht zu mounten brauche und stattdessen direkt über rsync aktualisieren kann.
In der Spielphase ist es natürlich irgendwie cool, wenn man die Ergebnisse direkt visualisieren kann, sprich, im Dateimanager einfach sieht, dass etwas passiert und auch Dateien oder Verzeichnisse erst mal per Drag_n_Drop kopieren kann.
Wenn ich mich aber erst mal entschieden habe, ob und was dort sein soll, könnte ich ja in Zukunft nur noch von meinem Arbeits-PC das Backup auf dem Remote-SFTP aktualisieren. Das könnte ich einfach durch eine zusätzliche Zeile in meinem nächtlichen Backup-Script einbauen.
So etwas der Art:

rsync -crltvWhz --delete-after --force -e "ssh -C -l user" BSD-Sicherungen/ user@homeirgendwas.1and1-data.host:Backups/BSD-Sicherungen/

Also deshalb in der Art, weil das meinen üblichen Zeilen sehr nahe kommt, mit denen ich eh bereits arbeite.

Das komplette Konzept hängt sehr davon ab, wie ich das und ob überhaupt in Zukunft nutzen will. Ich fürchte, dass ich auch einen Zugang für GNU/Linux haben möchte und deshalb was Verschlüsselung angeht, nicht nur auf FreeBSD-Mechanismen setzen kann.
Ein kurzer Test mit einem ZSTD Archiv, das dann mit GPG verschlüsselt wird, hat zwar überraschende Kompression erzielt, aber das wars dann auch. Denn es ist sehr unpraktisch, dieses Archiv zu updaten und dann auch wieder zu verwenden. Rein zum Auslagern der wichtigsten Daten-Kopien hätte mir das gefallen. Für aktuelle und ständig aktualisierte Backups allerdings nicht.

Wie auch immer, dank eurer Hilfe bin ich nun ein "password-less" ssh-user und das alleine war diesen Beitrag schon Wert. Damit vereinfachen sich einige alte Routinen, sprich scripts, die ich gerade sortiere und durchgehe.

 

[GrandDixence]

Denn es ist sehr unpraktisch, dieses Archiv zu updaten und dann auch wieder zu verwenden. Rein zum Auslagern der wichtigsten Daten-Kopien hätte mir das gefallen. Für aktuelle und ständig aktualisierte Backups allerdings nicht.

Ein Art tägliches gar oder stündliches "Inkrementelle Backup" lässt sich hochperformant beim Einsatz eines CoW-Dateisystems (CoW => Copy-On-Write) realisieren. Also unter FreeBSD mit ZFS und unter Linux mit btrfs. Ist also klar eine Betriebssystem-abhängige Lösung!

Dazu verwendet man den send/receive-Mechanismus des CoW-Dateisystems in Kombination mit Dateisystem-Snapshots. Ein Einstieg dazu bietet:

LEAP 15.3 Empfehlung "bare-metal-disaster-recovery-backup-software" - Veeam-Alternativen

Hallo, bis jetzt habe ich für mehrere Linux-PCs für o.g.Backup Veeam genutzt und habe früher gute Erfahrungen mit dem Recover gemacht - auch bei von mir betreuten Windows-PCs. Leider macht Veeam bereits bei der Installation unter openSUSE 15.3 neuerdings diverse Probleme, sodass ich der...

forums.opensuse.org

ZFS Backup auf neue HDD

Hallo zusammen, nicht zur Strafe sondern nur zur Übung hab ich gestern mal mein ZFS Backup auf eine neue Platte spielen wollen um zu sehen ob ich im Fehlerfall auch alles hin bekomme. Leider Hab ich noch ein Problem :confused: Ich habe die Partitionstabelle mit "gpart show ada2 > ada2.txt" ins...

www.bsdforen.de

how to use zfs send | zfs receive to back up my current pools to a 10TB transfer disk?

After I've noticed that cp isn't a fool-proof way of making a backup of your zfs pools' data, I was pointed to zfs send and received. I looked around but I sure would like some help: how would one backup all /mnt/POOL/* data to /mnt/TRANSFERDISK? I'm planning to add disks to my existing ZFS so...

www.truenas.com

NAS Backups, Part 2: Btrfs send / receive

Hey there! In the first post of this series, I talked about my plan for a backup NAS to complement my main NAS. In this part, I'm going to show the pa.... (click to read more)

starbeamrainbowlabs.com

• Mit "zfs send" die Differenzen zum (vor-)letzten ZFS-Snapshot in eine Pipe schreiben.
• den Pipe-Inhalt mit lz4 komprimieren und dann
• Pipe-Daten verschlüsseln (gpg mit Hardwarebeschleunigung => AES-NI)
• und die Pipe-Ausgabe als Datei auf die SFTP-Ablage schreiben.

Die Daten von der SFTP-Ablage holt man dann mit "zfs receive" (irgendwie?) wieder zurück. => Klar ungetestete Lösung!

Statt zstd hätte ich lz4 eingesetzt. LZ4 ist offenbar noch ein Quäntchen schneller als zstd. Nachteil: Schlechtere Kompressionsrate. Siehe dazu:

https://indico.fnal.gov/event/16264/contributions/36466/attachments/22610/28037/Zstd__LZ4.pdf

LEAP 15.3 Empfehlung "bare-metal-disaster-recovery-backup-software" - Veeam-Alternativen

Hallo, bis jetzt habe ich für mehrere Linux-PCs für o.g.Backup Veeam genutzt und habe früher gute Erfahrungen mit dem Recover gemacht - auch bei von mir betreuten Windows-PCs. Leider macht Veeam bereits bei der Installation unter openSUSE 15.3 neuerdings diverse Probleme, sodass ich der...

forums.opensuse.org

Für die Verschlüsselung und Entschlüsselung mit gpg (oder openssl) siehe auch:

How to use OpenSSL to encrypt/decrypt files?

I want to encrypt and decrypt one file using one password. How can I use OpenSSL to do that?

stackoverflow.com

Und mit dem Parameter "-e" oder "--embed" scheint sogar der Pipe-(De-)Komprimierungsschritt überflüssig zu sein. Siehe # man zfs-send und # man zfs-receive.

zfs-send

www.freebsd.org

zfs-receive

www.freebsd.org

 

[medV2]

Ich bin ja noch am Spielen und überlegen.
Nun denke ich, dass ich im Grunde das Remote-Verzeichnis gar nicht zu mounten brauche und stattdessen direkt über rsync aktualisieren kann.
In der Spielphase ist es natürlich irgendwie cool, wenn man die Ergebnisse direkt visualisieren kann, sprich, im Dateimanager einfach sieht, dass etwas passiert und auch Dateien oder Verzeichnisse erst mal per Drag_n_Drop kopieren kann.
Wenn ich mich aber erst mal entschieden habe, ob und was dort sein soll, könnte ich ja in Zukunft nur noch von meinem Arbeits-PC das Backup auf dem Remote-SFTP aktualisieren. Das könnte ich einfach durch eine zusätzliche Zeile in meinem nächtlichen Backup-Script einbauen.
So etwas der Art:

rsync -crltvWhz --delete-after --force -e "ssh -C -l user" BSD-Sicherungen/ user@homeirgendwas.1and1-data.host:Backups/BSD-Sicherungen/

Also deshalb in der Art, weil das meinen üblichen Zeilen sehr nahe kommt, mit denen ich eh bereits arbeite.

Rsync benötigt eine Shell am Zielserver, du hast expliziert von einem sftp Zugang gesprochen, da wird sowas dann nicht funktionieren.

Wie hier schon erwähnt kann rclone hier dein Freund sein. Das könnte auch wieder lokal ein FS Darstellen überdass du eine verschlüsselung legen kannst.

Allgemein finde ich gpg für den Zweck den du vorhast nicht wirklich geeignet. Entweder du nimmst ein verschlüsselndes FS transparent als Layer über sshfs oder rclonefs, oder du nutzt direkt ein Tool, was sich automatisch um sowas kümmert.

Ein Art tägliches gar oder stündliches "Inkrementelle Backup" lässt sich hochperformant beim Einsatz eines CoW-Dateisystems (CoW => Copy-On-Write) realisieren. Also unter FreeBSD mit ZFS und unter Linux mit btrfs. Ist also klar eine Betriebssystem-abhängige Lösung!

ZFS on Linux ist mit dem aktuellen ZFS on FreeBSD kompatibel. Wenn man beide Systeme nutzen möchte ist das ne Option. Ansonsten würde ich unter Linux auch eher zu btrfs raten, wenn man keine zfs Features braucht.

Bezüglich zstd vs lz4: Ja, zstd ist in der Defaulteinstellung spürbar langsamer als lz4. Kommt halt auf den Anwendungsfall an ob man damit klar kommt, beim Wöchentlichen Backup auf die externe HD oder ähnlichem wär mir das z.b. egal. Man kann zstd aber sehr gut konfigurieren, man kann den Defaultwert (3) z.b. auf 1 stellen, da komprimiert man immer noch deutlich besser als lz4, aber auf modernen PCs merkt man da keinen unterschied mehr. Geht unter btrfs und zfs. zfs kann sogar noch zfs-fast und hat dafür eigene Optionen. zfsfast-10 sollte z.b. sehr ähnlich wie lz4 sein.

 

[Andy_m4]

So mal als Ergänzung:

Man kann zstd aber sehr gut konfigurieren, man kann den Defaultwert (3) z.b. auf 1 stellen, da komprimiert man immer noch deutlich besser als lz4, aber auf modernen PCs merkt man da keinen unterschied mehr.

Das wirklich Coole an zstd ist, das es beim Dekomprimieren immer die gleiche Performance liefert. Egal wie hoch Du den Kompressionslevel drehst.
Das kann man sich zunutze machen. Wenn man weiß, das man Daten hat die kaum geschrieben werden aber sehr viel gelesen, dann lohnt natürlich eher ein voll aufgedrehtes zstd, als wenn man das nicht hat.

Entweder du nimmst ein verschlüsselndes FS transparent als Layer

Wenn das für Backup-Zwecke ist, könnte man sogar darüber nachdenken, ob man das entsprechende ZFS-Dataset nicht gleich verschlüsselt und dann quasi den verschlüsselten Snapshot (also Option --raw bei zfs-send) direkt auf den Server schiebt. :-)

 

[mr44er]

Das wirklich Coole an zstd ist, das es beim Dekomprimieren immer die gleiche Performance liefert. Egal wie hoch Du den Kompressionslevel drehst.

Das stimmt. Aber man sei gewarnt, dass sich zstd-19 beim Schreiben irgendwo zwischen Anker geworfen und abgestürzt anfühlt.

ob man das entsprechende ZFS-Dataset nicht gleich verschlüsselt und dann quasi den verschlüsselten Snapshot (also Option --raw bei zfs-send) direkt auf den Server schiebt.

Das wäre auch mein Ansatz. Lesenswert dazu: https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-to-openzfs-native-encryption/
Sowie der wichtigste Satz:

If you forget to use -w when zfs sending a dataset with its key loaded, the replication will work—but the target will be unencrypted!

-w/--raw macht das Gleiche, ich persönlich kann mir --raw besser merken im Sinne von roh senden, exakt wie es ist.

 

[GrandDixence]

Rclone unterstützt mit dem Modul "crypt" die verschlüsselte Datenablage auf SFTP-Ablage.

Crypt

Encryption overlay remote

rclone.org

Eine Verzeichnissynchronisation mit Rclone auf eine SFTP-Ablage sollte einfach als Cronjob realisierbar sein. Der Cronjob wird stündlich oder einmal täglich gestartet um die SFTP-Ablage mit den Änderungen auf der lokalen Ablage zu aktualisieren.

Dieser Rclone-Cronjob könnte mit normalen Benutzerrechte (User: foo) gestartet werden. Sicher ein Vorteil gegenüber der Dateisystemsynchronisation per Send-/Receive-Mechanismus von CoW-Dateisystemen. Der Cronjob für zfs send und zfs receive müsste wohl oder übel mit Administratorrechten (User: root) gestartet werden.

 

[Andy_m4]

Das stimmt. Aber man sei gewarnt, dass sich zstd-19 beim Schreiben irgendwo zwischen Anker geworfen und abgestürzt anfühlt.

Ja. Das kann bei Videoschnitt schon mal ein bissl ausbremsen. :-)
Aber man kann es ja auch positiv als Entschleunigungsmaßnahme sehen :-)

Lesenswert dazu

Ich finde gut, das die richtigerweise darauf hinweisen das whole-disk-encryption damit nicht automatisch überflüssig wird und es durchaus Szenarien gibt, wo man lieber das macht als Dataset-Encryption.

ich persönlich kann mir --raw besser merken

Ja. Ich finde es auch besser. Ich weiß auch gar nicht, wofür das w stehen soll.

 

[mr44er]

Ich finde gut, das die richtigerweise darauf hinweisen das whole-disk-encryption damit nicht automatisch überflüssig wird und es durchaus Szenarien gibt, wo man lieber das macht als Dataset-Encryption.

Genau, das lässt sich auch prima kombinieren. Man kann sein Tagebuch-dataset dann nach Bedarf auf- und abschließen, obwohl die ganze Karre auf geli liegt (...somit während Betrieb aufgeschlossen sein muss).

 

[Andy_m4]

Man kann sein Tagebuch-dataset dann nach Bedarf auf- und abschließen, obwohl die ganze Karre auf geli liegt

Hat eine solche Doppelverschlüsselung eigentlich spürbaren Einfluss auf die Performance?
Ich würde spontan sagen: nein (dank AES-NI kostet Verschlüsselung ja ohnehin nicht mehr so viel).

 

[pit234a]

Rsync benötigt eine Shell am Zielserver, du hast expliziert von einem sftp Zugang gesprochen, da wird sowas dann nicht funktionieren.

das war, weil mein Provider das so erklärt hatte und ich weiter nicht nachgesehen hatte.
Nunja, viel erklärt hatten die ja auch nicht, halt das übliche Vertriebs-Gewäsch, das man ja sowieso nicht liest. Deshalb war mir das auch fast in Vergessenheit geraten. Nun dachte ich, wenn sich das bewährt, könnte das vielleicht quasi so meine zukünftige "Backup-Cloud" werden und fing an zu probieren.

Ich habe immer noch nicht nachgesehen, aber im Laufe des Threads einfach mal einen ssh-Login versucht und das funktionierte tatsächlich.
Wie ich inzwischen dann getestet habe, auch das rsyncen.

Alles noch offen und ganz am Anfang der Überlegungen, aber dank eurer Hilfe bereits ein gutes Stück weiter.

 

[mr44er]

Hat eine solche Doppelverschlüsselung eigentlich spürbaren Einfluss auf die Performance?

Wenn ich die vm auf einem Opteron 4284 trotz vollen acht Hostkernen laufen lasse, ja ist spürbar, aber auch nur wenn man ein paar GB wegschreibt. Insgesamt aber vernachlässigbar bei ein paar kleinen Textseiten/passwort-db. Auf nem Ryzen 7 3800X ist es dann nicht mehr spürbar.

 

[pit234a]

Wäre hier nicht der Einsatz von Rclone angebracht?

das wollte ich nur zurück melden: nach einigen Versuchen mache ich das nun mit rclone
Es funktioniert beinahe problemlos von den unterschiedlichen Systemen aus, von denen ich es nutze.
Probleme habe ich hauptsächlich wegen meiner Fehler, aber mittels des rclone-browsers kann man die fertig eingerichteten "remotes" recht intuitiv nutzen.
Die GNU/Linux Versionen auf meinen diversen Systemen sind älter als in FreeBSD und können nicht base64 filename_encoding, was ich zunächst mit nur FreeBSD genutzt hatte.
Ansonsten genügt ein erstaunlich einfaches Kopieren der rclone.conf zu einem neuen System, und schon kann man dieses nutzen.

Allerdings gibt es sehr viele Schalter, die recht unübersichtlich sind und die ich nicht alle probieren möchte. So bin ich mit einem einfachen Erfolg schon ausreichend zufrieden.