Jak ograniczyć dostęp użytkowników SSH do określonych katalogów w Ubuntu 24.04

Najbezpieczniejszym sposobem ograniczenia dostępu użytkowników SSH do określonego katalogu w Ubuntu 24.04 jest użycie OpenSSH ChrootDirectoryz rozszerzeniem ForceCommand internal-sftp. Jest to idealne rozwiązanie, gdy konto potrzebuje tylko transferu plików. Daje to użytkownikowi widok SFTP, którego katalogiem głównym systemu plików jest wybrany katalog, jednocześnie blokując interaktywną powłokę i przekierowanie SSH.

Jeśli użytkownik rzeczywiście potrzebuje zwykłej powłoki, decyzja jest inna. Interaktywna powłoka chroot wymaga własnych plików binarnych powłoki, bibliotek, węzłów urządzeń i plików pomocniczych w jailu. OpenSSH dokumentuje to wyraźnie. W przypadku większości kont do przesyłania danych, tworzenia kopii zapasowych, agencji, dostawców i hostingu współdzielonego, chroot wyłącznie SFTP jest znacznie prostszy i mniej podatny na błędy. Dla niezaufanych użytkowników, którzy potrzebują pełnego środowiska poleceń, kontener lub dedykowana maszyna wirtualna są zazwyczaj łatwiejsze w utrzymaniu niż ręczne budowanie chroota powłoki.

W tym przewodniku użyto Ubuntu 24.04 LTS i przykładowego użytkownika o nazwie alice. Użytkownik będzie ograniczony do domeny /srv/sftp/alice, a jego uprawnienia do zapisu będą ograniczone tylko do domeny /files. Zmień nazwy i ścieżki, aby dopasować je do swojego serwera.

Zanim zaczniesz: zrozum zasadę własności

Najczęstszy błąd chroot jest spowodowany uprawnieniami. OpenSSH wymaga, aby każdy komponent ścieżki ChrootDirectorybył własnością użytkownika root i nie mógł być zapisywalny przez grupę ani innych użytkowników . To wymaganie jest sprawdzane bezwarunkowo. Oznacza to, że nie należy ustawiać /srv/sftp/aliceprawa zapisu dla użytkownika chroot alice.

Zamiast tego zmień katalog główny więzienia na root-owned i utwórz zapisywalny katalog podrzędny:

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

Ten projekt jest zgodny z zachowaniem opisanym w podręczniku Ubuntu 24.04sshd_config(5) . W tym samym podręczniku zaznaczono, że internal-sftpnie są wymagane żadne dodatkowe pliki uruchomieniowe w chroot, dlatego najlepiej nadaje się on do konta z ograniczonym transferem plików.

Krok 1: Sprawdź, czy serwer OpenSSH jest zainstalowany

Jeśli to konieczne, zainstaluj pakiet serwera:

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

Oficjalna dokumentacja OpenSSH Ubuntu dotyczy openssh-serverpakietu demona i ssh.servicezarządzania usługami. Zobacz przewodnik po OpenSSH dla Ubuntu Server .

Jeśli jest to komputer zdalny, a SSH to Twoja jedyna ścieżka administracyjna, utrzymuj otwartą sesję administratora podczas wprowadzania zmian. Nieprawidłowa konfiguracja SSH może zablokować dostęp.

Krok 2: Utwórz grupę i dodaj użytkownika z ograniczonym dostępem

Utwórz grupę dla użytkowników z ograniczonym dostępem. Jeśli taka alicegrupa już istnieje, dodaj ją tylko do niej:

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

Jeśli korzystasz już z kluczy publicznych SSH, kontynuuj. Konfiguracja chroot kontroluje, co dzieje się po uwierzytelnieniu ; nie wymaga ona przełączania się z uwierzytelniania kluczem na hasła.

Reguła grupowa jest zazwyczaj lepsza niż osobna Match Userblokada dla każdego konta. Pozwala zachować zasady w jednym miejscu. Reguła dla każdego użytkownika jest nadal przydatna, gdy różnych użytkowników trzeba przypisać do niepowiązanych ze sobą układów.

Krok 3: Zbuduj więzienie należące do użytkownika root i podkatalog z możliwością zapisu

