Jak dodać użytkownika z dostępem SFTP / FTP do folderu „/ var / www / html / website_abc” w Amazon EC2 Centos?

19

Możliwe duplikaty:
uprawnienia do katalogu Linux

Współpracuję z niektórymi programistami zewnętrznymi i chciałbym przyznać SFTP (lub FTP) dostęp do folderu głównego witryny, nad którą pracują, tj '/var/www/html/website_abc'. Aby mogli tam przesyłać pliki. Pamiętaj, że hostuję tam inne witryny w tej samej instancji EC2, np '/var/www/html/website_xyz'.

Żeby podkreślić, że pracuję z wieloma stronami internetowymi na jednym wystąpieniu EC2, struktura stron jest następująca:

/ var / www / html /
/ var / www / html / website_abc
...
/ var / www / html / website_xyz

Moje cele są następujące:

  • Użytkownik „programista” ma dostęp do „/ var / www / html / website_abc” i tylko „/ var / www / html / website_abc”
    • Przypuszczam, że użytkownik „programista” użyje słowa „programista @ [mój elastyczny adres IP]” jako nazwy użytkownika, aby zalogować się do SFTP (lub FTP), prawda?
  • Użytkownik „programista” nie ma dostępu do „/ var / www / html /” ani żadnych innych katalogów w mojej instancji EC2
  • Co powiesz na plik klucza prywatnego?
    • Czy przekazuję plik klucza prywatnego programistom zewnętrznym - czy jest to wskazane?
    • Czy istnieje sposób wygenerowania dla nich innego pliku klucza prywatnego lub umożliwienia im zalogowania się przy użyciu nazwy użytkownika i hasła?

Przeprowadziłem wyszukiwania, ale większość ludzi mówiła o tym, jak uzyskać dostęp do EC2 przez SFTP, z którego już jestem w stanie korzystać w WinSCP.

Wyjaśnienia:

  • Potrzebowałbym „programisty”, aby móc przesyłać rzeczy, do /var/www/html/website_abcktórych jest uprawnienie „zapisu”
  • Potrzebowałbym „programisty”, aby nie mieć uprawnień do „zapisu” dla dowolnych plików / katalogów /var/www/html/, a idealnie nawet „uprawnień do odczytu”
  • Wydaje się jednak, że jest tutaj duży problem:
    • /var/www/html/ma już uprawnienia 777, ponieważ jest to mój folder DocumentRoot. Jak więc uniemożliwić programistom dostęp do mojej innej witryny?

Częściowo rozwiązane udało mi się osiągnąć swoje cele za pomocą OpenSSH (tworzę folder .ssh wewnątrz / var / www / html / website_abc / i generuję klucz prywatny i przekazuję go programistom zewnętrznym). Dowiedziałem się również, że nigdy nie powinienem nigdy dawać pliku klucza prywatnego, który dał mi AWS. Wciąż uczę się o chroot.

centos amazon-ec2 ftp amazon-web-services sftp ericn
źródło
1
Przepraszam @lain, ale chyba mnie źle zrozumiałeś. Wydaje mi się, że mógłbyś spędzić czas na robieniu czegoś bardziej znaczącego niż na takim fałszywym osądzaniu. Być może, jeśli dokładnie przeczytasz moje pytanie, naprawdę miałbyś więcej wspólnego z SSH / SFTP niż z uprawnieniami do plików / folderów Linuksa, a raczej byłby to zamieszanie między nimi (dlaczego byłem zdezorientowany? Nie wiem, właśnie dlatego Potrzebowałem pomocy). To nie jest dokładna kopia innego wątku, jak uważałeś. W każdym razie udało mi się osiągnąć swoje cele za pomocą OpenSSH. Nadal uczę się o chroot, jak sugeruje Tom H i niektóre wyniki wyszukiwania. Dzięki
ericn,
„Dowiedziałem się również, że nigdy nie powinienem nigdy podawać pliku klucza prywatnego, który AWS mi dał”. Dlaczego .....
Michael Bailey

Odpowiedzi:

11

Domyślnie usługi zapewniające zdalną powłokę, taką jak ssh lub telnet, lub interaktywną zdalną sesję dla poleceń takich jak sftp, pozwalają użytkownikowi lokalnemu na przejście do dowolnego katalogu, do którego mają uprawnienia, i odzyskanie kopii dowolnego pliku, do którego mają dostęp.

Jako ogólna konfiguracja bezpieczeństwa jest to niefortunne, ponieważ istnieje wiele plików i katalogów, które z konieczności są czytelne na całym świecie. Na przykład tutaj jestem użytkownikiem innym niż root na jakimś zdalnym komputerze CentOS;

$ cd /etc
-bash-3.2$ ls -1
acpi
adjtime
aliases
...

np. mogę uzyskać dostęp do wielu rzeczy, które idealnie chcesz ograniczyć od nieznanego użytkownika, któremu chcesz zapewnić dostęp lokalny.

Oto ja patrzę na wszystkich lokalnych użytkowników skonfigurowanych w /etc/passwdpliku;

$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
...

Systemy uniksowe udostępniają chrootpolecenie, które pozwala zresetować /użytkownika do jakiegoś katalogu w hierarchii systemu plików, w którym nie ma on dostępu do plików i katalogów „wyżej”.

Jednak w twoim przypadku wskazane byłoby zapewnienie wirtualnego chroota zaimplementowanego przez zdalną usługę powłoki. sftp można łatwo skonfigurować, aby ograniczyć lokalnego użytkownika do określonego podzbioru systemu plików, używając konfiguracji w

Stąd w przypadku, chcesz chrootdo adeveloperużytkownika w /var/www/html/website_abckatalogu.

Możesz ustawić katalog chroot dla swojego użytkownika, aby ograniczał go do podkatalogu /var/www/html/website_abctak jak w /etc/ssh/sshd_config;

To wymaga serwera openssh późniejszego niż 4.8 ?, więc prawdopodobnie wymaga CentOS 6.2 

Match Group sftp
    ChrootDirectory %h
    AllowTcpForwarding no

(nie testowano, zobacz, man sshd_configaby potwierdzić składnię)

a następnie dodaj tych użytkowników do grupy sftp;

 groupadd sftp
 usermod -d /var/www/html/website_abc adeveloper
 usermod -G sftp adeveloper

Odnośnie udostępnionych kluczy

należy utworzyć dodatkową parę kluczy dla programistów i przesłać ją do konsultanta. (lub alternatywnie, niech wyślą swój klucz publiczny i dodadzą go do pliku autoryzowanego_kluczy dla adeveloper)

nigdy nie rezygnuj z klucza prywatnego, dlatego nazywa się prywatny ;-)

tradycyjne alternatywy ftp

vsftp / proftp itp. obsługują również konfiguracje chroot, ale w dzisiejszych konfiguracjach opartych na ssh są normalne, a obsługa ftp jest tylko historyczna.

tutaj jest kilka linków do samouczków;
http://www.techrepublic.com/blog/opensource/chroot-users-with-openssh-an-easier-way-to-confine-users-to-their-home-directories/229

http://www.howtoforge.com/chrooted-ssh-sftp-tutorial-debian-lenny

Tom H.
źródło
Do tej pory nie byłem w stanie zrozumieć chroota, ale wciąż się uczę i jeszcze się nie poddałem. Udało mi się jednak osiągnąć powyższe cele, korzystając z OpenSSH.
Jeszcze