Wie man SSH-Benutzer in Ubuntu 24.04 auf bestimmte Verzeichnisse beschränkt

Die sicherste Methode, SSH-Benutzer unter Ubuntu 24.04 auf ein bestimmtes Verzeichnis zu beschränken, ist die Verwendung von OpenSSH ChrootDirectorymit der Option `--sfp` ForceCommand internal-sftp. Dies ist ideal, wenn das Konto ausschließlich Dateiübertragungen benötigt. Es ermöglicht dem Benutzer eine SFTP-Ansicht, deren Dateisystem-Root das von Ihnen gewählte Verzeichnis ist, während interaktive Shell-Zugriffe und SSH-Weiterleitung blockiert werden.

Benötigt der Benutzer tatsächlich eine normale Shell, sieht die Sache anders aus. Eine interaktive Shell in einer Chroot-Umgebung benötigt eine eigene Shell-Binärdatei, Bibliotheken, Geräteknoten und zugehörige Dateien innerhalb der Chroot-Umgebung. OpenSSH dokumentiert dies explizit. Für die meisten Upload-, Backup-, Agentur-, Anbieter- und Shared-Hosting-Konten ist eine reine SFTP-Chroot-Umgebung deutlich einfacher und weniger fehleranfällig. Für nicht vertrauenswürdige Benutzer, die eine vollständige Befehlsumgebung benötigen, ist ein Container oder eine dedizierte VM in der Regel einfacher zu verwalten als die manuelle Erstellung einer Shell-Chroot-Umgebung.

Diese Anleitung verwendet Ubuntu 24.04 LTS und einen Beispielbenutzer namens „<Benutzername>“ alice. Der Benutzer ist auf das Verzeichnis „<Verzeichnis>“ beschränkt /srv/sftp/aliceund darf nur innerhalb dieses Verzeichnisses schreiben /files. Passen Sie die Namen und Pfade an die Gegebenheiten Ihres Servers an.

Bevor Sie beginnen: Verstehen Sie die Eigentumsregeln.

Der häufigste Fehler bei der Verwendung von chroot wird durch fehlende Berechtigungen verursacht. OpenSSH verlangt, dass alle Komponenten des ChrootDirectoryPfades dem Benutzer root gehören und weder von der Gruppe noch von anderen Benutzern beschreibbar sind . Diese Anforderung wird bedingungslos geprüft. Das bedeutet, dass Sie die Pfade nicht /srv/sftp/alicefür root beschreibbar machen sollten alice.

Stattdessen sollte das Jail-Root-Verzeichnis dem Root-Verzeichnis zugeordnet und ein beschreibbares Unterverzeichnis erstellt werden:

/srv/sftp/alice        root:root   755
└── files              alice:alice 755

Dieses Design entspricht dem im Ubuntu 24.04- sshd_config(5)Handbuch dokumentierten Verhalten . Im selben Handbuch wird darauf hingewiesen, dass internal-sftpkeine zusätzlichen Laufzeitdateien innerhalb des Chroot-Verzeichnisses benötigt werden, weshalb es sich am besten für ein Konto mit eingeschränktem Dateitransfer eignet.

Schritt 1: Überprüfen Sie, ob der OpenSSH-Server installiert ist.

Installieren Sie gegebenenfalls das Serverpaket:

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh.service

Die offizielle OpenSSH-Dokumentation von Ubuntu verwendet openssh-serverdas Daemon-Paket und ssh.servicedie Dienstverwaltung. Siehe den Ubuntu Server OpenSSH-Leitfaden .

Wenn es sich um einen entfernten Rechner handelt und SSH Ihr einziger administrativer Zugang ist, lassen Sie Ihre bestehende Administrator-Sitzung während der Änderungen geöffnet. Eine fehlerhafte SSH-Konfiguration kann Sie aussperren.

Schritt 2: Erstellen Sie eine Gruppe und fügen Sie den eingeschränkten Benutzer hinzu.

Erstellen Sie eine Gruppe für eingeschränkte Benutzer. Falls alicebereits eine solche Gruppe existiert, fügen Sie die betreffende Person nur dieser Gruppe hinzu.

sudo groupadd sftpusers
sudo adduser alice
sudo usermod -aG sftpusers alice
id alice

Wenn Sie bereits SSH-Schlüssel verwenden, können Sie dies weiterhin tun. Die Chroot-Konfiguration steuert das Verhalten nach der Authentifizierung ; ein Wechsel von Schlüssel- zu Passwortauthentifizierung ist nicht erforderlich.

Eine gruppenbasierte Regel ist in der Regel besser als eine separate Match UserSperre für jedes Konto. Dadurch bleiben die Richtlinien an einem Ort. Eine benutzerbezogene Regel ist weiterhin sinnvoll, wenn verschiedene Benutzer auf unterschiedliche Layouts beschränkt werden müssen.

Schritt 3: Erstellen Sie ein Jail mit Root-Rechten und ein beschreibbares Unterverzeichnis

Erstellen Sie die Verzeichnishierarchie:

sudo mkdir -p /srv/sftp/alice/files
sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files
sudo chmod 755 /srv/sftp/alice/files

Eigentumsverhältnisse prüfen:

ls -ld /srv /srv/sftp /srv/sftp/alice /srv/sftp/alice/files
namei -l /srv/sftp/alice

Falls /srvdie /srv/sftpDatei für Gruppen oder Benutzer beschreibbar ist, muss dies ebenfalls korrigiert werden. OpenSSH prüft alle Pfadbestandteile, nicht nur das Endverzeichnis.

Schritt 4: Fügen Sie eine Match-Regel in sshd_config.d hinzu.

Die aktuelle Serverdokumentation von Ubuntu empfiehlt, benutzerdefinierte SSH-Einstellungen separat zu speichern, /etc/ssh/sshd_config.d/anstatt sie in die Hauptdatei des Pakets einzubinden. Erstellen Sie einen Codeausschnitt:

sudo nano /etc/ssh/sshd_config.d/90-sftp-restricted.conf

Hinzufügen:

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

Match all

%uwird zum authentifizierten Benutzernamen erweitert und alicebefindet sich daher in /srv/sftp/alice. Das -d /filesArgument weist den internen SFTP-Server an, im beschreibbaren Unterverzeichnis zu starten. DisableForwarding yesdeaktiviert X11-, Agent-, TCP- und StreamLocal-Weiterleitung mit einer einzigen Direktive; sie ist speziell zur Vereinfachung eingeschränkter Konfigurationen dokumentiert.

Das letzte Konstrukt Match allist in einem Code-Snippet wichtig, da es den bedingten Kontext beendet, bevor die spätere Konfiguration analysiert wird.

Schritt 5: Entscheiden Sie sich zwischen gruppenbasierten und benutzerbezogenen Beschränkungen.

Bei mehreren Benutzern mit demselben Layout behalten Sie die oben gezeigte Gruppenregel bei. Verwenden Sie für ein einzelnes Ausnahmekonto stattdessen einen benutzerspezifischen Block:

Match User vendor1
    ChrootDirectory /srv/vendor/vendor1
    ForceCommand internal-sftp -d /incoming
    DisableForwarding yes
    PermitTTY no

Match all

Die Auswahl erfolgt anhand der Verwaltungskosten:

Schritt 6: Überprüfen Sie die SSH-Konfiguration vor dem Neustart.

Starten Sie SSH niemals unmittelbar nach der Bearbeitung der Datei neu. Führen Sie zuerst den von Ubuntu empfohlenen Syntaxtest durch:

sudo sshd -t

Keine Ausgabe bedeutet, dass die Syntaxprüfung erfolgreich war. Sie können auch die effektive Konfiguration für einen bestimmten Benutzer überprüfen:

sudo sshd -T -C user=alice,host=localhost,addr=127.0.0.1   | grep -E 'chrootdirectory|forcecommand|disableforwarding|permittty'

Sie sollten den erwarteten chroot-Pfad und den erzwungenen SFTP-Befehl sehen. Dies ist besonders unter Ubuntu hilfreich, da die Einstellungen sowohl aus Dateien im Verzeichnis `/etc/chroot` /etc/ssh/sshd_configals auch aus Dateien unter `/etc/ chroot` stammen können /etc/ssh/sshd_config.d/. Ubuntu weist darauf hin, dass OpenSSH im Allgemeinen den ersten ermittelten Wert für die meisten Direktiven verwendet. Daher ist es sicherer, die effektive Konfiguration zu überprüfen, als anzunehmen, welche Datei Vorrang hat.

Schritt 7: SSH neu starten und mit SFTP testen.

Die Änderung anwenden:

sudo systemctl restart ssh.service
sudo systemctl status ssh.service

Stellen Sie dann von einem anderen Terminal aus eine Verbindung her:

sftp alice@server.example.com

Innerhalb von SFTP testen:

pwd
ls
put test.txt
ls -l

Bei der obigen Konfiguration sollte das anfängliche SFTP-Verzeichnis /files. lauten. Der von SFTP angezeigte Schrägstrich ist das Stammverzeichnis des Chroot-Verzeichnisses, nicht das eigentliche Server-Stammverzeichnis.

Ein normaler Shell-Versuch sollte keine uneingeschränkte Shell erzeugen:

ssh alice@server.example.com

Da ForceCommand internal-sftpdie angeforderte Sitzung durch den im Prozess laufenden SFTP-Server ersetzt wird, ist dieses Konto absichtlich für die Dateiübertragung und nicht für die Befehlsausführung vorgesehen.

Schritt 8: Sicherstellen, dass der Benutzer nicht aus dem Gefängnis entkommen kann.

Versuchen Sie, sich über den scheinbaren Stammordner hinaus zu bewegen und sensible Hostpfade zu untersuchen:

cd ..
ls /
ls /etc
ls /root

Innerhalb des Chroot-Verzeichnisses wird das Verzeichnis auf dem Host /repräsentiert /srv/sftp/alice. Wenn Sie innerhalb dieses Jails kein Verzeichnis erstellt haben etc, kann der Benutzer nicht auf das reale Verzeichnis oder rootdie tatsächliche Adresse des Hosts zugreifen ./etc/root

