sftp + root

DemonLord

DemonLord

Weeeeee!
Moinsen.

OpenSSH. Gutes Teil.
FTP. Schlechtes Teil.

Jetzt kommt sftp in's Spiel. Seit Jahren (8-10) nutze ich leider FTP und habe mit den Nachteilen der unmöglichen administierung (firewall) gelebt.

Subsystem sftp internal-sftp, ChrootDirectory %h in der Config sind ja ganz toll, aber so weit wie ich googlen konnte sah ich, dass das rooted top level dir root:$usergroup 750 sein muss.

Unter FTP konnte ich wunderbar nach ~ jailen, und die Jungs konnten da auch reinschreiben. Wie bekomme ich ähnliche / identische Funktionalität mit openssh/sftp hin?

LG,
Chris
(Wochenende!!!11elf)
 
Hoi
wenn Du mit FTP Möglichkeiten sonst glücklich warst, warum nimmst Du nicht einfach FTP mit SSL wenn damit sonst alles andere möglich war und ging ?

Gruß Bummibär
 
Flex6 schrieb:
hier ist der Hersteller:D
http://openbsd.maroufi.net/sshchroot.shtml

Generell hab ich dein Problem nicht richtig verstanden.
Gruß
Zum Vergrößern anklicken....

Problem: Alice und Bob hassen sich. Ein chroot nach "nur" /usr/home würde es ermöglichen, dass sowohl Alice wie auch Bob alle Userdirs sehen könnten (jedoch nicht öffnen). Ein chroot, das direkt nach dem login nach /usr/home/$user als / abbildet, wäre effektiver, würde Alice nicht bob sehen lassen.

wenn Du mit FTP Möglichkeiten sonst glücklich warst, warum nimmst Du nicht einfach FTP mit SSL wenn damit sonst alles andere möglich war und ging ?
Zum Vergrößern anklicken....
Weil FTP die Hölle zu administrieren ist (Firewall). Ausserdem ist openssh schon im userland erhältlich und braucht keine ports. Ausserdem hab ich dann ein "Prozess" weniger ;)
 
Hoi,

ich meine mich zu entsinnen, dass es ginge - so ähnlich hier (aus dem Bärenkopf):

Subsystem sftp internal-sftp

Match user u1,u2,u3 oder mit Match Group GRPNAME
ChrootDirectory /usr/home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
...

Gruß Bummibär
 
durch die richtigen Rechte dürfte ein Blick zum Nachbar nicht möglich sein viel weniger ein Wechsel zum Nachbar. Entscheident zum administratieven ist auch deine Userzahl und sind die User/Benutzer bekannt, eventuell Bekannte oder Fremdaccounts.
FTP kann auch in den ports einschränken und in die Schranken weisen wie Bummibär schon schrieb sollte es keine Probs geben, FTPD ist auch in der Base wie OpenSSH eben ohne Verschlüsselung des Bn und PW. In den ports gibts ja genug ftp-Zeugs.
Mußt du schon alles selbst abschätzen.
750 sollte der Blick zum Nachbar ausfallen, Standart ist 755
Gruß
 
Bummibaer schrieb:
Hoi,

ich meine mich zu entsinnen, dass es ginge - so ähnlich hier (aus dem Bärenkopf):

Subsystem sftp internal-sftp

Match user u1,u2,u3 oder mit Match Group GRPNAME
ChrootDirectory /usr/home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Zum Vergrößern anklicken....
Prinzipiel hast du recht, allerdings muss, wie erwähnt, /usr/home/%u root:$usergroup gehören. Das ist nicht der Fall, denn das gehört $user:$usergroup. Ich kann ja nicht einfach das Schreiben in deren homedirs verbieten (durch root:*).

Dein oben genanntes Beispiel führt demnach zu (auth.log)

Code: 
Oct 26 17:17:49 xxx sshd[20525]: Accepted password for xxx from 91.2.144.257 port 6553 ssh2
Oct 26 17:17:49 xxx sshd[20528]: fatal: bad ownership or modes for chroot directory "/usr/home/xxx"

