SFTP Benutzer chrooten – Oder wie man Benutzer zur sicheren Datenübertragung einsperrt


Zugriff auf Daten per FTP herstellen ist einfach, aber in den meisten Fällen sehr unsicher. Der Datenverkehr lässt sich „abhören“, Benutzername und Passwort werden im Klartext übertragen. Sicherer ist die Verbindung per SFTP, welche über eine SSH Verbindung hergestellt wird. Somit ist die Übertragung verschlüsselt und nicht mitlesbar.
Die einfachste Variante ist direkt gegeben: Jeder Benutzer auf dem Linux/UNIX System, der auch eine Shell hat, kann eine Verbindung per SFTP herstellen. Das ist bequem und einfach, will man aber nicht unbedingt. Damit wäre quasi das komplette System für jeden offen und alle Daten könnten mehr oder weniger einfach eingesehen werden. Für normale Nutzer des Systems ist das OK. Aber für Benutzer, die einzig und allein Daten hoch- oder auch runterladen sollen ist das eigentlich schon zu viel. Sei es, dass man mehreren unterschiedlichen Benutzern einen eigenen Datenspeicher anbieten möchte (z.B. für Webhosting unterschiedlicher Seiten). Man möchte natürlich nur, dass jeder seinen Datenbereich einsehen und nutzen kann. Hierzu ist das „Chrooten“ eines Benutzeraccounts sinnvoll.


Um einen Benutzer oder auch ein Benutzergruppe in ein Verzeichnis/-baum zu verbannen wird in der Konfiguration des SSH Servers (/etc/ssh/sshd_config) das chrooten aktiviert:


1. Schritt: Änderung SFTP Verhalten
Das Verhalten des SFTP Servers wird umgestellt. Die Original-Zeile wird durch internal-sftp ersetzt:

#Subsystem sftp /usr/libexec/sftp-server
Subsystem sftp internal-sftp


2. Schritt: Match-Regeln anlegen
Für die Home-Verzeichnisse der SFTP-Benutzer wird ein Verzeichnispfad /pfad/nurfuerftpuser/ genutzt. Unterhalb dieses Pfades werden für die Benutzer jeweils ein eigenes Home Verzeichnis erstellt und die Benutzer in dieses „gechrootet“. Wir haben einen Benutzer sftpbenutzername, der nun eine Match-Regel erhält:

# SSH chroot fuer SFTP Benutzer
Match User sftpbenutzername
    ForceCommand internal-sftp
    ChrootDirectory /pfad/nurfuersftpuser/%u
    AllowTCPForwarding no
    X11Forwarding no

Die Angabe von %u ist in diesem Falle eine Variable für den Benutzernamen sftpbenutzername. Kann man sich in diesem Falle eigentlich sparen, da der Benutzername in der Match-Regel angegeben ist.

Will man nun eine ganze Gruppe von Benutzern in dieser Match-Regel abgreifen, so kann man dieses mit der Group-Regel machen:

# SSH chroot fuer SFTP Gruppe
Match Group sftpgruppe
    ForceCommand internal-sftp
    ChrootDirectory /pfad/nurfuersftpuser/%u
    AllowTCPForwarding no
    X11Forwarding no

Somit werden alle Benutzer, die in dieser Gruppe sind, automatisch gechrootet.


3. Schritt: Rechte in der Verzeichnisstruktur

Das Chrooten setzt eine Änderung der Verzeichnisrechte und des Besitzers voraus. Nur wenn dieses erfüllt ist, kann der Benutzer sich in sein Verzeichnis erfolgreich einloggen. Andernfalls kommen in den Logzeilen des SSHd ähnliche Einträge:

…. sshd[pid]: fatal: bad ownership or modes for chroot directory component „/pfad/nurfuersftpuser/“

