Возможный дубликат:
разрешения для каталога 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.
Ответы:
По умолчанию службы, предоставляющие удаленную оболочку, например ssh или telnet, или интерактивный удаленный сеанс для таких команд, как sftp, позволяют локальному пользователю переходить в любой каталог, для которого у него есть разрешения, и извлекать копию любого файла, к которому у них есть доступ.
Как общая конфигурация безопасности, это неудачно, потому что есть много файлов и каталогов, которые могут быть прочитаны по необходимости. Например, вот я, не являющийся пользователем root, на удаленном компьютере CentOS;
Например, я могу получить доступ ко многим вещам, которые в идеале вы хотели бы ограничить от неизвестного пользователя, которому вы хотите предоставить локальный доступ.
Здесь я смотрю на всех локальных пользователей, настроенных в
/etc/passwd
файле;Системы 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
(не проверено, см.
man sshd_config
для подтверждения синтаксиса)а затем добавьте этих пользователей в группу sftp;
Относительно общих ключей
Вы должны создать дополнительную пару ключей для пользователей-разработчиков и отправить ее своему консультанту. (или, альтернативно, пусть они отправят ваш открытый ключ и добавят его в файл 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
источник