Flex6 schrieb:
durch die richtigen Rechte dürfte ein Blick zum Nachbar nicht möglich sein viel weniger ein Wechsel zum Nachbar.
Zum Vergrößern anklicken....
Da hast du recht, aber: Wenn Du Dir das Problem genau durchliest, ist die Visibility das Problem, also Alice soll gar nicht wissen, dass es Bob gibt. Schon gar nicht das Verzeichnis (gar nicht erst zu sprechen von "cd bob"...)

Problem leider noch offen.
-Christian.
 
Hoi,

des geht bärig - also machen wir mal en Kurzabriss nun hier da:

PANDORA172# cat /etc/master.passwd | grep home/u
u1:$1$.YKcJ1LW$4AEHSEA.9HYLoavhZi25c0:1001:1001::0:0:u1 test:/home/u1:/bin/sh
u2:$1$WaLuFQiZ$ICSKSQwIuvqs8ccAqqKO1.:1002:1002::0:0:u2:/home/u2:/bin/sh

PANDORA172# mkdir -p /chroot/u1/home/u1
PANDORA172# mkdir -p /chroot/u2/home/u2

PANDORA172# chown -R u1 /chroot/u1/home/u1
PANDORA172# chown -R u2 /chroot/u2/home/u2

/etc/ssh/sshd_config:
---------------------
...
Match user u1,u2,u3
ChrootDirectory /chroot/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
...

Status: Verbinde mit 192.168.0.172...
Antwort: fzSftp started
Befehl: open "u1@192.168.0.172" 22
Befehl: Pass: ****
Status: Connected to 192.168.0.172
Status: Empfange Verzeichnisinhalt...
Befehl: pwd
Antwort: Current directory is: "/home/u1"
Befehl: ls
Status: Listing directory /home/u1
Status: Anzeigen des Verzeichnisinhalts abgeschlossen
Status: Empfange Verzeichnisinhalt...
Befehl: cd ".."
Antwort: New directory is: "/home"
Befehl: ls
Status: Listing directory /home
Status: Berechne Zeitzonenabweichung des Servers...
Befehl: mtime "u1"
Antwort: 1319649257
Status: Zeitzonenabweichungen: Server: 7200 Sekunden. Lokal: 7200 Sekunden. Differenz: 0 Sekunden.
Status: Anzeigen des Verzeichnisinhalts abgeschlossen
Status: Empfange Verzeichnisinhalt...
Befehl: cd ".."
Antwort: New directory is: "/"
Befehl: ls
Status: Listing directory /
Status: Anzeigen des Verzeichnisinhalts abgeschlossen
Status: Empfange Verzeichnisinhalt...
Befehl: cd ".."
Antwort: New directory is: "/"
Status: Anzeigen des Verzeichnisinhalts abgeschlossen


Status: Verbinde mit 192.168.0.172...
Antwort: fzSftp started
Befehl: open "u2@192.168.0.172" 22
Befehl: Pass: ****
Status: Connected to 192.168.0.172
Status: Empfange Verzeichnisinhalt...
Befehl: pwd
Antwort: Current directory is: "/home/u2"
Befehl: ls
Status: Listing directory /home/u2
Status: Anzeigen des Verzeichnisinhalts abgeschlossen
Status: Empfange Verzeichnisinhalt...
Befehl: cd ".."
Antwort: New directory is: "/home"
Befehl: ls
Status: Listing directory /home
Status: Berechne Zeitzonenabweichung des Servers...
Befehl: mtime "u2"
Antwort: 1319649261
Status: Zeitzonenabweichungen: Server: 7200 Sekunden. Lokal: 7200 Sekunden. Differenz: 0 Sekunden.
Status: Anzeigen des Verzeichnisinhalts abgeschlossen
Status: Empfange Verzeichnisinhalt...
Befehl: cd ".."
Antwort: New directory is: "/"
Befehl: ls
Status: Listing directory /
Status: Anzeigen des Verzeichnisinhalts abgeschlossen
Status: Empfange Verzeichnisinhalt...
Befehl: cd ".."
Antwort: New directory is: "/"
Status: Anzeigen des Verzeichnisinhalts abgeschlossen

In beide Fälle sieht man nur / und /home und /home/%u abär koine andere User.

Gruß Bummibär
 
Hey,

Danke für den Post. So weit war ich allerdings auch schon, nur statt /chroot /usr/local/sftp.
So das Alice /usr/local/sftp/alice hatte. Ihr real-home natürlich /usr/home/alice. Ein ln -s $realhome /usr/local/sftp/alice/alice geht aber nicht (rooted).

