Jak ograniczyć dostęp użytkowników SSH do określonych katalogów w systemie Ubuntu 24.04 (przewodnik po SFTP Chroot)

Udzielenie użytkownikowi dostępu do przesłania kilku plików nie powinno automatycznie dawać mu sesji terminala z widokiem na cały serwer. W Ubuntu 24.04 LTS OpenSSH może ograniczyć konto transferu plików do wybranego katalogu za pomocą reguły ChrootDirectoryi wbudowanego internal-sftpserwera. Istotną różnicą jest to, że jest to ograniczenie wyłącznie do SFTP , a nie prosty sposób na zapewnienie w pełni funkcjonalnej, ale zablokowanej powłoki Bash.

W tym przewodniku wyjaśniono, co tak naprawdę chronią te ustawienia, a następnie przedstawiono odwracalną, ośmioetapową konfigurację wielu kont, z których każde ma swój własny katalog. Polecenia używają przykładowego konta o nazwie contractori przykładowego hosta o nazwie server.example.com; zastąp je własnymi wartościami. Są to przykłady konfiguracji, a nie deklarowane wyniki testów na serwerze rzeczywistym.

Jakiego rodzaju ograniczenia faktycznie potrzebujesz?

Trzy kontrolki są często mylone. Uprawnienia w systemie Linux decydują, które pliki konto może odczytywać lub modyfikować; zmiana katalogu domowego konta ustawia początkową lokalizację; chroot zmienia katalog główny systemu plików prezentowany procesowi. Nie są one zamienne.

Błędne przekonanie: ustawienie /home/contractorkatalogu domowego ogranicza użytkownika do niego. Tak nie jest. Zwykły użytkownik powłoki może przenieść się do dowolnego dostępnego katalogu w innym miejscu systemu plików. Jeśli wymiana plików jest rzeczywistym wymaganiem, wybierz opcję „tylko SFTP” poniżej, zamiast próbować ukrywać katalogi za pomocą wiersza poleceń powłoki.

Dokumenty OpenSSH ChrootDirectory, Matchoraz ForceCommandoficjalny podręcznik sshd_config Ubuntu 24.04 .

Skonfiguruj katalog więzienny wyłącznie dla protokołu SFTP w ośmiu etapach

Przed zdalną modyfikacją SSH, utrzymuj otwartą sesję administratora i upewnij się, że masz dostęp do konsoli lub odzyskiwania. Do transferów używaj osobnego konta bez uprawnień; nie umieszczaj konta administratora w grupie z ograniczeniami.

1. Zweryfikuj OpenSSH i utwórz sesję odzyskiwania

Zainstaluj OpenSSH na serwerze, jeśli to konieczne, sprawdź usługę i zapisz główną konfigurację. Oficjalna dokumentacja serwera Ubuntu obsługuje te ścieżki usług i konfiguracji.

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

Jeśli możesz administrować maszyną tylko przez SSH, nie zamykaj bieżącej sesji podczas edycji lub testowania. Przed zmianą demona zapoznaj się z instrukcją konfiguracji serwera Ubuntu OpenSSH .

2. Utwórz dedykowaną grupę użytkowników i dostępu SFTP

Grupa jest przydatna, gdy spodziewasz się więcej niż jednego konta z ograniczeniami. W tym przykładzie każdemu członkowi przydzielane jest osobne więzienie (areszt) za pomocą %utokena, który OpenSSH rozszerza do nazwy użytkownika łączącego. /uploadŚcieżka domowa ma znajdować się w przyszłym chroot, więc nie twórz katalogu na poziomie hosta /upload.

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

Przepływ addusermoże wymagać podania hasła. W instalacjach, które wyłączają uwierzytelnianie hasłem SSH, należy zamiast tego utworzyć i autoryzować klucz publiczny; nie należy włączać globalnie logowania hasłem tylko po to, by naśladować przykład. Powłoka nologinstanowi kolejne zabezpieczenie, ale wymuszone internal-sftppolecenie sprawia, że ​​ta konfiguracja jest dostępna tylko do transferu. Przetestuj tę kombinację na własnym stosie uwierzytelniania.

3. Utwórz katalog chroot należący do użytkownika root

W tym miejscu wiele poradników popełnia błąd. OpenSSH wymaga, aby każdy komponent ścieżki chroot należał do użytkownika root i nie był dostępny do zapisu dla innych użytkowników ani grup. Nigdy nie ustawiaj dostępu do samego katalogu jail root jako dostępnego do zapisu dla konta SFTP.

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

Sprawdź również istniejące komponenty /i /srv; powyższe polecenia nie naprawiają automatycznie niebezpiecznych uprawnień nadrzędnych. Jeśli któryś z komponentów ma uprawnienia do zapisu dla grupy lub jest własnością użytkownika, popraw jego własność i tryb dopiero po sprawdzeniu, czy inne aplikacje z niego korzystają.

4. Dodaj zapisywalny podkatalog wewnątrz więzienia

Konto może zapisywać do katalogu podrzędnego bez możliwości zmiany katalogu głównego chroot. Utwórz /srv/sftp/contractor/uploaddla rzeczywistych plików konta; z poziomu SFTP będzie to widoczne jako /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

Oczekiwane prawa własności różnią się celowo: root:rootdla katalogu głównego więzienia i contractor:contractordla folderu do przesyłania z możliwością zapisu. Należy unikać chmod 777, ponieważ wprowadzałoby to niepotrzebne zagrożenie i zostałoby odrzucone, gdyby zostało zastosowane do katalogu głównego więzienia.

5. Dodaj regułę dopasowania do sshd_config

Otwórz /etc/ssh/sshd_configi dołącz poniższy blok na końcu, po istniejących dyrektywach i Matchblokach. Użyj edytora tekstu, takiego jak sudoeditlub sudo nano. MatchNajpierw przejrzyj istniejące reguły: jeśli kilka pasujących bloków przypisze to samo słowo kluczowe, OpenSSH użyje pierwszej odpowiedniej instancji. Ubuntu przetwarza również pliki /etc/ssh/sshd_config.d/z wcześniejszej wersji Include; reguły mogą wpływać na pierwszeństwo.

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

Match Groupjest skierowany do członków sftpclients. ChrootDirectoryumieszcza każdego użytkownika w /srv/sftp/USERNAME. ForceCommand internal-sftp -d /uploaduruchamia usługę SFTP w trakcie procesu i rozpoczyna działanie w katalogu, w którym można zapisywać. PermitTTY nozapobiega przydzielaniu terminala, jednocześnie DisableForwarding yeswyłączając funkcje przekazywania SSH dla dopasowanych połączeń.

Zachowaj globalną Subsystem sftpdyrektywę już dostarczoną przez Ubuntu, chyba że masz inny powód, aby ją zmienić; wymuszone wewnętrzne polecenie SFTP nie wymaga zastępowania tego globalnego wiersza. Nie dodawaj dodatkowej globalnej dyrektywy Match Alltylko po to, aby zakończyć blok, nie rozumiejąc, jaki to będzie miało wpływ.

6. Przed ponownym załadowaniem sprawdź składnię i obowiązujące ustawienia

Pomyślne przeprowadzenie analizy nie dowodzi poprawności uprawnień ani zgodności konta z polityką. Należy wykonać oba sprawdzenia jawnie.

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

Efektywna konfiguracja powinna określać docelową ścieżkę chroot, wymuszoną komendę SFTP, wyłączoną alokację TTY oraz ograniczenia przekierowywania. Przykładowy adres 192.0.2.10ma charakter wyłącznie dokumentacyjny; jeśli masz Matchreguły zależne od adresu, zastąp go rzeczywistym adresem źródłowym klienta. Formularz -T -Cjest udokumentowany w podręczniku sshd Ubuntu 24.04 .

Jeśli walidacja się nie powiedzie, popraw konfigurację przed ponownym załadowaniem SSH. Jeśli wartości efektywne są nieoczekiwane, sprawdź dołączone fragmenty kodu i kolejność istniejących bloków warunkowych, a nie tylko ostatnie edytowane wiersze.

7. Ponownie załaduj SSH i zachowaj dostęp administratora

Po pomyślnym sprawdzeniu przeładuj usługę SSH, aby nowe połączenia korzystały ze zmodyfikowanej polityki. Utrzymuj aktywne połączenie administratora, otwierając jednocześnie drugi terminal, aby upewnić się, że normalny dostęp administratora nadal działa.

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

Pełny restart może również wprowadzić zmiany, ale ponowne załadowanie jest preferowane, jeśli jest obsługiwane i chcesz uniknąć niepotrzebnych przerw. Dane wyjściowe polecenia usługi i komunikaty dziennika różnią się w zależności od hosta, dlatego należy sprawdzić rzeczywisty wynik, zamiast zakładać, że pomyślny powrót do wiersza poleceń gwarantuje dostęp.

8. Test zezwalający na transfery i blokujący dostęp do powłoki

Z innego komputera połącz się jako użytkownik z ograniczonym dostępem. Użyj rzeczywistej nazwy hosta serwera i odpowiedniego pliku testowego. Pierwszy katalog SFTP powinien mieć nazwę /upload, a katalog główny chroot powinien być wyświetlany jako , /a nie ścieżka hosta /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

Przesyłanie nieszkodliwego pliku testowego powinno być dozwolone w /upload. Dostęp do rzeczywistego katalogu hosta /etcnie powinien być możliwy: chroot definiuje inny katalog główny i /etcbyłby dostępny tylko wtedy, gdybyś celowo utworzył lub udostępnił taki katalog w jailu. Dokładny tekst błędu klienta nie ma znaczenia.

ssh contractor@server.example.com

Dla tego konta nie wolno otwierać zwykłej interaktywnej powłoki SSH. Zamiast tego połączenie może zostać zamknięte lub wyświetlony zostanie komunikat dotyczący protokołu; nie należy polegać na dokładnej frazie. Jeśli powłoka zostanie otwarta, należy traktować konfigurację jako niebezpieczną i ponownie sprawdzić członkostwo w grupie, Matchpriorytet i efektywne sshd -T -Cdane wyjściowe przed użyciem konta.

A co jeśli użyjesz kluczy publicznych SSH?

Uwierzytelnianie za pomocą klucza publicznego działa w przypadku aresztu SFTP, ale umieszczenie adresu domowego użytkownika na poziomie hosta /uploadoznacza, że ​​domyślna ~/.ssh/authorized_keysścieżka może nie istnieć poza aresztem. Praktyczną alternatywą jest umożliwienie protokołowi SSH odczytania pliku klucza kontrolowanego przez użytkownika root przed uruchomieniem chroot. Dodaj to w tym samym Match Group sftpclientsbloku, jeśli wybierzesz scentralizowane przechowywanie kluczy:

    AuthorizedKeysFile /etc/ssh/authorized_keys/%u

Następnie utwórz plik /etc/ssh/authorized_keys/contractorzawierający autoryzowany klucz publiczny kontrahenta, z uprawnieniami roota i bez uprawnień zapisu dla grupy lub całego świata. Na przykład, po bezpiecznym skopiowaniu sprawdzonego pliku klucza publicznego contractor.pubdo administracyjnego katalogu tymczasowego:

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

Nie kopiuj klucza prywatnego na serwer. Ustawienia ścieżki klucza, domyślne ustawienia uwierzytelniania i weryfikacja konta zależą od istniejącej polityki SSH. Przed wyłączeniem działającej metody uwierzytelniania zweryfikuj dostęp do klucza publicznego.

Typowe awarie i ich znaczenie

Sprawdź logi za pomocą sudo journalctl -u ssh -n 80 --no-pager. Dokładny błąd zależy od ustawień PAM, konfiguracji SSH, dostępu do systemu plików i metody uwierzytelniania. OpenSSH 9.0 i nowsze wersje scpdomyślnie używają SFTP do standardowych transferów, natomiast tryb legacy wymaga powłoki, jak wyjaśniono w podręczniku SCP w Ubuntu 24.04 .

Czy można ograniczyć interaktywną powłokę SSH do jednego folderu?

Nie ze zmianą katalogu domowego ani z powyższym przykładem tylko SFTP. OpenSSH ChrootDirectorymożna również używać do sesji powłoki, ale jail musi zawierać użyteczną powłokę, biblioteki współdzielone i wymagane węzły urządzeń oraz wszelkie zależności poleceń. Bezpieczne zbudowanie takiego środowiska wymaga więcej niż jednej linii w pliku sshd_config. Łatwo jest stworzyć niestabilną lub mylącą konfigurację, zwłaszcza gdy w grę wchodzą dowolne polecenia powłoki lub montowania.

Jeśli użytkownik naprawdę potrzebuje interaktywnych poleceń, należy najpierw dokładnie określić, jakich poleceń i plików potrzebuje. W przypadku niewielkiego zestawu poleceń należy używać wąskozakresowych poleceń zdalnych lub dedykowanego punktu końcowego aplikacji. W przypadku szerszych, niezależnych środowisk należy rozważyć kontener lub maszynę wirtualną z jawnymi montowaniami systemów plików, kontrolą uprawnień i ograniczeniami sieciowymi. Sam chroot nie zastępuje pełnej izolacji systemu, a ani chroot, ani uprawnienia do plików w systemie Unix nie chronią przed uprzywilejowanym użytkownikiem, który może zmieniać system.

Lista kontrolna bezpieczeństwa przed udzieleniem dostępu

• Konto transferowe nie jest kontem administratora i należy tylko do niezbędnych grup.
• Każdy komponent prowadzący do więzienia jest własnością użytkownika root i nie jest dostępny do zapisu dla grupy lub świata.
• Miejscem zapisu do przesłania danych jest więzienie, a nie sam katalog główny więzienia.
• Docelowy użytkownik pasuje do ChrootDirectory, ForceCommand internal-sftpi wyłączył przekazywanie w efektywnej konfiguracji.
• Prawdziwe przesłanie za pomocą protokołu SFTP kończy się powodzeniem, próba dotarcia do plików dostępnych tylko dla hosta kończy się niepowodzeniem, a normalny dostęp do powłoki SSH zostaje zablokowany.
• Kopie zapasowe, przechowywanie, limity, monitorowanie i unieważnianie kont są zarządzane osobno; więzienie katalogu nie wdraża tych zasad automatycznie.

Aby uzyskać więcej szczegółów technicznych, zapoznaj się z dokumentacją konfiguracji OpenSSH w Ubuntu 24.04 oraz podręcznikiem serwera SFTP w Ubuntu . Instrukcje te dotyczą Ubuntu 24.04 LTS; kompilacje pakietów i istniejące fragmenty kodu SSH mogą zmienić efektywne działanie, dlatego ostateczną miarą jest konfiguracja i rzeczywiste testy połączenia na własnym hoście.