staging.inyokaproject.org

Hallo,

ich habe mit sftp einen Dateiserver aufgesetzt. Das Ganze klappt auch gut, aber ich hätte eine Frage zum ChRoot - Verzeichnis. Da das Ch-Root-Verzeichnis dem Nutzer "root" gehört und man Eigentümer und Rechte leider nicht ändern kann, kann der sftpbenutzer natürlich in dieses Verzeichnis nicht reinschreiben kann. Allerdings ist das ein bisschen blöd, wenn man zum schnellen Dateiaustausch immer erst einen Unterordner auswählen muss.

Deshalb wolte ich fragen, ob man irgendwie was konfigurieren kann, damit man direkt ins ChRoot - Verzeichnis schreiben kann?

Für hilfreiche Erklärungen danke ich sehr.

Hm, ändere doch das Homeverzeichnis von dem sftpbenutzer.

Falls du dir noch unsicher sein solltest: Die richtige Schreibweise lautet chroot und leitet sich von dem gleichnamigen Programm ab. 😉

Zu deiner Frage:

Nach welchem Muster bzw. welcher Anleitung hast du deine Konfiguration vorgenommen?

Was spricht dagegen, die Unterverzeichnisse des Einstiegsverzeichnis von den Berechtigungen her so zu gestalten, dass sie vom sftp-Benutzer beschrieben werden dürfen?

Cranvil schrieb:

Falls du dir noch unsicher sein solltest: Die richtige Schreibweise lautet chroot und leitet sich von dem gleichnamigen Programm ab. 😉

Zu deiner Frage:

Nach welchem Muster bzw. welcher Anleitung hast du deine Konfiguration vorgenommen?

Was spricht dagegen, die Unterverzeichnisse des Einstiegsverzeichnis von den Berechtigungen her so zu gestalten, dass sie vom sftp-Benutzer beschrieben werden dürfen?

Also, ich habe die User angelegt und zur Gruppe sftpgruppe hinzugefügt. Dann habe ich die /bin/false - Shell zugeordnet, damit sie sich nicht im System einloggen können.

Was ich jetzt möchte:

