Chcę dać klientowi dostęp do mojego serwera, ale chcę ograniczyć tych użytkowników do ich katalogów domowych. Zamocuję bind-mount we wszystkich plikach, które chcę, aby były widoczne.

Utworzyłem użytkownika o nazwie bobi dodałem go do nowej grupy o nazwie sftponly. Mają katalog domowy pod adresem /home/bob. Zmieniłem ich powłokę, /bin/falseaby zatrzymać logowanie SSH. Oto ich /etc/passwdlinia:

bob:x:1001:1002::/home/bob:/bin/false

Zmieniłem również /etc/ssh/sshd_confignastępujące elementy:

Match Group sftponly
        ChrootDirectory /home/%u
        ForceCommand internal-sftp
        AllowTcpForwarding no

Kiedy próbuję się zalogować jako oni, oto co widzę

$ sftp bob@server
bob@server's password: 
Write failed: Broken pipe
Couldn't read packet: Connection reset by peer

Jeśli skomentuję ChrootDirectorywiersz, mogę wprowadzić SFTP, ale wtedy będą mogli swobodnie sterować serwerem. Znalazłem, że to ChrootDirectory /homedziała, ale nadal daje im dostęp do dowolnego katalogu domowego. Próbowałem wyraźnie, ChrootDirectory /home/bobale to też nie działa.

Co ja robię źle? W jaki sposób można ograniczyć bobdo /home/bob/?

----EDYTOWAĆ-----

Okej, więc właśnie rzuciłem okiem /var/log/auth.logi zobaczyłem to:

May  9 14:45:48 nj sshd[5074]: pam_unix(sshd:session): session opened for user bob by (uid=0)
May  9 14:45:48 nj sshd[5091]: fatal: bad ownership or modes for chroot directory component "/home/bob/"
May  9 14:45:48 nj sshd[5074]: pam_unix(sshd:session): session closed for user bob

Nie jestem do końca pewien, co się tam dzieje, ale to sugeruje, że coś jest nie tak z katalogiem użytkownika. Oto ls -h /homewynik:

drwxr-xr-x 26 oli      oli      4096 2012-01-19 17:19 oli
drwxr-xr-x  3 bob      bob      4096 2012-05-09 14:11 bob

Cały ten ból jest spowodowany kilkoma problemami bezpieczeństwa opisanymi tutaj . Zasadniczo katalog chroot musi być własnością rooti nie może być dostępem do zapisu grupowego. Śliczny. Więc zasadniczo musisz zmienić chroota w komórkę przechowującą, w której możesz mieć swoją zawartość do edycji.

sudo chown root /home/bob
sudo chmod go-w /home/bob
sudo mkdir /home/bob/writable
sudo chown bob:sftponly /home/bob/writable
sudo chmod ug+rwX /home/bob/writable

I bam, możesz się zalogować i napisać /writable.

Aby chrootować katalog SFTP, musisz

1. Utwórz użytkownika i zmuś root jako jego właściciela

   cd /home
   mkdir john
   useradd -d /home/john -M -N -g users john
   sudo chown root:root /home/john
   sudo chmod 755 /home/john
   

2. Zmień lokalizację podsystemu w / etc / ssh / sshd_config:

   #Subsystem sftp /usr/lib/openssh/sftp-server
   Subsystem sftp internal-sftp
   

   i utwórz sekcję użytkownika na końcu pliku (ssh może umrzeć odradzając się, jeśli zostanie umieszczony po wierszu podsystemu):

   Match User john
       ChrootDirectory /home/john
       ForceCommand internal-sftp
       AllowTCPForwarding no
       X11Forwarding no
   

Cały dzień spędziłem, próbując uzyskać udział sieciowy na mojej malinie. Chciałem zablokować użytkownika, aby nie mógł poruszać się po całym systemie plików, brak dostępu do logowania ssh i chciałem mieć dostęp do zapisu do udziału sieciowego.

Oto jak to działa:

