• Vorbemerkung
• OpenSSH mit scponly(c)
• OpenSSH mit rssh
  • Installation von OpenSSH, Patches und Tools
  • Installation der rssh
  • User einrichten
  • Chroot Umgebung erstellen
  • Einstellungen der rssh Konfigurationsdatei rssh.conf
  • sshd_config anpassen
  • Einen neuen User aufnehmen
• Quota
• QoS / HTB
• Links

Diese Seite beschreibt die Einrichtung eines OpenSSH Servers, über den User nur SFTP und/oder SCP in ihrer Chroot Umgebung ausführen können. Der Server soll nur Protokoll 2 und Public-Key Authentifizierung unterstützen. Außerdem werden zusätzliche Möglichkeiten des Loggens von SFTP Transaktionen und der Rechtevergabe eingerichtet. Damit und aufgrund der Verschlüsselungskapazitäten von OpenSSH wird der Server zu einer sicheren Alternative zu allen privat betriebenen FTP Servern.

Über QoS und HTB wird die Upload Bandbreite, über Quota der Platzverbrauch der SFTP/SCP User beschränkt.
Zur Erreichung der Ziele kommt eine OpenSSH Version zum Einsatz, die mit Chroot und sftp-logging Patches modifiziert wird. Für die User Restriktionen wird die rssh und Chroot Umgebungen eingerichtet. Um den Upload Traffic und Quota zu steuern, wird der Kernel mit Quota und QoS/HTB kompiliert und das htb.init Script verwendet.
Die Beschreibung und Umsetzung ist an Fedora Linux orientiert, weil es hier im Einsatz ist, dürfte aber problemlos auf andere Distributionen anzuwenden sein.

Hinweis: Alle Programme werden mit "make install" installiert. Für RPM-Lösungen kann man sich z. B. RPM Pakete mittels checkinstall bauen, sich die Informationen des RPM HOWTO aneignen oder bei RPM pbone.net bzw. in den RPM Repositories nach fertigen Paketen suchen.

Laut einem Security Advisory auf der Bugtraq Malingliste vom 02.12.2004 können per rssh <= 2.2.2 und scp, rdist, rsync mit Ausnahme von sftp Kommandos und Programme auf dem Host außerhalb der Shell ausgeführt werden.

Mit der Version 2.2.3 wurden Prüfroutinen auf scp, rdist und rsync Argumente zur Kommandoausführung hinzugefügt.

Vorweg eine einfache und schnell umzusetzende Methode, mit scponly und dem OpenSSH Server so, wie er von den Repository der Distribution ausgeliefert wird, einen reinen SFTP/SCP Server einzurichten. scponly ist eine abgesicherte Shell bzw. ein Wrapper für eine begrenzte Anzahl von Programmen, die per SSH ausgeführt werden dürfen.

Zuerst wird das Binärpaket des OpenSSH Servers aus dem Distributionsrepository installiert und konfiguriert. Bei Fedora Core z. B. mit

$ yum install "openssh openssh-server"

Anschließend wird scponly installiert. Dabei sollte man darauf achten, dass bei einem Binärpaket auch die chroot-Variante scponlyc von scponly enthalten ist, was z. B. bei dem Paket aus dem Fedora Extras Paket nicht der Fall ist. Ob das scponly Binärpaket der Distributionsrepositories scponlyc enthält, kann man mit dem Paketmanager der eigenen Distribution überprüfen. Unter Fedora Core Linux z. B. mit:

$ yum what have scponlyc
$ No Matches found

Ohne scponlyc ist es dem Benutzer möglich, auf die meisten Dateien des Dateisystems lesen zuzugreifen, dafür muss scponlyc mit setuid ausgeführt werden. Allerdings wird scponlyc erst nach der Authentifizierung des Benutzers aufgerufen, die Kommandos bzw. scp oder sftp werden nicht mit UID 0 ausgeführt und man sollte schon ein Mindestmaß an Vertrauen in die Benutzer haben, denen man Zugriff auf den eigenen Rechner gewähren kann.

Für den Fall, dass scponlyc nicht im Binärpaket enthalten ist, hier der manuelle Weg:

1. scponly Sourcecode entpacken:
   $ tar -xzf sconly-version.tgz
2. scponly kompilieren und installieren:
   $ ./configure --enable-chrooted-binary --disable-wildcards
   
   scponly kann neben scp und sftp mit folgenden Optionen für weitere Programme optimiert werden oder nicht:
   
   --disable-gftp-compat schaltet Kompatibilität für gFTP ab
   --disable-winscp-compat schaltet Kompatibilität für WinSCP ab
   --enable-unison-compat schaltet Kompatibilität für unison an
   --enable-rsync-compat schaltet Kompatibilität für rsync an
   --enable-svn-compat schaltet Kompatibilität für den svn Client an
   --enable-svnserv-compat schaltet Kompatibilität für dden svn Server an
   
   $ make
   $ su root
   $ make install
3. scponlyc in die Liste der shells aufnehmen:
   $ which scponlyc >> /etc/shells
4. Benutzer und chroot Umgebung anlegen.
   Am einfachsten wird das mit der Ausführung des Kommandos make jail erledigt. make jail ruft das Shellscript setup_chroot.sh auf.
   
   Beispiel:
   
   
   • $ ./make jail
   • Username to install [scponly] # Eingabe des Benutzernames
     
     home directory you wish to set for this user [/home/scptest] # Eingabe des Pfades zum chroot Heimatverzeichnisses für den Benutzer
     
     name of the writeable subdirectory [incoming] # Das Unterverzeichnis im chroot Heimatverzeichnis, auf das der Benutzer einzig Schreibrechte erhält
     
     New UNIX password:
     Retype new UNIX password: # Eingabe des Passwortes für den Benutzer
   Damit hat das Script einen neuen Benutzer angelegt und ein Heimatverzeichnis erstellt, das alle benötigten Bibliotheken und Programme enthalten sollte. Für die Anwender, bei denen das Script nicht funktionieren sollte, enthält das scponly Archiv in der Datei BUILDING-JAILS.txt eine Anleitung zur manuellen Einrichtung eines Chroot Jails.
   
   Als Gegenprobe, ob auch wirklich alle Bibliotheken in das chroot Heimatverzeichnis kopiert wurden, kann man sich mit
   
   $ ldd /chroothome/user/usr/bin/scp
   $ ldd /chroothome/user/usr/libexec/openssh/sftp-server
   
   die Pfade und Bibliotheken ausgeben lassen, von denen scp und sftp-server abhängen und anschließend mit den kopierten Bibliotheken vergleichen.
5. Anschließend kopiert man die öffentlichen SSH Schlüssel der berechtigten Nutzer in die authorized_keys Datei mit
   
   $ cat sshpubkey.pub >> /pfad/authorized_keys
   
   Bei der zweiten Methode, die unten dargestellt wird, liegt die authorized_keys Datei im /chroothome/user/.ssh/ Verzeichnis. Praktischer ist es, zentral eine authorized_keys Datei außerhalb der chroot Heimatverzeichnisse zu pflegen. Dazu legt man z. B. in /etc/pki/ das Unterverzeichnis .ssh an und speichert dann die authorized_keys in /etc/pki/.ssh/. In der sshd_config des SSH-Servers passt man dann die entsprechende Option an:
   
   AuthorizedKeysFile /etc/pki/.ssh/authorized_keys

Neben dem incoming Verzeichnis, in das der Benutzer Dateien ablegt, kann man ein weiteres Unterverzeichnis z. B. mit dem Namen pub anlegen, in das man Dateien ablegt oder Verzeichnisse mit Dateien mountet, die sich der Benutzer herunterladen kann.

Um Benutzer auf die Verzeichnisstruktur und den Typ des Servers hinzuweisen, kann man dem Benutzer den Inhalt der /etc/ssh/banner Datei vor der Authentifizierung übermitteln lassen. Die entsprechende Option in der sshd_config:

Banner /etc/ssh/banner # kann natürlich auch anders heißen als "banner"

Bevor sich bei mir ein Benutzer authentifiziert, erhält er z. B.:

1. Chroot Patch osshChroot-version.diff, den sftplogging Patch openssh-version.sftplogging-vn.n.patch, die rssh, x11-ssh-askpass und bei OpenSSH den zu den Versionen des Chroot und sftp-logging Patches passenden OpenSSH Sourcecode openssh-version.tar.gz plus GnuPG Signaturen oder MD5 Hashes (falls vorhanden) herunterladen.
2. GnuPG Signaturen oder MD5 Hashes überprüfen.
3. OpenSSH Sourcecode entpacken:
   $ tar -xzf openssh-version.tar.gz
4. osshChroot-version.diff und openssh-version.sftplogging-vn.n.patch in das Verzeichnis kopieren, das dem OpenSSH Sourcecode Verzeichnis übergeordnet ist und in das Verzeichnis wechseln
5. Chroot Patch anwenden:
   $ patch -p0 < ./osshChroot-version.diff
6. sftplogging Patch anwenden:
   $ patch -p0 < openssh-version.sftplogging-vn.n.patch
7. Falls mit der Distribution bereits OpenSSH installiert wurde, OpenSSH und Dienstprogramme deinstallieren.
   Zum Beispiel bei einem RPM basierten System:
   1. sshd Konfig und Schlüssel
      löschen: $ rm -dirv /etc/ssh/
      oder
      sichern: $ mv /etc/ssh/ /etc/ssh_old/
   2. $ rpm -qa | grep openssh
      openssh-clients-version
      openssh-version
      openssh-askpass-version
      openssh-askpass-gnome-version
      openssh-server-version
   3. su
   4. $ rpm -e (--nodeps) openssh(-xyz-version)
8. OpenSSH kompilieren und installieren. Z. B. mit
   $ ./configure --sysconfdir=/etc/ssh --with-zlib --with-tcp-wrappers --with-pam --with-privsep-user=sshd --with-privsep-path=/var/empty/sshd --with-xauth=/usr/X11R6/bin --with-pid-dir=/var/run --with-lastlog
   $ make
   $ su root
   $ make install
9. Aus dem contrib/ Verzeichnis gnome-ssh-askpass2 kompilieren & installieren:
   $ make gnome-ssh-askpass2
   $ cp gnome-ssh-askpass2 /usr/local/libexec/gnome-ssh-askpass
10. Aus dem /contrib/redhat Verzeichnis Red Hat spezifische Dateien kopieren:
    $ cp gnome-ssh-askpass.* /etc/profile.d
    $ cp sshd.init /etc/rc.d/init.d/sshd
    $ cp sshd.pam /etc/pam.d/sshd
11. Das sshd Runlevelscript hinzufügen
    $ chkconfig --add sshd
12. x11-ssh-askpass kompilieren & installieren
    $ tar -xzf x11-ssh-askpass-version.tar.gz
    $ cat README | more
    $ ./configure --with-app-defaults=SshAskpass-green.ad
    (Statt green kann auch ein anderer Look wie 1337, NeXTish, default oder motif gewählt werden, siehe README)
    $ xmkmf
    $ make includes
    $ make
    $ su root
    $ make install
    $ make install.man

rssh kompilieren & installieren:
$ tar -xzf rss-version.tar.gz
$ ./configure --sysconfdir=/etc/ssh --exec-prefix=/usr/local --prefix=/usr/local
$ make
$ su root
$ make install

Bei der Einrichtung der SSH User sollte man sich überlegen, dass für jeden User eine extra Chroot Umgebung und ein eigener Syslog Prozess eingerichtet werden muss.
Will man die Anzahl der Chroot Umgebungen und Syslog Prozesse begrenzen, kann man z. B. von dem Modell ausgehen, dass eine begrenzte Anzahl von SSH Usern stellvertretend für Gruppen steht, denen man verschiedene "Vertrauensstufen" und Möglichkeiten zubilligt. Die realen User werden dann über den Eintrag ihrer Public Keys in den authorized_keys Dateien der jeweiligen Chrootumgebungen diesen Gruppen "zugeordnet".
Man richtet z. B. 3 SSH User/Gruppen ein sshuser1, sshuser2, sshuser3 - sshuser1 wird über die rssh SCP und SFTP erlaubt und erhält Zugriff auf mehr Dateien, sshuser2 wird ebenfalls SCP und SFTP erlaubt, hat aber nur auf eine beschränkte Anzahl von Dateien Zugriff und/oder kann nur Downloads ausführen, sshuser3 hat nur SCP Zugriff und kann nur Uploads ausführen.

1. $ groupadd sshusers
   $ useradd sshuserN -m -p Passwort -d /opt/chroot/home/sshuserN -G sshusers -s /pfad/zu/rssh
2. $ rm -fr /opt/chroot/home/sshuserN/*

Damit wird zuerst 1x die Gruppe sshusers angelegt. Danach wird der User sshuserN, mit Gruppenzugehörigkeit zu sshuserN und sshusers (-G), angelegt, sein Heimatverzeichnis (-d) wird erzeugt (-m), ein Passwort vergeben (-p) und ihm wird die rssh als Shell zugeordnet.
Anschließend werden die automatisch angelegten Unterverzeichnisse und Dateien aus dem Heimatverzeichnis des Users gelöscht.

Dazu werden die Verzeichnisse, Bibliotheken, Programme und Konfigurationsdateien in die User Heimatverzeichnisse abgebildet, d. h. liegt z. B. sftp-server in /usr/local/libexec/sftp-server, wird von dort sftp-server in das Verzeichnis /opt/chroot/home/sshuserN/usr/local/libexec/sftp-server kopiert. Das betrifft auch alle Bibliotheken, von denen das Programm abhängt. Um das festzustellen, gibt man "ldd Programm" ein und erhält die Bibliotheken mit Verzeichnissen, die das Programm benötigt. Das betrifft scp, sftp-server, rssh und rssh_chroot_helper. Die ausgegebenen Informationen werden dann verwendet, um die Verzeichnis- und Dateistruktur abzubilden.

/opt/chroot/ - root:sshusers rwx-r-x---
/opt/chroot/dev/ - root:root rwx------
/opt/chroot/home/ - root:sshusers rwxr-x---
/opt/chroot/home/sshuserN/ - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/.ssh - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/.ssh/authorized_keys - root:sshuserN rw-r-----
/opt/chroot/home/sshuserN/dev/ - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/etc/ - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/etc/passwd - root:sshuserN rw-r-----
/opt/chroot/home/sshuserN/lib/ - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/lib/libnss*_files*.so - root:sshuserN rwxr-x---*
/opt/chroot/home/sshuserN/lib/tls/ - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/userarea/ - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/userarea/upload/ - root:sshuserN rwxrwx---
/opt/chroot/home/sshuserN/userarea/download/ - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/usr/ - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/usr/kerberos/ - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/usr/kerberos/lib/ - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/usr/local/bin/rssh - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/usr/local/bin/scp - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/usr/local/libexec/rssh_chroot_helper - root:sshuserN rwxr-x---
/opt/chroot/home/sshuserN/usr/local/libexec/sftp-server - root:sshuserN rwxr-x---

* Die Bibliotheken sind notwendig, damit der User SCP verwenden kann.

Aus der /etc/passwd wird die entsprechende Zeile mit den Angaben zu sshuserN in die Datei /opt/chroot/home/sshuserN/etc/passwd kopiert.

In /etc/sysconfig/syslog werden für syslogd und für jeden SSH User in der Chrootumgebung zusätzliche Sockets angegeben (maximal 19):
SYSLOGD_OPTIONS="-m 0 -a /opt/chroot/dev/log -a /opt/chroot/home/sshuserN/dev/log"
Danach den syslogd neu starten:
$ service syslog restart

logfacility = LOG_name # name = Syslogkategorie, z. B. AUTH

# allowrsync # rsync erlauben
# allowrdist # rdist erlauben
# allowcvs # cvs erlauben
allowsftp # SFTP erlauben
allowscp # SCP erlauben

umask = 022 # Standard umask

chrootpath="/opt/chroot" # Standard chroot Verzeichnis

# User konfigurieren:
user="sshuserN:umask:nnnnn:/opt/chroot/home/sshuserN"
# n = 0|1 = Bits zur Deaktivierung|Freischaltung von rsync, rdist, cvs, SFTP und SCP (in der Reihenfolge)
z. B. 00011 = User kann nur SFTP und SCP nutzen.

Mit dem sftp-logging Patch kommen einige Optionen hinzu:

LogSftp yes # zusätzliche Informationen zu Kommandos, die der SFTP User ausführt, werden geloggt (Verzeichniswechsel, Löschen von Dateien, chmod, chown usw.)
SftpLogFacility AUTH # Syslog Kategorie festlegen
SftpLogLevel VERBOSE # Syslog Loggrad festlegen
SftpPermitChmod no # SFTP Usern ist chmod verboten
SftpPermitChown no # SFTP Usern ist chown verboten
SftpUmask # Vorgabe einer umask, die alle anderen überschreibt

sftp-server[397]: realpath /
sftp-server[397]: realpath /.ssh
sftp-server[397]: opendir /.ssh
sftp-server[397]: chown /.ssh/./authorized_keys: operation prohibited by sftp-server configuration.

Eine komplette Aufstellung der verwendeten Optionen erfolgt nicht, weil die Erfordernisse von System zu System abweichen werden.

## Groupnamen, denen Login erlaubt ist
AllowGroups sshusers sshuser1 sshuser2 sshuserN
## Usernamen, denen Login erlaubt ist
AllowUsers sshuser1 sshuser2 sshuserN
## Groupnamen, denen Login nicht erlaubt ist
DenyGroups root users
## Usernamen, denen Login nicht erlaubt ist
DenyUsers user1 user2 userN root

## nur Public Key Authentifizierung + Protokoll 2

ChallengeResponseAuthentication no
HostbasedAuthentication no
IgnoreRhosts yes
PasswordAuthentication no
PermitEmptyPasswords no
PermitUserEnvironment no
Protocol 2
PubkeyAuthentication yes
RhostsRSAAuthentication no
RSAAuthentication no

1. Den erhaltenen Public Key als 'root' in die entsprechende authorized_keys Datei aufnehmen:
   $ cat keydatei >> /opt/chroot/home/sshguserN/.ssh/authorized_keys
2. User muss den unter AllowGroups / AllowUsers in der /etc/sshd_config angegbenen Usern und/oder Gruppen angehören
3. Für den User einen Eintrag in der rssh.conf erstellen, falls er noch nicht existiert.
4. Für den User muss ein glaichlautender Eintrag in der /etc/passwd und /usr/chroot/home/sshuserN/etc/passwd existieren.

Um die SSH User daran zu hindern, den Plattenplatz durch Uploads vollständig auszunutzen, sollte man den Plattenplatz durch Quota beschränken. Als Beispiel soll für den SSH User sshuser1 Block User Quota eingerichtet werden. Auf ähnlichem Weg kann auch ein Gruppen Quota eingerichtet werden oder beides. Zur Information sind die entsprechenden Kommandos für Group Quota mit aufgeführt. Nähere Informationen findet man im Red Hat Red Hat Linux Customization Guide Kapitel 6 oder "man quota|quotacheck|quotaon|edquota|repquota".

1. Um Quota Begrenzungen nutzen zu können, muss der Kernel mit Quotaunterstützung kompiliert sein. Sollte dies nicht der Fall sein, muss der Kernel mit folgenden Einstellungen neu kompiliert werden:
   
   File systems
   ->Quota support (CONFIG_QUOTA) y
   ->Old quota format support (CONFIG_QMFT_V1) y|m
   ->VFS v0 quota format support (CONFIG_QFMT_V2) y|m
   
   Wenn Quota als Modul kompiliert wird, in /etc/rc.d/rc.sysinit Zeile 573 mit
   action $"Enabling local filesystem quotas: "/sbin/quotaon -aug
   ergänzen zu
   action $"Enabling local filesystem quotas: "/sbin/modeprobe quota_v2 && /sbin/quotaon -aug
2. In /etc/fstab User Quota für Filesystem aktivieren, d. h. für die Wurzel, unter der die Chroot Umgebung eingerichtet wurde:

   für User Quota
   LABEL=/opt	/opt	ext3	defaults,usrquota	1 2
   für Group Quota
   LABEL=/opt	/opt	ext3	defaults,grpquota	1 2

3. Neu booten
4. Quota Datei im Rootverzeichnis des Filessystems erstellen:
   "aquota.user" für User Quota
   $ quotacheck -vcu /opt
   
   "aquota.group" für Group Quota
   $ quotacheck -vcg /opt
5. Tabelle der aktuellen Plattennutzung für Quota aktiviertes Filesystem erstellen:
   für User Quota
   $ quotacheck -avu
   
   für Group Quota
   $ quotacheck -avg
6. Quotas für User zuordnen, bzw. editieren:
   Zuerst informationen über Blöcke/Platznutzung einholen und den bereitzustellenden Plattenplatz in Blockangaben umrechnen:
   $ df -k /opt (in KB Blöcken)
   $ df -m /opt (in MB Blöcken)
   KB / 1024 = 1MB
7. Im Editor die Angaben für soft und hard limits für "blocks" (in KB) ändern:
   für User
   $ edquota sshuser1 -f /opt
   
   für Group
   $ edquota -g groupname -f /opt

   Anzeige im Editor:

   Disk quotas for user sshuser1 (uid nnn):
   Filesystem	blocks	soft	hard	inodes	soft	hard
   /dev/hdN	3720	102400	153600	47	0	0

   
   In diesem Beispiel verwendet sshuser1 aktuell 3.63 MB (3720 KB-Blöcke), darf 100 MB (102400 KB-Blöcke) verbrauchen (soft limit) und bis maximal 150MB (153600 KB-Blöcke) (hard limit) für die Dauer von 7 Tagen, der sogenannten "grace period", überschreiten.
8. Quota Konfiguration prüfen:
   für User
   $ quota sshuser1
   
   für Group
   $ quota -g groupname
9. Quota Report und Staistik:
   für User
   $ repquota -vus /opt
   
   für Group
   $ repquota -vgs /opt

OpenSSH bringt von Hause aus keine Funktionen zur Steuerung der Bandbreite mit wie alle bekannten FTP Server. Das mag für Anwender mit einer Standleitung weniger von Bedeutung sein. Für ADSL Flat Anwender, die in der Regel nur eine Uploadbandbreite von 128 Kb haben, aber schon. Um trotzdem eine Begrenzung des Uploads durch SFTP User zu erreichen, kann man auf die QoS Unterstützung des Kernels zurückgreifen und mit dem htb.init Script eine HTB (Hierachical Token Bucket) basierte Traffic Kontrolle für SSH/SFTP Transaktionen einrichten.

1. Sofern nicht bereits im Kernel aktiviert, wird der Kernel mit QoS Unterstützung neu kompiliert:
   
   Networking Options
   -> QoS and/or fair queueing
   -->QoS and/or fair queueing (CONFIG_NET_SCHED) y
   --->alle angegebenen Algorithmen als Modul aktivieren m
   -->QoS support (CONFIG_NET_QOS) y
   -->Rate estimator (CONFIG_NET_ESTIMATOR) y
   -->Packet classifier API (CONFIG_NET_CLS) y
   --->alle Klassifizierungsmechanismen als Modul aktivieren m
   -->Traffic policing (CONFIG_NET_CLS_POLICE) y
2. iproute (neu) installieren.
   Das Red Hat 9 Paket iproute-2.4.7-7.90 funktionierte nicht mit dem htb.init Script. Dazu war die Installation des iproute-2.4.7-11 Pakets aus der Fedora Core 1 Distribution nötig. Nicht getestet wurde mit dem originalen iproute Paket.
3. Das HTB.init Script runterladen und hinzufügen:
   
   $ cp htb.init-version /etc/rc.d/init.d/htb.init
   $ chmod ugo+x /etc/rc.d/init.d/htb.init
   $ chkconfig -add htb.init
4. Verzeichnis für HTB Konfiguration anlegen:
   $ mkdir /etc/sysconfig/htb
5. In /etc/sysconfig/htb werden Konfigurationsdateien für das Interface angelegt, für das der Traffic reguliert werden soll. Die Dateien definieren verschiedene Traffic "Klassen". Alle Klassen sind hierarchisch über die Angabe einer ID miteinander verknüpft.
   
   Ein einfaches Beispiel anhand des Interfaces eth0. Ausführlichere Informationen und weitere Beispiele sind über das htb.init Script und die Links zu finden.
   • eth0
     
     Inhalt:
     DEFAULT=30
   • eth0-2.root
     
     Inhalt:
     RATE=128Kbit
   • eth0-2:10.sftp
     
     Inhalt:
     RATE=64Kbit
     CEIL=64Kbit
     LEAF=sfq
     RULE=*:22,
   • eth0-2:30.def
     
     Inhalt:
     RATE=64Kbit
     CEIL=128Kbit
     LEAF=sfq
   Erklärung:
   
   Für das Interface eth0 wird die Datei eth0 angelegt, in der globale HTB qdisc Parameter stehen. DEFAULT=30 gibt an, dass für jeden Traffic, der nicht über andere Klassen Konfigurationsdateien definiert wird, die Einstellungen der Konfigurationsdatei mit der ID 2:30 zutreffen. In der Klassen-Datei eth0-2.root, die das oberste Level innerhalb der Klassenhierarchie darstellt, wird die maximale Upload Bandbreite des Interfaces in Kilobits/s angegeben. In der Unterklassen-Datei eth0-2:10.sftp der Anteil, der von der zur Verfügung stehenden Uploadbandbreite für SCP/SFTP Uploads bereitstehen soll. Mit CEIL=64Kbit wurde definiert, dass der Bandbreite dieser Klasse keine Bandbreite der übergeordneten Klasse zugeschlagen werden soll, d. h. von den 128Kbit der eth0-2.root. Mit LEAF=sfq wird festgelegt, dass zur Bandbreitenregelung der "Stochastic Fairness Queueing" Algorithmus verwendet wird. Die Anagbe RULE=*:22, besagt, dass jeder Traffic ausgewählt werden soll, der von jedem Host/Netzwerk von Port 22 ausgeht (auf dem in diesem Beispiel sshd arbeitet). Für allen anderen Traffic wird über den Verweis in der Datei eth0 in der Klassendatei mit der ID 2:30 erlaubt, 64Kbit zu nutzen und wenn kein anderer Traffic auftritt, bis zu 128Kbit.
   Für die Selektion des Traffics über die RULE Angabe kann auch die Paketmarkierung von iptables mit "--set-mark" verwendet werden.

• SSH: The Secure Shell
  The Definitive Guide
• Chroot Umgebung für OpenSSH und sftp
• Traffic Shaping with Linux v2.4 and HTB qdisc
• HowTo do a "Einfache Bandbreitenbeschränkung"
• Traffic Control & QoS mit Linux 2.4