Im Verzeichnis /srv/sftp, habe ich ein Verzeichnis "Kollegen" erstellt, das dem Nutzer root und der Gruppe sftpgruppe gehört. In diesem Verzeichnis sind die Verzeichnisse der Nutzer (in meinem Beispiel tim und tom). Ein Chefkollege (username: meister) hat nun als chroot-Verzeichnis /srv/server/Kollegen - er soll ja auf jeden Kollegen (hier: tim und tom) zugreifen können. tim und tom haben ihr chroot Verzeichnis in /srv/sftp/Kollegen/tim bzw. /srv/sftp/Kollegen/tom, damit die beiden in ihrem Verzeichnis drin bleiben und nur auf ihre eigenen Sachen Zugriff haben. Das Ganze habe ich übrigens durch Gruppenberechtigungen gesteuert (meister, tim und tom der Gruppe sftpgruppe hinzugefügt, Eigentümergruppe der Verzeochnisse ist sftpgruppe - Besitzer muss ja root bleiben.

Funktioniert auch alles. Aber ich möchte, dass tim und tom nun direkt in ihr Verzeichnis schreiben können und nicht noch erst in ein extra angelegtes "shared"-Verzeichnis, wo dann die Rechte angepasst werden können. Das würde mich interessieren, ob sich das realisieren lässt oder ob das die Sicherheitsvorkehrungen von ssh ausschließen.

Wolfmann schrieb:

Cranvil schrieb:

[…]

Bitte vermeide vollständige Zitate von Beiträgen oder strukturiere deine Antwort so um die Zitate herum, dass klar wird, auf welchen Teil des Beitrags du reagierst.

Wenn ich deine Beschreibung richtig verstehe, hast du derzeit folgende Struktur:

/srv              root:root
|
+--sftp           root:root
   |
   +--Kollegen    root:sftpgruppe    750    Einstiegspunkt meister
      |
      +--Tim      root:sftpgruppe    750    Einstiegspunkt tim
      |
      +--Tom      root:sftpgruppe    750    Einstiegspunkt tom

Nehmen wir weiterhin an, dass wir unbedingt vermeiden wollen, dass eines der Benutzerkonten auf dem Einstiegspunkt Schreibrechte erhält, um zu vermeiden, dass er beginnt sich selbst Rechte zu vergeben. Damit ergibt sich aus meiner Sicht eine Verlagerung der Einstiegspunkte von Tim und Tom um eine Ebene nach oben:

/srv              root:root
|
+--sftp           root:root
   |
   +--Kollegen    root:sftpgruppe    750    Einstiegspunkt meister, tim, tom
      |
      +--Tim       tim:sftpgruppe    750
      |
      +--Tom       tom:sftpgruppe    750

Diese Lösung hätte den Vorteil, dass jeder direkt in seinem eigenen Verzeichnis speichern kann, je nach sichtweise jedoch den Nachteil, dass jeder dann auch in das Verzeichnis des jeweils anderen schauen kann. Sollte das zu vermeiden sein, bietet es sich an, die Gruppe der Benutzerverzeichnisse anzupassen und meister zum Mitglied der Gruppen tim und tom zu machen, damit er weiterhin alles sehen kann:

/srv              root:root
|
+--sftp           root:root
   |
   +--Kollegen    root:sftpgruppe    750    Einstiegspunkt meister, tim, tom
      |
      +--Tim       tim:tim           750    tim darf hier alles, Mitglieder der Gruppe tim dürfen gucken
      |
      +--Tom       tom:tom           750    tom darf hier alles, Mitglieder der Gruppe tom dürfen gucken

Ich beende meinen Beitrag an dieser Stelle mal, damit sich das hier nicht zu sehr verselbstständigt. 😉

Ok, deine letzte Lösung macht Sinn. So in etwa habe ich es mir auch gedacht.

Bloß: meister kann ja jetzt nun nicht mehr in tim und tom schreiben, da die Verezichnisse tim und tom ja jetzt den Gruppen tim und tom gehören und nicht mehr der Gruppe sftpgruppe. Bei 2 Kollegen geht das - da würde ich den meister halt zu den entsprechenden Gruppen hinzufügen. Aber bei einem Betrieb mit mehreren hundert Kollegen wäre das doch recht unübersichtlich...

By the way: Zwar ein bisschen off-topic, aber ich wollte jetzt nicht noch einen thread aufmachen: Welche anderen Sicherheitsvorkehrungen würdest du noch so treffen? Ich habe tcpforwarding und x11forwarding ausgestellt und nur sftp-Kommmandos zugelassen und den Port gewechselt. Habe ich was vergessen?

Was mich vor allem noch stört, dass die "normalen" Nutzer des Systems sich über ssh einloggen können - falls das Ganze mal online ist und jemand das ja mal knackt (was bei ssh zwar unwahrscheinlich ist, aber man weiß ja nie) könnte der dann leicht sämtliche Systemdaten löschen/umändern usw. Kann man da noch was absichern?

Deine Anforderung für Meister lautete, dass er zugreifen können muss - das beinhaltet nicht zwingend schreiben. 😉

Wenn du komplexere Szenarien umsetzen willst, kannst du es beispielsweise mit ACL versuchen.

Abgesehen davon: Was hindert dich, es mit einem richtigen Dateiserverdienst à la Samba zu versuchen? Dass du es mit sftp-chroots versuchst und von sehr vielen Benutzern sprichst, macht den Eindruck, als solltest du dich eher damit beschäftigen, ein Werkzeug zu verwenden, das als konzeptionellen Kern die Bereitstellung von Dateien für viele Benutzer hat.

sftp ist nur ein netter Nebeneffekt eines Werkzeugs, mit dem ganz andere Dinge realisiert werden sollen. Das würde auch helfen, die Fragen zur Absicherung zu beantworten: Wenn die Anwender ihre Dateien nicht über einen in ssh implementierten Mechanismus beziehen, müssen die ganzen Features wie Forwarding von Hü und Hott und so nicht explizit deaktiviert werden. Und Shellzugriff hätten dann auch nur diejenigen, die wirklich einen Shellzugriff benötigen.

Da "normale" Anwender in der Regel auch jene sind, die man kaum für Public Key Authentifizierung erwärmen kann, wird dein ssh-Server vermutlich noch Passwortauthentifizierung aktiviert haben. Und das bedeutet auch bei als halbwegs sicher geltenden Passwörtern, dass du zusätzliche Mechanismen wie fail2ban benötigst, um Angreifern das Durchraten von Passwörtern durch den Zeitaufwand zu teuer zu machen.

Ok, dann habe ich michwohl etwas blöd ausgedrückt ☺

Ich weiß schon, dass es Sachen wie samba gibt, die sogar meistens von Vorteil sind - aber: Samba ist ja auf das Heimnetzwerk beschränkt und bekommt keinen Austausch über das Internet hin, wenn ich richtig gelesen habe. Es geht mir derzeit halt darum, verschiedene Sachen auszuprobieren, weil ich ein bisschen Linux lernen und verstehen möchte. das man vieles davon im Alltag dann anders machen könnte/würde, ist schon klar.

An ACL habe ich auch schon gedacht, aber das UID betrifft ja die Ausführungsrechte. In unserem Fall wären aber eher die Shreibrechte wichtig.

Ich danke dir jedenfalls für deinen Input und lese mich mal in die von dir verlinkten Quellen ein.

Wolfmann schrieb:

[…] aber: Samba ist ja auf das Heimnetzwerk beschränkt und bekommt keinen Austausch über das Internet hin, wenn ich richtig gelesen habe.

Damit Samba funktioniert, brauchst du in aller erster Linie eine funktionierende Netzwerkkommunikation zwischen Server und Client. Dabei ist es egal, ob die beiden Geräte innerhalb desselben Netzwerks (gleiche NetzwerkID in IP-Sprech) sind oder noch ~255 Netzwerke dazwischen liegen (das TTL-Feld eines Netzwerkpakets ist 8 Bit lang; erreicht die TTL 0, wird das Paket verworfen).

Es gibt Features, die auf Broadcasts angewiesen sind, damit sie funktionieren. Dazu gehören Dinge wie WINS, Computerbrowser, Arbeitsgruppen. Allerdings sind dies je nach Anwendungsfall mit die ersten Dinge, die auch abgeschaltet werden. 😉

Je nach Einschätzung ist Samba aus verschiedenen Gründen nicht gern über das Internet gesehen. Diese Gründe sammeln sich mit Masse um das Thema Sicherheit und basieren auf der Annahme, dass SMB/CIFS analog zu FTP ohne Verschlüsselung der Anmeldeinformationen oder Datenübertragungen arbeitet. Vergleichbar mit den anderen großen Protokollen (z.B. HTTP, SMTP, IMAP, POP) hat sich da im Laufe der Jahre einiges getan, wobei das nicht heißt, dass eine neue Installation automatisch sicher ist.

[…] das man vieles davon im Alltag dann anders machen könnte/würde, ist schon klar.

Fortgeschrittene Dateiserverdienste und ACL gibt es unter anderem, weil die Systemadministratoren irgendwann keinen Bock mehr darauf hatten, durch brennende Reifen zu springen. Wenn du etwas gut genug kennen gelernt hast, dass du an dem Punkt ankommst, dir die Frage zu stellen, ob das überhaupt mit vielen Benutzern skalieren kann, wenn es mit einer Handvoll schon nervig wird, kannst du davon ausgehen, dass die Antwort auf die Frage dir ein neues Produkt zum Lernen vorschlägt. 😉

An ACL habe ich auch schon gedacht, aber das UID betrifft ja die Ausführungsrechte. In unserem Fall wären aber eher die Shreibrechte wichtig.

Mir wird nicht klar, was du aussagen willst. Beziehst du dich mit UID auf die erste der vier Stellen in der Oktalschreibweise, die gerne weggelassen wird, wenn sie 0 (keine gesetzten SUID-, SGID-, Sticky-Bits) sind? Falls ja, dann bringst du vielleicht ACL und diese Sonderrechte durcheinander.

Hallo,

erstmal danke für deine interessanten Ausführungen - es ist schön, dass du Einsteigern hilfst.

Da habe ich mit Samba wohl was verwechselt - im Heimnetzwerk läuft es bei mir auch erfolgreich mit diversen Netzwerkfestplatten. Vielleicht werde ich mal testweise versuchen, das auch übers Heimnetz hinaus zum Laufen zu bringen.

Du hast auch Recht, was die ACLs betrifft - die habe ich tatsächlich mit den Sonderrechten verwechseln (in meinem Fall mit dem UID).

Nochmals danke für deine Hilfe. Ich beschäftige mich mal weiter mit den ACL und würde dieses Thema mal als gelöst markieren, da der eigentliche Sachverhalt ja erläutert wurde.

Wolfmann schrieb:

erstmal danke für deine interessanten Ausführungen - es ist schön, dass du Einsteigern hilfst.

Das beste Mittel gegen Einsteiger. 😉

Vielleicht werde ich mal testweise versuchen, das auch übers Heimnetz hinaus zum Laufen zu bringen.

Bevor du irgendwann mal von jemandem einen zwischen die Hörner bekommst: Nur, weil etwas technisch möglich ist, bedeutet das nicht, das man es machen sollte. Die in meiner Wahrnehmung zu bevorzugegende Herangehensweise ist die Anbindung externer Anwender über eine ordentliche VPN-Lösung.

Das sowieso, aber da habe ich noch keine Ahnung,wie man das aktiviert/einrichtet. Ich arbeite mich, wie gesagt, Stück für Stück in die Materie ein.