zła własność lub tryby komponentu katalogu chroot

Utworzyłem użytkownika MY_USER. Ustaw jego katalog domowy na / var / www / RESTRICTED_DIR, do której powinien być ograniczony. Następnie edytowałem sshd_config i ustawiłem:

Match user MY_USER
  ChrootDirectory /var/www/RESTRICTED_DIR

Potem zrestartowałem ssh. Sprawiłem, że MY_USER był właścicielem (i właścicielem grupy) RESTRICTED_DIR, i chmodded go do 755. Dostaję

Accepted password for MY_USER
session opened for user MY_USER by (uid=0)
fatal: bad ownership or modes for chroot directory component "/var/www/RESTRICTED_DIR"
pam_unix(sshd:session): session closed for user MY_USER

Jeśli usunę 2 linie z sshd_config, użytkownik może się zalogować. Oczywiście może jednak uzyskać dostęp do całego serwera. Jaki jest problem? Próbowałem nawet zmienić RESTRICTED_DIR na rootowanie (czytając gdzieś, że ktoś rozwiązał ten sam problem, robiąc to). Brak szczęścia..

ssh chown chroot

— Wielopostaciowe
źródło

Odpowiedzi:

Od tej manstrony :

ChrootDirectory
Określa nazwę ścieżki katalogu do chroot (2) po uwierzytelnieniu. Wszystkie składniki nazwy ścieżki muszą być katalogami będącymi własnością administratora, których nie można zapisać przez żadnego innego użytkownika lub grupę . Po chroot sshd (8) zmienia katalog roboczy na katalog osobisty użytkownika.

Domyślam się, że jeden lub więcej katalogów na ścieżce nie spełnia tych wymagań (moje podejrzenie wwwjest własnością lub zapisywalne przez użytkownika sieci, a nie roota).
Wróć i postępuj zgodnie ze wskazówkami, upewniając się, że zostały spełnione powyższe wymagania pogrubioną kursywą .

— voretaq7
źródło

Doprowadza mnie to do szału. Zrobiłem „chown root: root -R / var / www”; „chmod 775 -R / var / www /”; „usermod -a -G root www-data”. Ale nadal nie mogę się zalogować za pomocą MY_USER

— MultiformeIngegno

Wymóg jest na komponentach ścieżki ( /, /var, /var/www, i /var/www/RESTRICTED_DIRwszystkie muszą spełniać wymogi bezpieczeństwa wyżej). To jest prawdziwy chroot ( przejrzyj stronę podręcznika) - katalog domowy użytkownika musi istnieć w chroot , podobnie jak /binwszystkie inne rzeczy, których użytkownik będzie potrzebował ...

— voretaq7

Dobrze! Rozwiązany. Ustawiłem chrootowany katalog na wyższy poziom. Następnie dałem 777 perms oryginalnemu katalogowi chrooted_dir. Działa :)

— MultiformeIngegno

Pomimo tego, co mówi strona podręcznika, a nawet z grupą ustawioną na „root”, musiałem ustawić uprawnienia gw, zanim to zadziała (Ubuntu 14.04). Strona powinna powiedzieć, że wszystkie komponenty nazwy ścieżki muszą być katalogami będącymi własnością root, które nie mogą być zapisywane przez żadnego innego użytkownika lub grupę sudo chown root:root -R /path/to/home; sudo chmod 755 -R /path/to/home

— mmell 15.01.2015

Wiem, że jest to dość stare, ale zamiast modyfikować uprawnienia do /var/wwwścieżki bezpośrednio, co może zepsuć apache, znacznie lepiej byłoby umieścić katalog sftp w innej ścieżce, niż użyć mapowania URL w Apache, aby wskazać inny katalog . Sprawdź dokumentację tutaj httpd.apache.org/docs/2.4/urlmapping.html podFiles Outside DocumentRoot

— Daniel

Katalog ChrootDirectory musi być własnością root i mieć tryb 755:

sudo chown root:root /var/www/RESTRICTED_DIR
sudo chmod 755 /var/www/RESTRICTED_DIR

Ok, teraz wszystkie pliki do /var/www/RESTRICTED_DIRmuszą MY_USERnależeć do www-datagrupy, która musi należeć do grupy i mieć tryb 775, aby zezwolić na uprawnienia grupy, takie jak to:

sudo usermod -a -G www-data MY_USER
sudo chown MY_USER:www-data /var/www/RESTRICTED_DIR/*
sudo chmod 775 -R /var/www/RESTRICTED_DIR/*

UWAGA: Pamiętaj, że dobrą praktyką jest dostęp tylko do folderu htdocs, jeśli konfigurujesz apache.

— JG.
źródło

Całkiem pewnie powinno być sudo usermod -a -G www-data MY_USERtak, jak grupa powinna przyjść później-G

— sMyles

To działa, ale nie mogę przesyłać nowych plików do katalogu, mogę jedynie modyfikować pliki utworzone wcześniej przy użyciu konta root i własności użytkownika.

— dlopezgonzalez

Po dzisiejszym rozwiązywaniu problemów zdałem sobie sprawę, że root musi mieć także możliwość zapisu do katalogów.

Następujące nie działało:

$ ls -ld /mnt/synology03/files/
dr-xr-xr-x 1 root root 156 Oct  8 20:10 /mnt/synology03/files/
$ ls -ld /mnt/synology03
drwxr-xr-x 7 root root 4096 Oct  1 21:26 /mnt/synology03
$ ls -ld /mnt
drwxr-xr-x 6 root root 4096 Feb  8 10:01 /mnt
$ ls -ld /
drwxr-xr-x 24 root root 4096 Jan 14 09:22 /

Gdy tylko to naprawiłem, mój chroot zaczął działać.

$ sudo chmod 755 /mnt/synology03/files/
$ ls -ld /mnt/synology03/files/
drwxr-xr-x 1 root root 156 Oct  8 20:10 /mnt/synology03/files/

— Magnus
źródło