Testen Sie auch einen Upload in /files. Eine Konfiguration, die das Entkommen verhindert, aber versehentlich das gesamte Jail schreibgeschützt macht, ist zwar sicher, aber für ein Upload-Konto nicht nützlich.

Fehlerbehebung: „Falsche Besitzrechte oder Zugriffsrechte für das chroot-Verzeichnis“

Falls die Anmeldung sofort fehlschlägt, überprüfen Sie das SSH-Dienstprotokoll:

sudo journalctl -fu ssh.service

Die OpenSSH-Anleitung von Ubuntu empfiehlt das SSH-Dienstjournal zur Fehlerbehebung. Falls ein Besitz- oder Modusfehler auftritt, überprüfen Sie jedes übergeordnete Verzeichnis:

namei -l /srv/sftp/alice

Der Chroot-Pfad muss dem Root-Benutzer gehören und darf weder von der Gruppe noch von anderen Benutzern beschreibbar sein. Ein häufiger Fehler ist folgender:

sudo chown alice:alice /srv/sftp/alice

Das Problem sollte nicht durch Abschwächung der OpenSSH-Prüfungen gelöst werden. Platzieren Sie stattdessen den beschreibbaren Bereich des Benutzers unterhalb des Chroot-Root-Verzeichnisses:

sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files

Was ist, wenn der Benutzer nicht nur SFTP-Zugriff, sondern auch SSH-Shell-Zugriff benötigt?

ChrootDirectoryEs kann auch mit einer interaktiven Shell verwendet werden, die Einrichtung ist jedoch deutlich komplexer. OpenSSH gibt an, dass ein interaktives Chroot mindestens eine Shell und grundlegende /devNodes sowie alle Binärdateien, Bibliotheken, Namensauflösungsdateien und andere Abhängigkeiten benötigt, die von den zugelassenen Befehlen erforderlich sind.

Für ein streng kontrolliertes Appliance-Konto kann der Aufbau einer solchen Jail gerechtfertigt sein. Für den allgemeinen Zugriff auf Linux-Befehle führt dies jedoch häufig zu einem erhöhten Wartungsaufwand: Sicherheitsupdates für Tools und Bibliotheken müssen auch in der Jail berücksichtigt werden. Wenn Ihre eigentliche Anforderung darin besteht, „dieser Person die Ausführung von Befehlen zu ermöglichen, diese aber vom Host zu isolieren“, ist ein Container, eine VM oder ein speziell entwickelter, eingeschränkter Dienst in der Regel einfacher zu überprüfen.

Sicherheitsverbesserungen, die es wert sind, hinzugefügt zu werden

Die Verzeichnisbeschränkung ist nur eine Ebene. Für Server mit Internetzugang sollten Sie außerdem Folgendes berücksichtigen:

• Verwenden Sie nach Möglichkeit die SSH-Public-Key-Authentifizierung für Benutzer- und Automatisierungskonten.
• Gewähren Sie eingeschränkten Benutzern keinen Zugriff auf den Dateitransfer sudo.
• Diese Option ist DisableForwarding yesausschließlich für SFTP-Konten vorgesehen, damit die SSH-Verbindung nicht für Tunnel oder Agentenweiterleitung missbraucht werden kann.
• Beschränken Sie die beschreibbaren Verzeichnisse auf den kleinstmöglichen Bereich, den der Workflow benötigt.
• Überprüfung journalctl -u ssh.serviceund Dateibesitz nach dem Hinzufügen von Benutzern.
• Halten Sie eine Administratorsitzung geöffnet, während Sie Änderungen an der Remote-SSH-Konfiguration testen.

Das genaue Verhalten von ChrootDirectory`<option>`, Match`<option> ForceCommand`, `<option>` und `<option> DisableForwarding` ist im Konfigurationshandbuch des OpenSSH-Servers von Ubuntu 24.04 beschrieben . Informationen zum Ubuntu-spezifischen Konfigurationslayout, zur Validierung, zu Neustartbefehlen und zur Protokollierung finden Sie in der offiziellen Dokumentation des Ubuntu OpenSSH-Servers .

Fazit

Wenn das Ziel lautet: „Dieses SSH-Konto darf Dateien nur innerhalb eines Verzeichnisses hoch- und herunterladen“, verwenden Sie ein Verzeichnis im Besitz des Root-Benutzers ChrootDirectory, platzieren Sie beschreibbare Inhalte in einem Unterverzeichnis im Besitz des Benutzers und erzwingen Sie den Zugriff internal-sftp. Überprüfen Sie dies sshd -tvor dem Neustart und testen Sie anschließend sowohl den zulässigen Upload-Pfad als auch Zugriffsversuche außerhalb des Chroot-Verzeichnisses. Dadurch erhalten Sie eine kleine, verständliche Sicherheitsgrenze, ohne eine vollständige Linux-Umgebung innerhalb des Chroot-Verzeichnisses aufbauen zu müssen.