Alle Jahre wieder. So könnte das Thema dieses Beitrags lauten. Alternativ lautet er einfach wie oben angegeben.

Das aktualisierte Howto ist unter der bekannten URL zu finden. Im Unterschied zu den vorigen Versionen funktioniert die Anleitung jetzt auch mit der neuen Betriebsumgebung der Exklusiv-/Managed-/Homepage-Server, die auf Debian Etch basiert. Die Installation ist alles in allem einfacher geworden, da bspw. Ruby nicht mehr selbst installiert werden muss. Allerdings ist dafür die Möglichkeit mod_proxy zu nutzen weggefallen. Somit kann Ruby on Rails auf den Homepage-Servern nicht mehr mit Mongrel, Thin oder einem anderen Backend-Server betrieben und mittels mod_rewrite/mod_proxy zum Apache Webserver durchgereicht werden. Die einzige Möglichkeit für den Produktivbetrieb bleibt also die Einbindung über FastCGI.

Fehler, Anmerkungen usw. können wie immer in den Kommentaren hinterlassen werden.

Seit OpenSSH 4.9 unterstützt der SSH-Daemon des OpenBSD Projekts das Einsperren der Benutzer in einem beliebigen Verzeichnis über den chroot(2) Systemaufruf. Zuvor war dies nur mit einem Thirdparty Patch wie chrootssh oder im Fall der Einschränkung auf SFTP/SCP mit speziellen Shells wie scponly oder rssh möglich.

Ebenfalls mit Version 4.9 wurde eine Variante des sftp-server(8) eingeführt, die direkt in sshd(8) gelinkt ist. Das hat den großen Vorteil, dass nicht mehr alle Binaries und Programme, die ein Benutzer ausführen können soll oder muss (z. B. seine Shell oder die SFTP-Bibliothek) sowie die Gerätedateien /dev/null und /dev/urandom innerhalb der chroot-Umgebung vorhanden sein müssen. Das erspart dem Administrator die fehlerträchtige Erstellung einer solchen Umgebung sowie die Redundanz der in den chroot-Umgebungen benötigten Dateien.

Die Einrichtung erfolgt sehr einfach in der sshd_config(5). Zunächst muss das Subsystem "sftp" mit dem intern vorhandenen SFTP-Server ("internal-sftp") geladen werden:

Subsystem sftp internal-sftp

Danach können entweder global alle Benutzer in eine chroot-Umgebung eingesperrt werden (nicht zu empfehlen) oder über einen Match-Block nur einzelne Benutzer, Gruppen oder IP-Adressen bzw. IP-Adressbereiche. Die Festlegung des Verzeichnisses, in dem der Benutzer eingesperrt wird, erfolgt über die Direktive ChrootDirectory. Als Parameter wird das Verzeichnis erwartet, wobei die Zeichenkette einige Variablen enthalten kann:

Variable	Bedeutung
%h	Home-Verzeichnis des Benutzers
%u	Benutzername des Benutzers
%%	'%' Zeichen

Die Direktive ChrootDirectory /srv/www/%u würde den Benutzer "web1" also im Verzeichnis /srv/www/web1 einsperren. Soll der Benutzer zusätzlich wirklich nur via SFTP auf den Server zugreifen können, kann dies mit der Direktive ForceCommand internal-sftp erzwungen werden.

Achtung: Dadurch ist wirklich nur noch ein Zugriff via SFTP möglich. Auch SCP funktioniert dann nicht mehr!

Hier ein paar Beispieleinträge in der sshd_config. Die Match-Blöcke müssen unbedingt am Ende der Datei stehen, da sonst alle folgenden Direktiven, die auch in einem Match-Block stehen könnten, dem letzten Block zugeordnet werden!

# Clients aus dem IP-Adressbereich 10.0.1.0/24 einsperren.
Match Address 10.0.1.*
  ChrootDirectory %h

# Benutzer mit der Gruppe sftp im Homeverzeichnis einsperren und nur SFTP erlauben
Match Group sftp
  ChrootDirectory %h
  ForceCommand internal-sftp

# Benutzer web* (z. B. web1, web42, web123, web4711) in /srv/www/ einsperren und nur SFTP erlauben
Match User web*
  ChrootDirectory /srv/www/%u
  ForceCommand internal-sftp

Sobald ein Benutzer mit dieser sshd-Konfiguration mit `gpasswd -a sftp` der Gruppe "sftp" hinzugefügt wird, kann dieser sich in Zukunft nur noch innerhalb seines zugewiesenen Verzeichnisses bewegen. Ideal zur Absicherung eines Servers mit mehreren nicht vertrauenswürdigen Benutzern.

Quellen:
sshd_config(5)
OpenBSD Journal - Chroot in OpenSSH
Debian Administration - OpenSSH SFTP chroot() with ChrootDirectory

Disclaimer: Der Artikel wurde nach bestem Wissen und Gewissen geschrieben und überprüft. Ich übernehme jedoch keinerlei Haftung für Schäden, die durch Ausführung der in diesem Artikel aufgeführten Kommandos entstehen oder entstanden sind.

Derzeit ist auf den Homepage-Servern (sowie den Managed- und Exklusiv-Servern) von 1&1 noch MySQL 4.0 installiert. Für einige Anwendungen werden jedoch Features benötigt, welche erst mit MySQL 4.1 oder MySQL 5.0 eingeführt wurden, etwa Unterstützung für Unicode oder Store Procedures.

Es ist jedoch möglich einen eigenen MySQL-Server in der gewünschten Version innerhalb des Homeverzeichnisses auf dem System zu installieren. Dieser Artikel beschreibt die notwendigen Schritte.
More »