Utwórz hierarchię katalogów:

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

Zweryfikuj własność:

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

Jeśli plik /srvlub /srv/sftpjest zapisywalny przez grupę lub użytkownika, popraw to. OpenSSH sprawdza wszystkie składniki ścieżki, a nie tylko katalog końcowy.

Krok 4: Dodaj regułę dopasowania w pliku sshd_config.d

Aktualna dokumentacja serwera Ubuntu zaleca zachowanie niestandardowych ustawień SSH /etc/ssh/sshd_config.d/zamiast wrzucania ich do spakowanego pliku głównego. Utwórz fragment kodu:

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

Dodać:

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

Match all

%urozszerza się do uwierzytelnionej nazwy użytkownika, więc alicejest umieszczany w /srv/sftp/alice. -d /filesArgument nakazuje wewnętrznemu serwerowi SFTP uruchomienie w zapisywalnym katalogu podrzędnym. DisableForwarding yeswyłącza przekazywanie X11, agenta, TCP i StreamLocal w jednej dyrektywie; jest to specjalnie udokumentowane w celu uproszczenia ograniczonych konfiguracji.

Finał Match alljest istotny w fragmencie kodu, ponieważ kończy kontekst warunkowy przed przeanalizowaniem późniejszej konfiguracji.

Krok 5: Wybierz między ograniczeniami grupowymi a ograniczeniami dla poszczególnych użytkowników

W przypadku wielu użytkowników z tym samym układem zachowaj regułę grupową pokazaną powyżej. W przypadku pojedynczego konta wyjątkowego użyj zamiast tego blokady specyficznej dla użytkownika:

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

Match all

Wybierz na podstawie kosztów administracyjnych:

Krok 6: Sprawdź konfigurację SSH przed ponownym uruchomieniem

Nigdy nie restartuj SSH natychmiast po edycji pliku. Najpierw uruchom test składni zalecany przez Ubuntu:

sudo sshd -t

Brak wyniku oznacza, że ​​sprawdzenie składni zakończyło się powodzeniem. Możesz również sprawdzić efektywną konfigurację dla konkretnego użytkownika:

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

Powinieneś zobaczyć oczekiwaną ścieżkę chroot i wymuszoną komendę SFTP. Jest to szczególnie przydatne w Ubuntu, ponieważ ustawienia mogą pochodzić zarówno z /etc/ssh/sshd_configplików /etc/ssh/sshd_config.d/. Ubuntu zauważa, że ​​OpenSSH zazwyczaj używa pierwszej uzyskanej wartości dla większości dyrektyw, więc sprawdzenie efektywnej konfiguracji jest bezpieczniejsze niż zakładanie, który plik wygrywa.

Krok 7: Uruchom ponownie SSH i przetestuj za pomocą SFTP

Zastosuj zmianę:

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

Następnie połącz się z innego terminala:

sftp alice@server.example.com

Wewnątrz SFTP przetestuj:

pwd
ls
put test.txt
ls -l

Przy powyższej konfiguracji początkowy katalog SFTP powinien wyglądać następująco /files: . Ukośnik pokazany przez SFTP to katalog główny chroot, a nie rzeczywisty katalog główny serwera.

Normalna próba utworzenia powłoki nie powinna skutkować utworzeniem powłoki bez ograniczeń:

ssh alice@server.example.com

Ponieważ ForceCommand internal-sftpzastępuje żądaną sesję aktywnym serwerem SFTP, to konto jest przeznaczone do transferu plików, a nie wykonywania poleceń.

Krok 8: Sprawdź, czy użytkownik nie może uciec z więzienia

Spróbuj wyjść ponad widoczny korzeń i zbadać wrażliwe ścieżki hosta:

cd ..
ls /
ls /etc
ls /root

Wewnątrz chroot, /reprezentuje /srv/sftp/alicena hoście. Jeśli utworzyłeś katalog no etclub rootw tym jailu, użytkownik nie będzie mógł uzyskać dostępu do rzeczywistego /etclub /root.

Przetestuj również przesyłanie do /files. Konfiguracja, która blokuje ucieczkę, ale przypadkowo sprawia, że ​​całe więzienie jest tylko do odczytu, jest bezpieczna, ale nieprzydatna dla konta do przesyłania.

