Seit OpenSSH 4.8p1 existiert eine neue Option für den SSH-Server, die es ermöglicht, ein sog. chrooted-jail („changed-root“-Umgebung) aufzubauen. Eine solche Umgebung bietet den Vorteil, dass Anwender, die sich mittels SFTP mit dem Server verbinden, direkt in ein bestimmtes Unterverzeichnis „eingesperrt“ werden, so dass sie von da aus nicht in höhere Ordner-Ebenen wechseln können. Damit verhindert man den Zugriff auf unerwünschte Bereiche des Dateisystems.
Anwenden kann man diese Konfiguration z.B. bei Shared-Webhosting, wo unabhängige User ihren eigenen Webspace verwalten. Anstelle des unsicheren FTP kann hier dann eine sichere SFTP-Kommunikation stattfinden. Auch CVS-Repositories können auf diese Weise abgesichert werden.
Ich gebe in diesem Artikel nachfolgend eine Kurzanleitung, die die grundsätzliche chroot-Konfiguration beschreibt. Ich verwende derzeit openSUSE 11.3, grundsätzlich ist die Distribution aber natürlich nicht entscheidend.
Als Beispiel-Basisordner für die chroot-Umgebung verwenden wir „/srv/sftp„. Jeder User soll darin seinen eigenen Unterordner erhalten.
- Erstellen einer neuen Benutzergruppe „sftponly“:
groupadd sftponly
- Erstellen zweier Benutzerkonten „user1“ und „user2“:
useradd -s /bin/false user1 useradd -s /bin/false user2
- Setzen der Passwörter für die neuen User:
passwd user1 passwd user2
- Hinzufügen der User zur neuen Gruppe:
usermod user1 -A sftponly usermod user2 -A sftponly
- Erstellen des Ordners „/srv/sftp“ und der exemplarischen Unterordner „/srv/sftp/user1“ und „/srv/sftp/user2“:
mkdir /srv/sftp chown root:sftponly/srv/sftp chmod 750 /srv/sftp mkdir /srv/sftp/user1 chown user1: /srv/sftp/user1 chmod 700 /srv/sftp/user1 mkdir /srv/sftp/user2 chown user2: /srv/sftp/user2 chmod 700 /srv/sftp/user2
- Anpassen der Datei „/etc/ssh/sshd_config“:
#Subsystem sftp /usr/lib64/ssh/sftp-server Subsystem sftp internal-sftp Match Group sftponly ForceCommand internal-sftp ChrootDirectory /srv/sftp X11Forwarding no AllowTcpForwarding no - Neustart des SSH-Servers:
/etc/init.d/ssh restart
Auf in die chroot-Umgebung
Verbinden sich die eingerichteten User nun via SFTP (z.B. „sftp“-Kommando bei Linux oder WinSCP bei Windows) mit dem Server, sollten sie automatisch im Ordner „/srv/sftp“ landen. Im eigenen Unterordner des User ist dann die Schreibberechtigung für abzulegende Inhalte vorhanden.
Wichtig ist bei dieser Einrichtung vor allem die korrekte Vergabe der Verzeichnis-Berechtigungen:
- Der Eigentümer des chroot-Ordners MUSS „root“ (UID 0) sein.
- Die Gruppe des chroot-Ordners MUSS die in der „sshd_config“ angegebene Gruppe (hier „sftponly“) sein.
- Die Berechtigung des chroot-Ordners MUSS 750 (User: Vollzugriff, Gruppe, lesen+ausführen, Andere: kein Zugriff) sein.
Wird eine dieser Bedingungen nicht erfüllt, verweigert der SSH-Server den Zugriff mit einer entsprechenden Fehlermeldung im Syslog:
Feb 11 11:33:02 server sshd[10053]: fatal: bad ownership or modes for chroot directory "/srv/sftp"

