[Professor Hunt]

Aloha,

ich möchte auf meinem NAS remote etwas einbinden in einem bestimmten Ordner vom NAS.
Eine der ersten und einfachsten Anleitung findet man unter:
https://www.digitalocean.com/communi...stems-over-ssh

Für einen einmaligen Mount kann man angeben wohin es gemountet wird, aber bei einem permanenten Mount wird die fstab.etc verändert und da habe ich nichts gesehen, ob ich den Mountpunkt so setzen kann, dass es in den richtigen Ordner reinläuft bzw. die Dateien dargestellt werden und nicht als Unterordner eingehängt werden.

Das hier scheint auch eine gute Anleitung zu sein, aber sie steigt mir über meinen Kopf und scheint meine eigentliche Frage nicht zu beantworten:
https://www.linode.com/docs/networki...shfs-on-linux/

Könnt ihr da ein paar Tipps geben?

[Lookbehind]

Hi,

die /etc/fstab ist dafür da, dass du nicht jedes mal manuell "mount SOURCE TARGET" eingeben musst. Die kann aber eigentlich alles, was mount auch kann. Nur ist die Syntax manchmal ein wenig anders. ... ein wenig. Das hängt jetzt aber davon ab, mit welchen Parametern du das einhängen möchtest.
Ich verlinke einfach mal einen, meiner Meinung nach recht guten, Wiki-Artikel dazu: https://wiki.ubuntuusers.de/fstab/

Ein wichtiger Parameter, den ich in der fstab auf jeden Fall benutzen würde, wenn es um sshfs geht, lautet "_netdev". Wenn du das weg lässt, kann es dir sonst passieren, dass dein NAS mit dem vollständigen boot wartet, bis es dieses Dateisystem einhängen kann. Was bei Netzwerk-Dateisystemen mitunter sehr lange sein kann. Evtl ist auch "noauto" noch sinnvoll. Vielleicht in Kombination mit autofs?

So, nun kommen wir zur Gretchenfrage: Du schreibst was von einem NAS, auf welchem du das umsetzen möchtest. Was genau ist das für ein NAS? Denn was du da genau machen musst, ist gegebenenfalls unterschiedlich. Manche NAS-Hersteller erlauben dir einfach die fstab an zu passen und alles ist gut. Andere überschreiben dir die fstab beim nächsten Boot wieder und deine Änderungen sind weg, andere haben da eine spezielle GUI für. Wie es generell unter Linux geht, weiß ich, und steht auch in den von dir verlinkten Anleitungen. Aber die NAS-Hersteller versuchen oft den Benutzer vor sich selbst zu schützen und darum muss man da manchmal Dinge anders machen.

[Professor Hunt]

Hi,

die /etc/fstab ist dafür da, dass du nicht jedes mal manuell "mount SOURCE TARGET" eingeben musst. Die kann aber eigentlich alles, was mount auch kann. Nur ist die Syntax manchmal ein wenig anders. ... ein wenig. Das hängt jetzt aber davon ab, mit welchen Parametern du das einhängen möchtest.
Ich verlinke einfach mal einen, meiner Meinung nach recht guten, Wiki-Artikel dazu: https://wiki.ubuntuusers.de/fstab/

Ein wichtiger Parameter, den ich in der fstab auf jeden Fall benutzen würde, wenn es um sshfs geht, lautet "_netdev". Wenn du das weg lässt, kann es dir sonst passieren, dass dein NAS mit dem vollständigen boot wartet, bis es dieses Dateisystem einhängen kann. Was bei Netzwerk-Dateisystemen mitunter sehr lange sein kann. Evtl ist auch "noauto" noch sinnvoll. Vielleicht in Kombination mit autofs?

So, nun kommen wir zur Gretchenfrage: Du schreibst was von einem NAS, auf welchem du das umsetzen möchtest. Was genau ist das für ein NAS? Denn was du da genau machen musst, ist gegebenenfalls unterschiedlich. Manche NAS-Hersteller erlauben dir einfach die fstab an zu passen und alles ist gut. Andere überschreiben dir die fstab beim nächsten Boot wieder und deine Änderungen sind weg, andere haben da eine spezielle GUI für. Wie es generell unter Linux geht, weiß ich, und steht auch in den von dir verlinkten Anleitungen. Aber die NAS-Hersteller versuchen oft den Benutzer vor sich selbst zu schützen und darum muss man da manchmal Dinge anders machen.

Hi Lookbehind,

vielen Dank für die Antwort.

Achso, dann hab ich fstab wohl immer falsch verstanden. Ich kenne das schon lange, aber ich dachte das macht die Verbindung von physischen Platten im System zum Mounten (da musste man ja noch irgendwelche IDs eintragen und so). Dann könnte ich dort es also einrichten, dass mein NAS eine sichere Verbindung dauerhaft erzeugt und es automatisch mountet in meinem NAS-Ordner? (der Ordner heißt direkt so).

Bezüglich der Parameter muss ich mich auch noch schlau machen. Ich bin mir noch unsicher, ob der Server ein Zertifikat liefert bzw. liefern sollte oder ob Login allein sicher ist. Zusätzlich eben noch die von dir erwähnten Parameter etc. Also den groben Aufbau des Gesamtbefehls halt. Teile der Daten sind auch Mediendateien und die sollten halt on the fly verfügbar sein und kA, ob ich auch ein gewisses Caching per Parameter einfügen kann.

Mein NAS an sich ist ein ARM Debian (Armbian mit OpenMediaVault) und ich habe eine einfache Freigabe gemacht für mein Netzwerk zum Datenaustausch bzw. für DLNA/Samba und den Bluetooth Player. Dorthin soll auch der andere Krams münden. Ich habe also Zugriff auf die fstab ohne Probleme.

[Lookbehind]

Caching halte ich für schwierig. Insbesondere, wenn jemand ARM erwähnt, denke ich spontan an RasPis, und deren Leistung.

Generell will man natürlich gerne Public-Key Authenfizierung haben. Ist insgesamt sicherer UND bequemer. Eine Win/Win-Lösung. Außerdem ist es einfacher zu konfigurieren. Du musst nur angeben wo dein Key-File liegt und damit hat sich die Sache.

Und zu guter Letzt noch die Frage: Was ist eigentlich das andere Ende? Und wo steht das? Evtl gibts ja auch ein sinnvolleres Protokoll als SSHFS. Letzteres hat schon recht viel Overhead, dafür aber den Vorteil dass man damit sichere Verbindungen mitten durchs Kriegsgebiet (aka Internet) legen kann.
Wenn das andere Ende aber z.B. bei dir im LAN ist, bietet sich vielleicht NFS an. Das ist bei weitem nicht so sicher, aber deutlich flinker und einfacher ein zu richten.

[Professor Hunt]

Caching halte ich für schwierig. Insbesondere, wenn jemand ARM erwähnt, denke ich spontan an RasPis, und deren Leistung.

Generell will man natürlich gerne Public-Key Authenfizierung haben. Ist insgesamt sicherer UND bequemer. Eine Win/Win-Lösung. Außerdem ist es einfacher zu konfigurieren. Du musst nur angeben wo dein Key-File liegt und damit hat sich die Sache.

Und zu guter Letzt noch die Frage: Was ist eigentlich das andere Ende? Und wo steht das? Evtl gibts ja auch ein sinnvolleres Protokoll als SSHFS. Letzteres hat schon recht viel Overhead, dafür aber den Vorteil dass man damit sichere Verbindungen mitten durchs Kriegsgebiet (aka Internet) legen kann.
Wenn das andere Ende aber z.B. bei dir im LAN ist, bietet sich vielleicht NFS an. Das ist bei weitem nicht so sicher, aber deutlich flinker und einfacher ein zu richten.

Bei Raspis kriege ich immer so einen Beißanfall

In meinem Odroid HC2 ist ein Samsung Exynos 5422 drin, d.h. Big-Litte-Architektur mit 2x4 Kernen und 2GB RAM. Das sollte also schon potent genug sein.

Okay, Keyfile also.

Hm, das Ganze befindet sich derzeit noch im Aufbau (also der Server mein ich). Eventuell nutzen wir auch andere Protokolle, aber was wäre denn performanter als SSHFS? WebDAV? Es ist nicht lokal, d.h. ich brauch schon eine sichere Verbindung, aber ich weiß natürlich nicht wie gut welches Protokoll dafür geeignet ist etc...

[Lookbehind]

Bei Raspis kriege ich immer so einen Beißanfall

In meinem Odroid HC2 ist ein Samsung Exynos 5422 drin, d.h. Big-Litte-Architektur mit 2x4 Kernen und 2GB RAM. Das sollte also schon potent genug sein.

Sach ich ja. Performance.
Mit so wenig RAM würd ich Caching erstmal hinten anstellen. Da lässt sich vielleicht was machen, aber da muss man sich die Umstände genauer anschauen. Auf jeden Fall hat das nichts mit den Mount-Optionen zu tun. Bestenfalls mit dem Pfad, aber der ist schnell geändert.

...
Hm, das Ganze befindet sich derzeit noch im Aufbau (also der Server mein ich). Eventuell nutzen wir auch andere Protokolle, aber was wäre denn performanter als SSHFS? WebDAV? Es ist nicht lokal, d.h. ich brauch schon eine sichere Verbindung, aber ich weiß natürlich nicht wie gut welches Protokoll dafür geeignet ist etc...

WebDAV? Performance? Hahahaha ... Nein!
Wenn du durch das böse Internet musst, ist was SSH-Basiertes schon eine der besseren Entscheidungen. Was genau habt ihr denn vor? SSHFS hängt dir das Remote-Filesystem ja direkt lokal ein, aber alle Anfragen gehen dennoch direkt übers Netz. Aber je nach Anwendungsfall, gibts da evtl auch noch andere Methoden, bei denen man das Remote-Filesystem evtl nichtmal einhängen muss. SSH ist ja durchaus ein Schweizer-Taschenmesser. Da kann man ja allen Möglichen Kram durch tuneln. rsync zum Beispiel.

[Professor Hunt]

Sach ich ja. Performance.
Mit so wenig RAM würd ich Caching erstmal hinten anstellen. Da lässt sich vielleicht was machen, aber da muss man sich die Umstände genauer anschauen. Auf jeden Fall hat das nichts mit den Mount-Optionen zu tun. Bestenfalls mit dem Pfad, aber der ist schnell geändert.



WebDAV? Performance? Hahahaha ... Nein!
Wenn du durch das böse Internet musst, ist was SSH-Basiertes schon eine der besseren Entscheidungen. Was genau habt ihr denn vor? SSHFS hängt dir das Remote-Filesystem ja direkt lokal ein, aber alle Anfragen gehen dennoch direkt übers Netz. Aber je nach Anwendungsfall, gibts da evtl auch noch andere Methoden, bei denen man das Remote-Filesystem evtl nichtmal einhängen muss. SSH ist ja durchaus ein Schweizer-Taschenmesser. Da kann man ja allen Möglichen Kram durch tuneln. rsync zum Beispiel.

Also primär gehts ums Medien-Streaming. Für weiteres wollte ich mich mal mit rsync beschäftigen, ja. Aber eigentlich reicht da auch ein FTP oder irgendetwas mit nem automatischen Sync.
Die Mediendateien sind aber zentral aufm Server und die brauch ich nun nicht wirklich zu syncen. ich würde sie gerne streamen und brauche daher ein Protokoll, was das unterstützt und eben ein gewisses Caching für den Buffer. Rsync scheint jetzt nicht auf Streaming ausgelegt zu sein, oder?

[Lookbehind]

Also primär gehts ums Medien-Streaming.

Hm. Da wäre was UDP basiertes vielleicht besser. Auch wenn mir da offengestanden auf die Schnelle nix konkretes einfällt.
SSHFS wird das aber auch hin bekommen, wenn die Leitung schnell genug ist versteht sich.

Für weiteres wollte ich mich mal mit rsync beschäftigen, ja. Aber eigentlich reicht da auch ein FTP oder irgendetwas mit nem automatischen Sync.

Interessant. Also in sofern als das FTP und Sync jetzt nicht so richtig zusammen passen. Klar kann man rsync auch mit FTP verwenden und einen FTP-Server als Sternpunkt für Synchronisationen, etc. Möglich ist vieles. Aber generell hätte ich die beiden nicht zusammen erwartet.

Die Mediendateien sind aber zentral aufm Server und die brauch ich nun nicht wirklich zu syncen. ich würde sie gerne streamen und brauche daher ein Protokoll, was das unterstützt und eben ein gewisses Caching für den Buffer.

Spontan fällt mir da nichts konkretes ein. Aber es gibt zumindest webbasierte Streaming-Protokolle. Youtube machts vor. Vielleicht da mal einlesen?

Rsync scheint jetzt nicht auf Streaming ausgelegt zu sein, oder?

Well ... streng genommen schon. Aber nicht so, wie das Wort "Streaming" heute so im allgemeinen verstanden wird.

[Lolomoloko]

Okay, Keyfile also.

Wenn du sshfs statisch einbinden möchtest und public key authentification verwenden willst,
läuft das auf einen key ohne passphrase hinaus.
Es empfiehlt sich dann den key einzuschränken, damit niemand herum marodieren kann.
Z.b. den login mit dem key nur von bekannten adressen aus zuzulassen (sofern anwendbar).

Zudem sollte man generell password authentification global im sshd ausschalten.

Further reading: https://blog.tinned-software.net/res...ar-ip-address/

Erstelle auch wirklich einen key nur für diesen zweck und benutze ihn sonst für nichts.
Und achte beim erstellen des keys dass die standard parameter die ssh-keygen benutzt (momentan rsa 3072) zwar ok sind,
aber man für die zukunft durchaus andere benutzen sollte. (man will seine ssh keys ja auch nicht alle 2 tage austauschen)

Wenn z.B. kein altes legacy system mehr in der pipeline hängt, kann man z.B. einen ed25519 key benutzen.
ed25519 ist ein EdDSA verfahren (elliptische kurven, wissensschon).
Ansonsten sind RSA keys auch akzeptabel, wobei man auf keinen fall einen key < 2048 bit erstellen sollte und
man besser direkt einen 4096 bit key nimmt.
RSA authentification ist dabei langsamer als ed.
Von DSA sollte man komplett die finger lassen, das ist unsicher.
Und ECDSA riecht komisch. (NIST → NSA)

Further reading:
https://blog.g3rt.nl/upgrade-your-ssh-keys.html
https://www.heise.de/security/meldun...s-2103493.html




Sofern das thema hier noch aktuell ist.