…. sshd[pid]: fatal: bad ownership or modes for chroot directory „/pfad/nurfuersftpuser/sftpbenutzername“
(1. Zeile: Besitzer oder Rechte im Chroot-Verzeichnis sind falsch. 2. Zeile: Das Homzeichnis ist noch falsch

Der Besitzer von /pfad/nurfuersftpuser/ muss root sein. Ein
chown root:root /pfad/nurfuersftpuser/
ändert den Besitzer auf root, Gruppe root. (Gibt es die Gruppe root beispielsweise nicht (FreeBSD/ UNIX), so die passende Gruppe (wheel) wählen.).
Die Rechte müssen 755 sein:
chmod 0755 /pfad/nurfuersftpuser/
Damit sind die Rechte umgestellt. Das hat allerdings einen entscheidenden Nachteil: Man kann nicht mehr direkt als Benutzer im Chroot-Wurzelverzeichnis Dateien oder Ordner erstellen. Erst darin (und von einem SSH Benutzer) angelegte Verzeichnisse lassen den Benutzer in diese schreiben. Warum, das liegt an den obigen Rechten. Irgendwie unschön, aber wohl auf die Schnelle nicht anders machbar…..


4. Schritt: Konfiguration neu laden/ SSHd neu starten

Nachdem die Konfiguration geändert wurde muss der SSHd einmal neu geladen werden, also die Konfiguration eingelesen. Hierzu wird der ge’hup’t (kill -HUP pid) oder mit einem Start-Stop-Skript neu gestartet. Der HUP Aufruf ist der einfachste und sicherste Weg, ohne dass man sich u.U. den Ast absägt, auf dem man sitzt. Ist man nur per SSH verbunden (und kannn auch nur per SSH auf das System) so sollte man sich ein paar Gedanken machen, was passiert, wenn man an der falschen Stelle sägt 😉
Eine aufgebaute SSH Verbindung erzeugt eine child-Prozess, der unabhängig vom Mutterprozess läuft. Also einfach eine zweite SSH Verbindung starten, über die erste den SSH Prozess neu starten oder den HUP Aufruf durchführen. Startet der SSHd nicht mehr hat man zumindest noch die bestehende Verbindung.

Nun kann der Benutzer per sFTP eine Verbindung aufbauen und bleibt in seinem „Home“Verzeichnis eingesperrt. In den normalen Verzeichnisbaum kann er nicht mehr wechseln. Für ihn endet der Zugriff im Chroot-Wurzelverzeichnis, mehr sieht er nicht. Und das ist auch gut so…. 😉


Die noch bessere Absicherung

Damit man hier noch etwas mehr Sicherheit reinbringt: Den Zugriff auf den Server nur über einen VPN Tunnel zulassen. Nach Aufbau des VPN Tunnels kann dann der Zugriff per SFTP erlaubt werden. Somit sichert man den Server noch zusätzlich gegen Angriffe auf die SFTP Useraccounts ab. Kein VPN Tunnel, kein SFTP 😉
Wie man einen OpenVPN Server usw. hierfür aufsetzt habe ich an anderer Stellle ja schon beschrieben.


  Links

http://blog.schalanda.name/archives/154-chroot2-Unterstuetzung-fuer-OpenSSH.html
http://www.linuxquestions.org/questions/linux-security-4/chroot-jail-w-openssh-problems-597142/
http://serversupportforum.de/forum/security/25852-ssh-user-auf-sein-eigenes-verzeichnis-beschraenken.html#post165308
http://www.mynakedgirlfriend.de/sichere-chroot-umgebung-fur-ssh-dateiubertragungen-sftp/
http://forums.freebsd.org/showthread.php?t=20745
http://www.howtoforge.com/chrooted-ssh-sftp-tutorial-debian-lenny


Dieser Beitrag wurde unter Dokus und Tipps, Linux/ UNIX, Technikspielkram abgelegt und mit , , , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

3 Antworten zu SFTP Benutzer chrooten – Oder wie man Benutzer zur sicheren Datenübertragung einsperrt

  1. Robert sagt:

    Danke schön … dein 3. Schritt hat mir geholfen mein Problem zu lösen 🙂

  2. alex sagt:

    Super Anleitung! Danke!
    🙂

  3. Martin sagt:

    Hallo,
    soweit ich mich erinnere hat die Anleitung für mich unter Ubuntu 14.04 mal funktioniert. Deshalb hab ich sie gebookmarked.
    Zwischenzeitlich hab ich auf debian umgestellt.
    Sobald ich dort in der sshd config
    match user (username)
    aufnehme, startet der SSH Server nicht mehr.
    Den Subsystem Befehl nimmt es aber noch.

    Kann es sein, dass dies unter debian 8, anders lauten muss?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert