So beschränken Sie SSH-Benutzer auf bestimmte Verzeichnisse unter Ubuntu 24.04 (SFTP Chroot-Anleitung)

Einem externen Dienstleister Zugriff auf das Hochladen einiger weniger Dateien zu gewähren, sollte ihm nicht automatisch eine Terminal-Sitzung mit Einblick in den gesamten Server ermöglichen. Unter Ubuntu 24.04 LTS kann OpenSSH mithilfe einer ChrootDirectoryRegel und des integrierten internal-sftpServers ein Dateitransfer-Konto auf ein bestimmtes Verzeichnis beschränken. Wichtig ist hierbei, dass es sich um eine reine SFTP-Beschränkung handelt und nicht um eine einfache Möglichkeit, eine voll funktionsfähige, aber eingeschränkte Bash-Shell bereitzustellen.

Diese Anleitung erklärt, welche Funktionen die Einstellungen tatsächlich schützen, und führt anschließend durch eine reversible, achtstufige Einrichtung für mehrere Benutzerkonten mit jeweils eigenem Verzeichnis. Die Befehle verwenden ein Beispielkonto contractorund einen Beispielhost server.example.com; ersetzen Sie diese durch Ihre eigenen Werte. Es handelt sich hierbei um Konfigurationsbeispiele, nicht um bestätigte Ergebnisse eines Live-Servertests.

Welche Art von Einschränkung benötigen Sie tatsächlich?

Drei Steuerungselemente werden oft verwechselt. Linux-Berechtigungen legen fest, welche Dateien ein Benutzerkonto lesen oder ändern darf; das Ändern des Home-Verzeichnisses eines Benutzerkontos definiert dessen anfänglichen Speicherort; ein chroot ändert das Dateisystem-Root-Verzeichnis, das einem Prozess präsentiert wird. Diese drei Begriffe sind nicht austauschbar.

Irrtum: Die Festlegung /home/contractoreines Home-Verzeichnisses schränkt den Benutzer darin ein. Das ist nicht der Fall. Ein normaler Shell-Benutzer kann in jedes erreichbare Verzeichnis im Dateisystem wechseln. Wenn der Dateiaustausch tatsächlich erforderlich ist, wählen Sie die unten beschriebene reine SFTP-Methode, anstatt zu versuchen, Verzeichnisse über die Shell-Eingabeaufforderung auszublenden.

OpenSSH-Dokumente ChrootDirectory, Match, und ForceCommandim offiziellen Ubuntu 24.04 sshd_config-Handbuch .

Richten Sie in acht Schritten ein reines SFTP-Verzeichnis-Jail ein.

Bevor Sie SSH remote ändern, lassen Sie Ihre bestehende Administrator-Sitzung geöffnet und stellen Sie sicher, dass Sie Konsolen- oder Wiederherstellungszugriff haben. Verwenden Sie für Übertragungen ein separates Konto ohne Administratorrechte; fügen Sie Ihr Administratorkonto nicht der eingeschränkten Gruppe hinzu.

1. Überprüfen Sie OpenSSH und halten Sie eine Wiederherstellungssitzung aufrecht.

Installieren Sie gegebenenfalls OpenSSH auf dem Server, überprüfen Sie den Dienst und speichern Sie die Hauptkonfiguration. Die offizielle Serverdokumentation von Ubuntu unterstützt diese Dienst- und Konfigurationspfade.

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh
sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.pre-sftp

Wenn Sie den Rechner nur über SSH verwalten können, schließen Sie die aktuelle Sitzung während der Bearbeitung oder des Testens nicht. Lesen Sie die Konfigurationsanleitung für den Ubuntu OpenSSH-Server, bevor Sie Änderungen am Daemon vornehmen.

2. Erstellen Sie einen dedizierten Benutzer und eine SFTP-Zugriffsgruppe.

Eine Gruppe ist sinnvoll, wenn mehrere eingeschränkte Konten erwartet werden. In diesem Beispiel erhält jedes Mitglied mithilfe des %uTokens, das OpenSSH zum Benutzernamen der Verbindung auflöst, eine separate Umgebung. Das /uploadHome-Verzeichnis soll sich innerhalb des zukünftigen Chroot-Verzeichnisses befinden; erstellen Sie daher kein /uploadVerzeichnis auf Host-Ebene.

sudo groupadd sftpclients
sudo adduser --home /upload --no-create-home --shell /usr/sbin/nologin contractor
sudo usermod -aG sftpclients contractor
id contractor

Der adduserAblauf kann Sie zur Vergabe eines Passworts auffordern. Bei Installationen, die die SSH-Passwortauthentifizierung deaktivieren, erstellen und autorisieren Sie stattdessen einen öffentlichen Schlüssel. Aktivieren Sie die Passwortanmeldung nicht global, nur um einem Beispiel zu folgen. Die nologinShell stellt eine zusätzliche Sicherheitsmaßnahme dar, aber der erzwungene internal-sftpBefehl bewirkt, dass diese Konfiguration nur für die Übertragung gilt. Testen Sie die Kombination mit Ihrer eigenen Authentifizierungsumgebung.

3. Erstellen Sie ein Chroot-Verzeichnis mit Root-Rechten.

Hier liegt der Fehler vieler Anleitungen. OpenSSH erfordert, dass alle Komponenten des Chroot-Pfads dem Benutzer root gehören und von anderen Benutzern oder Gruppen nicht beschreibbar sind. Das Jail-Root-Verzeichnis selbst darf niemals vom SFTP-Konto beschreibbar gemacht werden.

sudo install -d -o root -g root -m 0755 /srv/sftp
sudo install -d -o root -g root -m 0755 /srv/sftp/contractor
namei -l /srv/sftp/contractor

Prüfen Sie auch die vorhandenen /Komponenten /srv; die obigen Befehle beheben unsichere Berechtigungen des übergeordneten Elements nicht automatisch. Wenn eine Komponente für eine Gruppe beschreibbar oder im Besitz eines Benutzers ist, korrigieren Sie deren Besitzverhältnisse und Modus erst, nachdem Sie geprüft haben, ob andere Anwendungen davon abhängen.

4. Fügen Sie ein beschreibbares Unterverzeichnis innerhalb des Jails hinzu.

Das Konto kann in ein Unterverzeichnis schreiben, ohne das Chroot-Root-Verzeichnis ändern zu dürfen. Erstellen Sie ein /srv/sftp/contractor/uploadVerzeichnis für die eigentlichen Dateien des Kontos; innerhalb von SFTP wird dieses als . angezeigt /upload.

sudo install -d -o contractor -g contractor -m 0750 /srv/sftp/contractor/upload
sudo stat -c '%U:%G %a %n' /srv/sftp/contractor /srv/sftp/contractor/upload

Die erwarteten Besitzverhältnisse unterscheiden sich bewusst: root:rootfür das Jail-Root-Verzeichnis und contractor:contractorfür den beschreibbaren Upload-Ordner. Vermeiden Sie die Verwendung von `/etc//` chmod 777, da dies unnötige Risiken birgt und bei Anwendung auf das Jail-Root-Verzeichnis abgelehnt würde.

5. Fügen Sie eine Match-Regel zu sshd_config hinzu.

Öffnen Sie /etc/ssh/sshd_configden folgenden Block und fügen Sie ihn am Ende, nach allen vorhandenen Direktiven und MatchBlöcken, ein. Verwenden Sie dazu einen Texteditor wie z. B. sudoedittsd oder cd sudo nano. Überprüfen Sie Matchvorher die vorhandenen Regeln: Weisen mehrere übereinstimmende Blöcke dasselbe Schlüsselwort zu, verwendet OpenSSH die erste zutreffende Instanz. Ubuntu verarbeitet außerdem Dateien /etc/ssh/sshd_config.d/aus einem frühen .conf- Verzeichnis Include; die dort geltenden Regeln können die Priorität beeinflussen.

Match Group sftpclients
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp -d /upload
    PermitTTY no
    DisableForwarding yes

Match GroupZielt auf Mitglieder von sftpclients. ChrootDirectoryplatziert jeden Benutzer unter /srv/sftp/USERNAME. ForceCommand internal-sftp -d /uploadFührt einen SFTP-Dienst im Prozess aus und startet im beschreibbaren Verzeichnis. PermitTTY noVerhindert die Terminalzuweisung, während DisableForwarding yesSSH-Weiterleitungsfunktionen für übereinstimmende Verbindungen deaktiviert werden.

Behalten Sie die Subsystem sftpvon Ubuntu bereitgestellte globale Direktive bei, es sei denn, Sie haben einen triftigen Grund, sie zu ändern. Der erzwungene interne SFTP-Befehl erfordert keine Änderung dieser globalen Zeile. Fügen Sie keine zusätzliche globale Direktive hinzu, Match Allnur um einen Block abzuschließen, ohne die Auswirkungen zu verstehen.

6. Überprüfen Sie die Syntax und die effektiven Einstellungen vor dem Neuladen.

Ein erfolgreicher Parsing-Vorgang beweist weder die Korrektheit der Jail-Berechtigungen noch, dass das vorgesehene Konto den Richtlinien entspricht. Führen Sie beide Prüfungen explizit durch.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T -C user=contractor,host=localhost,addr=192.0.2.10 | grep -E '^(chrootdirectory|forcecommand|permittty|disableforwarding) '
namei -l /srv/sftp/contractor

Die korrekte Konfiguration sollte den vorgesehenen Chroot-Pfad, den erzwungenen SFTP-Befehl, die deaktivierte TTY-Zuweisung und Weiterleitungsbeschränkungen enthalten. Die Beispieladresse 192.0.2.10dient nur der Dokumentation; falls Sie adressabhängige MatchRegeln verwenden, ersetzen Sie diese durch die tatsächliche Client-Quelladresse. Die -T -CVorgehensweise ist im Ubuntu 24.04 sshd-Handbuch dokumentiert .

Schlägt die Validierung fehl, korrigieren Sie die Konfiguration, bevor Sie SSH neu laden. Sind die effektiven Werte unerwartet, überprüfen Sie die enthaltenen Codeabschnitte und die Reihenfolge der vorhandenen Bedingungsblöcke, nicht nur die zuletzt bearbeiteten Zeilen.

7. Laden Sie SSH neu und behalten Sie Ihren Administratorzugriff bei.

Nach erfolgreichen Prüfungen laden Sie den SSH-Dienst neu, damit neue Verbindungen die geänderte Richtlinie verwenden. Lassen Sie die bestehende Administratorverbindung aktiv und öffnen Sie ein zweites Terminal, um zu überprüfen, ob der normale Administratorzugriff weiterhin funktioniert.

sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

Ein vollständiger Neustart kann die Änderungen ebenfalls anwenden, ein Neuladen ist jedoch vorzuziehen, sofern dies unterstützt wird und Sie unnötige Unterbrechungen vermeiden möchten. Die Ausgabe von Dienstbefehlen und Protokollmeldungen variiert je nach Host. Überprüfen Sie daher das tatsächliche Ergebnis, anstatt anzunehmen, dass eine erfolgreiche Rückkehr zur Eingabeaufforderung den Zugriff garantiert.

8. Testen Sie erlaubte Transfers und blockierte Shell-Zugriffe.

Stellen Sie von einem anderen Computer aus eine Verbindung als eingeschränkter Benutzer her. Verwenden Sie den tatsächlichen Hostnamen des Servers und eine geeignete Testdatei. Das erste SFTP-Verzeichnis sollte `<server-root>` lauten , und das Chroot-Root-Verzeichnis sollte als `<server-root>` und nicht als Hostpfad /uploadangezeigt werden .//srv/sftp/contractor

sftp contractor@server.example.com
sftp> pwd
sftp> cd /
sftp> ls
sftp> cd /upload
sftp> put sample.txt
sftp> cd /etc
sftp> exit

Das Hochladen einer harmlosen Testdatei sollte erlaubt sein /upload. Der Zugriff auf das eigentliche Stammverzeichnis des Hosts /etcsollte nicht möglich sein: Das Chroot definiert ein anderes Stammverzeichnis und /etcwäre nur dann zugänglich, wenn Sie ein solches Verzeichnis absichtlich innerhalb des Jails erstellt oder freigegeben hätten. Der genaue Fehlertext des Clients ist nicht wichtig.

ssh contractor@server.example.com

Für dieses Konto darf keine reguläre interaktive SSH-Shell geöffnet werden. Stattdessen kann die Verbindung geschlossen werden oder eine protokollbezogene Meldung angezeigt werden; verlassen Sie sich nicht auf den genauen Wortlaut. Falls sich eine Shell öffnet, betrachten Sie die Konfiguration als unsicher und überprüfen Sie die Gruppenzugehörigkeit, Matchdie Priorität und die effektive sshd -T -CAusgabe, bevor Sie das Konto verwenden.

Was passiert, wenn Sie öffentliche SSH-Schlüssel verwenden?

Die Public-Key-Authentifizierung funktioniert mit einem SFTP-Jail, aber wenn das Home-Verzeichnis eines Benutzers auf Host-Ebene auf /upload„“ gesetzt wird, existiert der Standardpfad ~/.ssh/authorized_keysmöglicherweise nicht außerhalb des Jails. Eine praktische Alternative ist, SSH eine vom Root-Benutzer kontrollierte Schlüsseldatei lesen zu lassen, bevor das Chroot gestartet wird. Fügen Sie dies im selben Match Group sftpclientsBlock hinzu, wenn Sie eine zentrale Schlüsselspeicherung wählen:

    AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Erstellen Sie anschließend /etc/ssh/authorized_keys/contractoreine Datei, die den autorisierten öffentlichen Schlüssel des Auftragnehmers enthält, mit Root-Rechten und ohne Schreibberechtigungen für Gruppen oder die gesamte Welt. Zum Beispiel nach dem sicheren Kopieren einer geprüften Datei mit dem Namen „publickey.css“ contractor.pubin ein administratives Staging-Verzeichnis:

sudo install -d -o root -g root -m 0755 /etc/ssh/authorized_keys
sudo install -o root -g root -m 0644 contractor.pub /etc/ssh/authorized_keys/contractor
sudo /usr/sbin/sshd -t

Kopieren Sie keinen privaten Schlüssel auf den Server. Die Einstellungen für den Schlüsselpfad, die Standardeinstellungen für die Authentifizierung und die Kontoprüfungen hängen von Ihrer bestehenden SSH-Richtlinie ab; überprüfen Sie den Zugriff mit dem öffentlichen Schlüssel, bevor Sie eine bereits funktionierende Authentifizierungsmethode deaktivieren.

Häufige Fehler und ihre Bedeutung

Überprüfen Sie die Protokolle sudo journalctl -u ssh -n 80 --no-pager. Der genaue Fehler hängt von den PAM-Einstellungen, der SSH-Konfiguration, dem Dateisystemzugriff und der Authentifizierungsmethode ab. OpenSSH 9.0 und neuer verwenden scpstandardmäßig SFTP für Standardübertragungen, während der Legacy-Modus eine Shell erfordert, wie im Ubuntu 24.04 scp-Handbuch beschrieben .

Kann man eine interaktive SSH-Shell auf einen einzigen Ordner beschränken?

Nicht mit einer Änderung des Home-Verzeichnisses oder dem oben genannten Beispiel mit reinem SFTP. OpenSSH ChrootDirectorykann zwar auch für Shell-Sitzungen verwendet werden, die Jail muss jedoch eine nutzbare Shell, die zugehörigen Bibliotheken, die benötigten Geräteknoten und alle Befehlsabhängigkeiten enthalten. Für eine sichere Einrichtung dieser Umgebung reicht es nicht aus, nur eine Zeile in der Konfigurationsdatei festzulegen sshd_config. Es ist leicht, eine instabile oder irreführende Konfiguration zu erstellen, insbesondere wenn beliebige Shell-Befehle oder Mounts verwendet werden.

Benötigt ein Benutzer interaktive Befehle, muss zunächst genau festgelegt werden, welche Befehle und Dateien er benötigt. Für einen kleinen Befehlssatz empfiehlt sich die Verwendung von eng definierten Remote-Befehlen oder eines dedizierten Anwendungsendpunkts. Für größere, unabhängige Umgebungen ist ein Container oder eine virtuelle Maschine mit expliziten Dateisystem-Mounts, Berechtigungssteuerung und Netzwerkbeschränkungen ratsam. Ein Chroot allein ersetzt keine vollständige Systemisolation, und weder Chroot noch Unix-Dateiberechtigungen schützen vor einem privilegierten Benutzer, der das zugrundeliegende System verändern kann.

Sicherheitscheckliste vor der Zugriffsgewährung

• Das Transferkonto ist kein Administratorkonto und gehört nur zu den erforderlichen Gruppen.
• Jede Komponente, die zum Gefängnis führt, ist im Besitz des Root-Benutzers und kann weder von der Gruppe noch von der gesamten Benutzeroberfläche beschrieben werden.
• Der beschreibbare Upload-Speicherort befindet sich innerhalb des Jails, nicht im Jail-Root-Verzeichnis selbst.
• Der vorgesehene Benutzer stimmt überein ChrootDirectory, ForceCommand internal-sftpund die Weiterleitung wurde in der effektiven Konfiguration deaktiviert.
• Ein SFTP-Upload gelingt, der Versuch, auf schreibgeschützte Dateien zuzugreifen, schlägt fehl, und der normale SSH-Shell-Zugriff wird blockiert.
• Datensicherung, Aufbewahrung, Quoten, Überwachung und Kontosperrung werden separat verwaltet; ein Directory Jail implementiert diese Richtlinien nicht automatisch.

Weitere technische Details finden Sie in der Ubuntu 24.04 OpenSSH-Konfigurationsreferenz und im Ubuntu SFTP-Serverhandbuch . Diese Anleitung bezieht sich auf Ubuntu 24.04 LTS; Paketkompilationen und vorhandene SSH-Snippets können das Verhalten verändern. Maßgeblich sind daher die Konfiguration und tatsächliche Verbindungstests auf Ihrem eigenen Rechner.