Super Anleitung hat mich schon ganz gut vorran gebracht, bloß ich habe folgendes Problem:
Ich habe das Ganze auf einer CentOS 6 Distribion ausprobiert. Habe alles nach der Anleitung befolgt, außer dass bei mir das Chroot-Verzeichnis unter /data/sftp liegt.
Anschließend verbinde ich mich erfolgreich mit einem der angelegten Usern über WinSCP und bin im Jailrootverzeichnis gefangen. (So wie es ja sein soll!)
Ich kann auch alle darin angelegten Ordner und Dateien sehen.
Und wenn man „Testdaten“ noch mit den richten Userrechten ausstattet
kann man diese auch downloaden.
->
# chown user1:user1 /data/sftp/user1/[Beispieldatei]
# chmod 700 /data/sftp/user1/[Beispieldatei]
Eigentliches Problem:
=====================
Ich kann keinerlei Daten über WinSCP von meinem PC auf den SFTP-Server kopieren (uploaden). Ich kann auch über WinSCP keine Ordner anlegen oder Ordner/Dateien löschen.
Es kommt immer die Fehlermeldung „Permission denied“ „ErrorCode 3″…
Ich gehe mal schwer davon aus, dass es irgendwas mit den Zugriffs/User – Rechten zu tun hat. Bin aber bis jetzt noch einfach auch keine Lösung des Problems gestoßen.
Hat jemand einen Lösungsansatz??? Würde mich sehr freuen!
Poste mal bitte die Besitzerdaten und Berechtigungen von folgenden Elementen:
/data
/data/sftp
/data/sftp/user1
/data/sftp/user1/[Beispieldatei]
Hilfreich wäre auch der entsprechende Chroot-Auszug aus Deiner sshd_config. Dann kann ich Dir bestimmt etwas dazu sagen.
gibt eses diesen sftpserver für windows 7?
Siehe oben.
frage leute,gibt es diesen sftp server auch für windows 7?bitte schnelle antwort.
Es existiert z.B. http://sshwindows.sourceforge.net/. Ich kann jedoch über die Qualität nichts sagen, das käme auf einen Versuch an.
gibt es eigentlich auch eine Möglichkeit zusätzlich zum SFTP-Force bei Login ein gesondertes Script im Hintergrund zu starten?
Ziel ist es in meinem Fall, ein Whitelisting auf iptables-basis anzustoßen, welches dazu sorgt, dass der User nicht nach einer gewissen Anzahl von Logins gebannt wird (SFTP baut ja an mancher Stelle parallel mehrere Verbindungen auf, was dann zum sofortigen Ban führen kann).
Daher muss ich bei der erfolgreichen Anmeldung ein Script starten, welches dann IP ausliest und temporär im IP-Filter als whitelisting vermerkt und somit keine Probleme entstehen können.
Grüße Chris
Hallo,
hast du eine Lösung gefunden. Hab ein Ähnliches Problem.
„Die Gruppe des chroot-Ordners MUSS die in der “sshd_config” angegebene Gruppe (hier “sftponly”) sein.“
Das ist falsch.
Hi,
bei mir kommt „Dateiliste für „/“ konnte nicht abgerufen werden.“ wenn ich mich anmelden möchte. Habe alles 1:1 so gemacht wie oben. Ausser „usermod…“ -A gibt es bei mir nicht und die Reihenfolge der Parameter ist eigentlich anders: „usermod -g sftpony user1“ machts dann.
Rechte:
/srv -> root:root 755
/srv/sftp -> root:sftpony 750
/srv/sftp/user1 -> user1:sftponly 700
Und meine sshd_conf:
Subsystem sftp internal-sftp
Match Group sftponly
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
ChrootDirectory /srv/sftp
Übersehe ich da was, oder hat sich hier was Grundlegend geändert, seit dem Post?
Es wäre vielleicht nicht verkehrt gleich das home-Verzeichnis des Users zu chrooten dann spart man sich das Gefummel mit den extra Verzeichnissen usw.
s. 6. Anpassen der Datei “/etc/ssh/sshd_config”:
ChrootDirectory %h
Mercy!
Hatte schon einige Hilfeseiten gefunden, die den Kern bereits ansprachen.
Bei mir gings nicht!?
Tjaa der Owner war nicht root und chroot wollte nicht.
Hier habs dann gefunden!
Vielen Dank!