Rozwiązywanie problemów: „nieprawidłowy właściciel lub tryby dla katalogu chroot”

Jeśli logowanie natychmiast się nie powiedzie, sprawdź dziennik usługi SSH:

sudo journalctl -fu ssh.service

Przewodnik OpenSSH w Ubuntu zaleca dziennik usług SSH do rozwiązywania problemów. Jeśli pojawi się błąd dotyczący własności lub trybu, sprawdź każdy katalog nadrzędny:

namei -l /srv/sftp/alice

Ścieżka chroot musi być własnością użytkownika root i nie może być zapisywana przez grupę ani innych użytkowników. Częstym błędem jest:

sudo chown alice:alice /srv/sftp/alice

Nie rozwiązuj problemu, osłabiając sprawdzanie OpenSSH. Zamiast tego umieść obszar zapisu użytkownika poniżej katalogu głównego chroot:

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

A co jeśli użytkownik potrzebuje dostępu do powłoki SSH, a nie tylko SFTP?

ChrootDirectoryMożna go również używać z powłoką interaktywną, ale konfiguracja jest znacznie bardziej złożona. OpenSSH stwierdza, że ​​interaktywny chroot wymaga co najmniej powłoki i podstawowych /devwęzłów, a także wszelkich plików binarnych, bibliotek, plików rozpoznawania nazw i innych zależności wymaganych przez dozwolone polecenia.

W przypadku ściśle kontrolowanego konta urządzenia, utworzenie takiego więzienia może być uzasadnione. W przypadku ogólnego dostępu do poleceń systemu Linux, często wiąże się to z obciążeniem konserwacyjnym: aktualizacje zabezpieczeń narzędzi i bibliotek również muszą być uwzględniane w więzieniu. Jeśli Twoim rzeczywistym wymaganiem jest „pozwól tej osobie uruchamiać polecenia, ale odizoluj ją od hosta”, kontener, maszyna wirtualna lub specjalnie zaprojektowana usługa z ograniczeniami zazwyczaj łatwiej jest audytować.

Warto dodać ulepszenia bezpieczeństwa

Ograniczenie katalogów to tylko jedna warstwa. W przypadku serwerów z dostępem do internetu należy również rozważyć:

• Jeśli to możliwe, używaj uwierzytelniania za pomocą klucza publicznego SSH w przypadku kont ludzkich i kont automatyzowanych.
• Nie udzielaj ograniczonych sudopraw dostępu do transferu plików użytkownikom.
• Należy zachować DisableForwarding yeswyłącznie dla kont SFTP, aby połączenie SSH nie mogło zostać wykorzystane do tunelowania lub przekazywania agentów.
• Ogranicz katalogi, w których można zapisywać, do najmniejszego obszaru, jakiego potrzebuje przepływ pracy.
• Przejrzyj journalctl -u ssh.servicei zmień właściciela pliku po dodaniu użytkowników.
• Podczas testowania zmian w konfiguracji protokołu SSH należy utrzymywać otwartą sesję administratora.

Aby uzyskać dokładne informacje o działaniu funkcji ChrootDirectory, Match, ForceCommandi DisableForwarding, skorzystaj z podręcznika konfiguracji serwera OpenSSH Ubuntu 24.04 . Informacje na temat układu konfiguracji, walidacji, poleceń restartu i rejestrowania specyficznego dla Ubuntu znajdują się w oficjalnej dokumentacji serwera OpenSSH Ubuntu .

Podsumowanie

Jeśli celem jest „to konto SSH może przesyłać i pobierać pliki tylko w jednym katalogu”, użyj chroot ChrootDirectory, umieść zapisywalną zawartość w podrzędnym katalogu należącym do użytkownika i wymuś internal-sftp. sshd -tPrzed ponownym uruchomieniem sprawdź poprawność za pomocą , a następnie przetestuj zarówno dozwoloną ścieżkę przesyłania, jak i próbę dostępu poza jail. To daje ci niewielką, zrozumiałą granicę bezpieczeństwa bez konieczności tworzenia kompletnego środowiska Linux w chroot.