Somit Ziel auch nicht erreicht.
 
Hi,
wozu brauchst Du das realhome der user db überhaupt - du musst das ja nirgends sonst verwenden wenn du nicht möchtest ?

Ftp bist Du mit der Lösung los, das Firewallproblem von Dir vermutlich ebenfalls. Die Separierung mit chroot über sftp klappt damit auch. Die User sehen sich gegenseitig auch nicht. Was möchtest Du noch mehr haben ?

Gruß Bummibär
 
Zuletzt bearbeitet:
Naja,

Die Daten der User liegen unter /usr/home/alice. Alice will ja auch ihre Daten verwalten, und nicht irgendein Verzeichnis. Wenn Alice mit der oben genannten Methode auf den Server per sftp geht, naja, sieht sie den Inhalt von /usr/local/sftp/alice/... - aber ihre Daten liegen ja unter /usr/home/alice.

Wo ist da der Gain?

-Chris.
 
Hi,
na der Sinn in meinem Beispiel ist eben die Daten nicht im realhome abzulegen sondern im chroot home und alle Dienste wo diese Daten nutzen dürfen daruf los zu lassen. Die User können in ihrem jeweiligen chroot home ja mit den Daten anstellen was se wollen.

Gruß Bummibär
 
Dafür müssten quasi eine bestehende funktionierende LIVE Konfig geändert werden. Und der Standard ist nunmal /usr/home/%u. Es ist alleine vom administrativen Aufwand nicht zu rechtfertigen, alles von dort nach chroot zu legen.
 
Hi,
sowas regelt mer in der Praxis normalerweise mit Scripts wo das automatisch machen. Bei größeren Installationen wird normal generell nur mit virtuellen User Accounts gearbeitet. In Sofern stellt sowas normalerweise auch keinen zusätzlichen Aufwand dar.

Gruß Bummibär
 
Es gibt noch einen anderen Ansatz. Je nach Umgebung (und wie 'heilig' $HOME ist) geht das, was DemonLord will über eine Änderung in sshd_config , oder wenn einer will, in authorized_keys.
Bummibaer's Variante, sozusagen die 'offizielle' , geht genauso, aber das hier halt auch.
Der Knackpunkt ist der User (%u) in sshd_config.
Ersetze 'Match Group' durch 'Match User' und %u durch %h , und sftp chrooted nach $HOME. Da liegt dann alles, also auch .ssh/ lesbar ... das soll so möglicherweise aber nicht sein.
Folgendes gibt strikten ro access nach $HOME/depot als chroot. Subsystem und so vorausgesetzt.
Code: 
Match User dull
        ChrootDirectory %h/depot
        ForceCommand internal-sftp

Da der chroot (hier $HOME/depot) root gehört, sorgt sftp dafür, das Schreibzugriff unmöglich ist. Das ist richtig so ( Schreibzugriff auf root ??). ALso ist $HOME/depot 'nur' lesbar.

Wenn der User auch Schreibzugriff haben soll, erzeuge einen Folder im chroot, der dem User gehört, e.g $HOME/depot/upload und dahin kann er dann nach Herzenslust schreiben.
Code: 
Wem gehört was:
###
rro#ls -la  /usr/home
total 6
drwxr-xr-x   4 root  wheel   4 May 20 09:37 .
drwxr-xr-x  14 root  wheel  14 Feb  5  2011 ..
drwxr-xr-x   4 root  dull    4 Oct 14 15:23 dull
###
rro# ls -la  /usr/home/dull
total 6
drwxr-xr-x  4 root  dull   4 Oct 14 15:23 .
drwxr-xr-x  4 root  wheel  4 May 20 09:37 ..
drwx------  2 dull  dull   3 Oct 14 14:18 .ssh
drwxr-xr--  3 root  dull   4 Oct 28 07:43 depot
###
rro# ls -la /usr/home/dull/depot/
total 6
drwxr-xr--  3 root  dull   4 Oct 28 07:43 .
drwxr-xr-x  4 root  dull   4 Oct 14 15:23 ..
drwxr-xr-x  2 dull  dull   3 Oct 14 07:44 upload

hth
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben