Как добавить пользователя с доступом SFTP / FTP в папку «/ var / www / html / website_abc» в Amazon EC2 Centos?


19

Возможный дубликат:
разрешения для каталога Linux

Я работаю с некоторыми сторонними разработчиками и хотел бы предоставить SFTP (или FTP) доступ к корневой папке для веб-сайта, над которым они работают, т.е. '/var/www/html/website_abc'чтобы они могли загружать туда файлы. Обратите внимание, что я размещаю свои другие веб-сайты там в том же экземпляре EC2, например '/var/www/html/website_xyz'.

Просто чтобы подчеркнуть, что я работаю с несколькими сайтами на одном экземпляре EC2, структура сайтов выглядит следующим образом:

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

Мои цели заключаются в следующем:

  • Пользователь 'adeveloper' имеет доступ к '/ var / www / html / website_abc' и только к '/ var / www / html / website_abc'
    • Я полагаю, что пользователь «adeveloper» будет использовать «adeveloper @ [мой эластичный IP]» в качестве имени пользователя для входа в SFTP (или FTP), я прав?
  • Пользователь 'adeveloper' не имеет доступа к '/ var / www / html /' или любым другим каталогам в моем экземпляре EC2
  • Как насчет файла закрытого ключа?
    • Передам ли я свой файл закрытого ключа сторонним разработчикам - это целесообразно?
    • Есть ли способ создать для них другой файл с закрытым ключом или разрешить им входить в систему с именем пользователя и паролем?

Я провел поиск, но большинство людей говорили о том, как получить доступ к EC2 через SFTP, что я уже могу использовать WinSCP.

Разъяснения:

  • Мне нужно было бы иметь "разработчика", чтобы иметь возможность загружать материалы, на /var/www/html/website_abcкоторые есть разрешение на "запись"
  • Мне нужно было бы иметь «разработчика», чтобы не иметь разрешения на «запись» для любых файлов / каталогов в /var/www/html/, и в идеале даже не «разрешение на чтение»
  • Однако здесь, кажется, есть большая проблема:
    • /var/www/html/уже имеет разрешение 777, так как это моя папка DocumentRoot. Итак, как мне запретить доступ «разработчика» к моему другому веб-сайту?

Частично решено. Мне удалось достичь своих целей с помощью OpenSSH (я создаю папку .ssh внутри / var / www / html / website_abc /, создаю закрытый ключ и передаю его сторонним разработчикам). Я также узнал, что никогда не должен передавать файл с закрытым ключом, который мне дал AWS. Все еще учусь о chroot.


1
Извините @lain, но вы меня неправильно поняли. Я думаю, вы могли бы потратить время на то, чтобы сделать что-то более значимое, чем ложное суждение, подобное этому. Возможно, если вы внимательно прочитаете мой вопрос, вам действительно придется иметь дело с SSH / SFTP, а не с правами доступа к файлам / папкам в Linux, или, скорее, это была путаница между ними (почему я запутался? Я не знаю, поэтому Мне нужна была помощь) Это не является точной копией другого потока, как вы думали. Во всяком случае, мне удалось достичь своих целей с помощью OpenSSH. Я все еще учусь о chroot, как это было предложено Томом Х., и некоторыми результатами поиска. Спасибо
Эрик

«Я также узнал, что никогда не должен давать файл закрытого ключа, который AWS дал мне» Почему .....
Майкл Бэйли

Ответы:


11

По умолчанию службы, предоставляющие удаленную оболочку, например ssh или telnet, или интерактивный удаленный сеанс для таких команд, как sftp, позволяют локальному пользователю переходить в любой каталог, для которого у него есть разрешения, и извлекать копию любого файла, к которому у них есть доступ.

Как общая конфигурация безопасности, это неудачно, потому что есть много файлов и каталогов, которые могут быть прочитаны по необходимости. Например, вот я, не являющийся пользователем root, на удаленном компьютере CentOS;

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

Например, я могу получить доступ ко многим вещам, которые в идеале вы хотели бы ограничить от неизвестного пользователя, которому вы хотите предоставить локальный доступ.

Здесь я смотрю на всех локальных пользователей, настроенных в /etc/passwdфайле;

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

Системы Unix предоставляют chrootкоманду, которая позволяет вам сбросить /пользователя в некоторый каталог в иерархии файловой системы, где они не могут получить доступ к «более высоким» файлам и каталогам.

Однако в вашем случае было бы целесообразно предоставить виртуальный chroot, реализованный службой удаленной оболочки. sftp может быть легко настроен для ограничения локального пользователя определенным подмножеством файловой системы, используя конфигурацию в

следовательно , в вашем случае, вы хотите chrootот adeveloperпользователя в /var/www/html/website_abcкаталоге.

Вы можете установить каталог chroot для своего пользователя, чтобы ограничить его подкаталогом, /var/www/html/website_abcкак в /etc/ssh/sshd_config;

Для этого требуется openssh-сервер более поздней версии, чем 4.8 ?, поэтому, вероятно, требуется CentOS 6.2

Match Group sftp
    ChrootDirectory %h
    AllowTcpForwarding no

(не проверено, см. man sshd_configдля подтверждения синтаксиса)

а затем добавьте этих пользователей в группу sftp;

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

Относительно общих ключей

Вы должны создать дополнительную пару ключей для пользователей-разработчиков и отправить ее своему консультанту. (или, альтернативно, пусть они отправят ваш открытый ключ и добавят его в файл author_keys для adeveloper)

никогда не сдавай свой личный ключ, поэтому он называется личным ;-)

традиционные альтернативы ftp

vsftp / proftp и т. д. также поддерживают конфигурации chroot, но в наши дни конфигурации на основе ssh являются обычным способом, а поддержка ftp является исторической.

здесь есть несколько ссылок на учебники;
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


Я до сих пор не смог понять chroot, но я все еще учусь и еще не сдался. Мне удалось достичь своих целей, указанных выше, используя OpenSSH.
Еще
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.