Konfigurujemy serwer SFTP na Macu (OS X 10.9) część 2/3
W poprzednim odcinku dowiedzieliście się jak w ogóle uruchomić serwer SFTP w OS X. Jest to wręcz trywialne, ale taki dostęp – w domyślnej konfiguracji – ma swoje wady. Najważniejszą z nich jest to, że zdalny użytkownik może w prosty sposób przeglądać zawartość folderów systemowych. Nie może nic usuwać ani dodawać, ale po co w ogóle dawać możliwość wyświetlania zawartości folderów?
Zróbmy taki przykład. Zakładamy nowego użytkownika (Preferencje systemowe > Użytkownicy i grupy), prawym klawiszem myszy wybieramy na nim Opcje zaawansowane…
Mój użytkownik nazywa się „Intruz”. Zmieniłem jego Katalog domowy, podając ścieżkę do folderu Publiczne, przynależącego do mojego konta. Ponadto wybrałem inną Powłokę logowania (domyślnie jest to bash, ja ustawiłem sh – co powinno zawęzić możliwości ew. „grzebactwa” ze strony Intruza). Oczywiście, należy jeszcze uaktywnić opcję Zdalne logowanie w Preferencje systemowe > Udostępnianie jeśli tego wcześniej nie zrobiliśmy i/lub dodać tego nowego użytkownika do grupy użytkowników, posiadających możliwość zdalnego dostępu – o ile nie daliśmy takich uprawnień wszystkim.
Sprawdźmy więc jak wygląda kwestia dostępu z poziomu sftp:
iMadlo:~ marek$ sftp intruz@192.168.1.14
Password:
Connected to 192.168.1.14.
sftp> ls
Drop Box
sftp> pwd
Remote working directory: /Users/marek/Public
sftp>
Jak zauważyliście, połączyłem się w Terminalu jako Intruz do swojego komputera. Po podaniu hasła serwer SFTP autoryzował dostęp. Komendą ls wyświetlam zawartość folderu, natomiast poleceniem pwd weryfikuję ścieżkę do określonego folderu roboczego. Wszystko się zgadza, jest to folder Publiczne, który określiłem w opcjach zaawansowanych użytkownika Intruz.
Niestety mogę śmiało zmienić ścieżkę i zobaczyć np. zawartość folderów systemowych:
sftp> cd /
sftp> ls
(null)-in (null)-out Applications
Incompatible Software Library Network
System Users Volumes
bin cores dev
etc home mach_kernel
net opt private
sbin tmp usr
var
sftp>
Pomimo, że nic tu zrobić w zasadzie nie mogę:
sftp> mkdir /test
Couldn't create directory: Permission denied
sftp>
To i tak nie jest to raczej to czego oczekujemy… Po za tym jeśli zdalny użytkownik będzie korzystać z jakiegoś klienta SFTP to musiałby w konfiguracji tego programu podać dokładną ścieżkę, czyli /Users/marek/Public, by przy każdym połączeniu się w tym folderze znaleźć. Gdy zostawi domyślną, tj. „/”, zobaczy foldery systemowe naszego komputera.
Dlaczego tak się dzieje? Sprawdźcie uprawnienia np. folderu Biblioteki na dysku waszego komputera (skrót: Command+I):
Zauważyliście, że każdy (everyone) posiada uprawnienia odczytu? To domyślne ustawienie w OS X, którego zdecydowałem się nie zmieniać, by nie ryzykować unieruchomienia systemu. Zastanawiałem się też nad utworzeniem grupy „Zdalni” (do ktorej dodałbym Intruza) i zabraniem dostępu tejże grupie, do wszystkich folderów po za Publiczne. Niestety, na obecnym etapie moja pewność w posługiwaniu się Terminalem, oraz zabawie przywilejami nie jest wystarczająca. Nic nie stoi na przeszkodzie, by „terminalowi wyjadacze” spróbowali takich modyfikacji – i podzielili się efektami na naszym blogu :)
Jeśli powyższy rezultat wam wystarczy możecie zakończyć lekturę. Jeśli jednak chcecie dowiedzieć się, jak ograniczyć uprawnienia zdalnego użytkownika wyłącznie do obsługi SFTP, oraz uniemożliwić przeglądanie innych folderów komputera – kontynuujcie!
Rozwiązaniem problemu jest tzw. chroot jail – dzięki któremu zmienimy katalog główny zdalnego użytkownika. Poniżej kroki, które przeprowadziłem:
Utworzyłem użytkownika „eseftep” podobnie jak Intruza, ale nie zmieniałem domyślnych ustawień (Opcje zaawansowane… pozostały nietknięte), dałem nowemu użytkownikowi możliwość zdalnego dostępu, następnie w Terminalu wprowadziłem poniższe:
sudo cp /etc/sshd_config /etc/sshd_config.backup
sudo chown root /
sudo chmod 755 /
sudo mkdir -p /chroot/eseftep/zdalny
sudo chown -R root /chroot/eseftep
sudo chown eseftep /chroot/eseftep/zdalny
sudo chmod -R 755 /chroot/eseftep
Pierwsza linia to zrobienie kopii zapasowej pliku sshd_config, który później zmodyfikuję. Dalej: zmiana właściciela – każdy folder w chroot jail musi należeć do roota, oraz ustalenie uprawnień. Poleceniem mkdir z parametrem -p tworzę kompletne drzewo folderów w katalogu głównym komputera – folder „chroot” zawiera folder o nazwie użytkownika, a ten – folder zwany „zdalny”, do którego będą wrzucane pliki. Dla nowych folderów wymagana jest kolejna zmiana własności oraz uprawnień.
UWAGA: Lepiej nie logować się lokalnie na konto użytkownika zdalnego, tzn. z poziomu systemu/okna logowania, ponieważ zostanie stworzony regularny profil wraz z domyślnymi folderami, tj. Biurko, Dokumenty, Obrazki, itp. Sugeruję ukrycie konta według metody opisanej tutaj.
Czas na modyfikację pliku sshd_config (ja edytowałem w programie TextEdit, ale jeśli znacie edytor tekstowy, jak np. vi, to możecie dokonać zmian bezpośrednio w Terminalu :)).
Najpierw zahaszowałem istniejący wpis:
#Subsystem sftp /usr/libexec/sftp-server
Następnie, na końcu pliku umieściłem poniższe:
Subsystem sftp internal-sftp
Match User eseftep
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
ChrootDirectory /chroot/eseftep
Od teraz, użytkownik eseftep, po zalogowaniu trafia bezpośrednio do folderu eseftep, który jest dla niego katalogiem głównym!
iMadlo:~ marek$ sftp eseftep@192.168.1.14
Password:
Connected to 192.168.1.14.
sftp> pwd
Remote working directory: /
sftp> ls
zdalny
sftp>
Próba zmiany ścieżki nic nie da:
sftp> cd /Users/marek
Couldn't canonicalise: No such file or directory
sftp>
Ponadto, użytkownik eseftep może łączyć się tylko korzystając z protokołu SFTP. Pomimo faktu, że udostępniłem mu dostęp zdalny w panelu preferencji, to połączenie SSH nie będzie zrealizowane pomyślnie:
iMadlo:~ marek$ ssh eseftep@192.168.1.14
ssh eseftep@192.168.1.14
Password:
This service allows sftp connections only.
Connection to 192.168.1.14 closed.
iMadlo:~ marek$
No to najbardziej spektakularna część pracy za nami. Ale to jeszcze nie koniec. Pamiętajmy, że folder zdalnego użytkownika znajduje się w odizolowanym sandboksie, i do niego należą prawa własności do plików oraz uprawnienia zarówno do odczytu jak i zapisu. Oczywiście, jeśli jesteśmy administratorami komputera nie jest to większy problem, wystarczy utworzyć skrót do folderu „zdalny” w wybranym miejscu, w naszym katalogu domowym (np. na biurku) korzystając z Findera, lub utworzyć tzw. dowiązanie symboliczne korzystając z Terminala.
Żeby jednak nie było zbyt różowo, pojawia się kolejny problem: Finder nie odświeża zawartości folderu „zdalny” automatycznie po zakończeniu uploadu pliku. Zachowanie jest dziwne, czasem kilka plików się pojawi w oknie Findera, innym razem nie. Oczywiście gdy wyświetlimy zawartość tego folderu w Terminalu wszystkie pliki będą widoczne. Problemu z odświeżeniem nie ma też np. manager plików ForkLift. Zakładam więc, że jest efekt stanu zaśmiecenia mojego systemu, lub faktycznie Finder w Mavericksie „kuleje” w tej materii…
Postanowiłem wykorzystać rozwiązanie systemowe – Automatora. Zrobiłem w nim megaprosty workflow, którego działanie polega na sprawdzeniu czy w folderze „zdalny” pojawiły się nowe pliki, a następnie skopiowanie ich do folderu „sftp” na biurku.
Skryp wyręcza mnie od sprawdzania zawartości folderu „zdalny”, ponadto operacja kopiowania powoduje, że właścicielem plików z pełnymi do nich prawami zostaję ja. Jeszcze jedno: chwilę po wykonaniu operacji na ekranie pojawia się komunikat o tym, że użytkownik „eseftep” skończył przesyłać do mnie pliki!
W kolejnej – ostatniej – części poświęconej konfugurowaniu serwera SFTP w OS X zajmiemy się tworzeniem grupy zdalnych użytkowników. Do przeczytania wkrótce.