Najpierw stworzyłem użytkownika:

sudo useradd netdrive

Następnie edytowałem /etc/passwdi upewniłem się, że ma to /bin/falsedla użytkownika, więc wiersz był:

netdrive:x:1001:1004:Net Drive User,,,:/home/netdrive:/bin/false

Edytowałem, /etc/ssh/sshd_configaby uwzględnić:

Match User netdrive
  ChrootDirectory /home/netdrive
  ForceCommand internal-sftp
  AllowTcpForwarding no
  X11Forwarding no

Zmieniono właściciela katalogu głównego i uprawnienia:

sudo chown root:root /home/netdrive/
sudo chmod 755 /home/netdrive/

Ok, więc po tym wszystkim udało mi się połączyć za pomocą, sshfsale w trybie tylko do odczytu. Co musiałem zrobić, aby uzyskać zapisywalny folder:

sudo mkdir -p /home/netdrive/home/netdrive/
sudo chown netdrive:netdrive /home/netdrive/home/netdrive/
sudo chmod 755 /home/netdrive/home/netdrive/

To było to, działało bez żadnych dalszych zmian. Pamiętaj, że mam tylko uprawnienia do zapisu dla użytkownika , a nie do grupy tak wielu innych rozwiązań online. Byłem w stanie bez problemu tworzyć / usuwać / edytować / zmieniać nazwy plików / folderów.

Podczas uzyskiwania dostępu za sshfspomocą użytkownika netdrive z powodu konfiguracji chroot widziałbym tylko rzeczy przechowywane w /home/netdrive/katalogu serwera , idealnie. Powtarzająca się /home/netdrive/home/netdrive/struktura katalogów sprawiła, że ​​działało mi się z czystym rozwiązaniem zapisywania ssh w chroot .

Teraz wyjaśnię poniżej problemy, które miałem:

Prawdopodobnie nie powinieneś wykonywać następujących akapitów :

Po zapoznaniu się z powyższymi rozwiązaniami (i wieloma innymi w sieci, które korzystały nawet z acl (listy kontroli dostępu)) nadal nie byłem w stanie uruchomić go, ponieważ to, co zrobiłem, to:

Poniższe NIE działało dla mnie:

sudo mkdir /home/netdrive/writable/
sudo chown netdrive:netdrive /home/netdrive/writable/
sudo chmod 755 /home/netdrive/writable/

Ponieważ użytkownik netdrive nadal nie mógł pisać w tym /home/netdrive/writable/katalogu, mimo że jest właścicielem folderu i ma uprawnienia. Potem zrobiłem: sudo chmod 775 / home / netdrive / writable / A teraz mogłem utworzyć katalog i go usunąć, ale nie byłem w stanie go edytować, ponieważ był tworzony bez uprawnień do zapisu grupowego. Tutaj, z tego, co widziałem w sieci, ludzie używają acldo naprawy. Ale nie byłem z tego zadowolony, ponieważ musiałem zainstalować acl, a następnie skonfigurować punkty montowania itp. Nie mam też pojęcia, dlaczego potrzebuję uprawnień grupy do zapisu w folderze należącym do tego samego użytkownika.

Wygląda na to, że z jakiegoś powodu tworząc /home/netdrive/home/netdrivei oddając własność do ostatniego netdrivefolderu byłem w stanie sprawić, że wszystko zadziała bez bałagania uprawnieniami grupy .

Śledziłem ten artykuł, ale to nie działało. Zaczęło działać po wprowadzeniu tej zmiany (sugerowanej w powyższych odpowiedziach):

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

Plus sprawił, że główny katalog główny jest dostępny, w którym miałem podkatalog do zapisu przez użytkownika (jak opisano powyżej).

Nową i przydatną rzeczą, którą chcę dodać w tej odpowiedzi, jest to, że możesz uprościć konfigurację, określając% h jako katalog domowy użytkownika:

ChrootDirectory %h

Odkryłem to dzięki temu linkowi.