Аккаунтинг SFTP

Макака - это всегда кто-то другой, да?

Макаки - это штатные прогеры. Давать им общую шару - самоубийство.

Давать разработчикам SFTP - это тоже обезьянство чистой воды, устаревшее на 20 лет.

У разработчиков должен быть CI/CD, в котором, после прохождения всех тестов, появляется кнопка «Deploy» (или несколько), нажав на которую всё будет деплоиться из CI/CD автоматически.

А к серверу разработчики вообще не должны иметь доступа.

Допустим у нас есть пользователь www-data от которого крутится веб-сервер. В домашнем каталоге этого пользователя есть подкаталоги с сайтами. Вот на уровне этих подкаталогов нужно запереть пользователей при этом сохранив им право писать/читать от www-data.

Сделать подкаталоги домашними каталогами пользователей, для www-data дать доступ через ACL

У разработчиков должен быть CI/CD, в котором, после прохождения всех тестов, появляется кнопка «Deploy» (или несколько), нажав на которую всё будет деплоиться из CI/CD автоматически.

Это всё конечно модно-современно-прогрессивно, но в нашем кейсе потребности в таких инструментах нет. Разрабы привыкли коммитить прямо на сервер, у них всё окружение настроено под это, и в принципе, это всех устраивает.

ACL

Я так надеелся что можно обойтись без этого монстра… А что можно почитать чтобы быстро погрузиться в его настройку? Никогда дел с ним не имел.

Я его ни разу не настраивал, только пользовался, но вроде здесь понятно написано: https://habr.com/ru/companies/southbridge/articles/673570/

Вот тут больше примеров https://www.osc.edu/resources/getting_started/howto/howto_manage_access_control_list_acls/howto_use_posix_acl

Если www-data достаточно прав на чтение, то можно без ACL обойтись простой группой, но тогда права на чтение буду у всех на всё.

Это всё конечно модно-современно-прогрессивно, но в нашем кейсе потребности в таких инструментах нет.

Дело не в модности и прогрессивности, а в том, что это невероятно удобно, и сокращает количество факапов.

Разрабы привыкли коммитить прямо на сервер, у них всё окружение настроено под это, и в принципе, это всех устраивает.

Нет слов…

Авторизация должна быть по уникальным, для каждого суб-аккаунта, ключам. С FTP это делается просто.

Стоп, как в FTP делается авторизация по ключам? Это FTPS что ли?

Стоп, как в FTP делается авторизация по ключам?

Под ключами я имею ввиду как пароли, так и ключ-файлы. :)

Нет слов…

Охо-хо! Рекомендую иногда вылазить из своего уютного офиса с пуфиками и смузи - не все работают с такими прогрессивными инструментами. И ничего плохого в этом нет - лишь бы работа делалась.

Дело не в смузи, которого у меня в офисе, к сожалению, нет. А в том, что вложенные усилия в настройку нормального процесса, окупаются сторицей.

1. Использовать fs с поддержкой acl, если че таже ext4 поддерживает.
2. команды setfacl, getfacl

Допустим у нас есть пользователь www-data от которого крутится веб-сервер.

1. Как разраб заливаешь веб файловый менеджер на php
2. Он может читать все то же, что и www-data и даже где-то писать
3. ???
4. PROFIT!

Разрабы используют ftp/sftp в своих IDE/редакторах для пушинга кода на сервер. Поэтому файловые менеджеры здесь не подходят.

Есть файловые менеджеры с веб интерфейсом, чтобы шарится по серверу, которые работают под пользователем веб-сервера. Это может быть один пхп файл, залил его, даже из ИДЕ, получил доступ ко всему, к чему имеет доступ веб-сервер)

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

Выдай им scp по ключам, а правами и пользователями рули через стандартные утилиты.

Разрабы используют ftp/sftp в своих IDE/редакторах для пушинга кода на сервер.

вы откуда такие не пуганные, родной?

Смотри. Ты хочешь выкинуть решение, созданное буквально под твою задачу, взяв вместо него решение для предоставления shell-доступа системным пользователям, к которому сбоку примотан плохо настраиваемый протокол передачи файлов.

У тебя какие цели, кроме как от души натрахаться?

У тебя какие цели

Безопасники спустили такое ТЗ. Мне главное это сделать, а ответственность уже не моя.

Пришло время послать безопасников нахер. Безопасники сами нахер не пойдут.

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

Немного покурив и почитав маны по ACL накидал что-то подобное:

setfacl -Rm d:group:www-data:rwx,d:user:www-data:rwx,d:user:subuser1:rwx,d:group:subuser1:rwx,group:www-data:rwx,user:www-data:rwx,user:subuser1:rwx,group:subuser1:rwx /var/www/site1

setfacl -Rm d:group:www-data:rwx,d:user:www-data:rwx,d:user:subuser2:rwx,d:group:subuser2:rwx,group:www-data:rwx,user:www-data:rwx,user:subuser2:rwx,group:subuser2:rwx /var/www/site2

Осталось накрутить сверху chroot и будет топ!

Осталось накрутить сверху chroot и будет топ!

С этого надо было начать.

Разрабы привыкли коммитить прямо на сервер,

Что значит «коммитить прямо на сервер»? Коммит подразумевает что есть vcs, вот через неё и надо на сервер заливать файлы. А для общения с vcs есть её штатный протокол.

Какое vcs?)) Тут коммитят (вносят правки) напрямую в проект, т.е в исходники лежащие в каталогах на сервере!

С ftp у тебя была дыра, которую кажется ты уже понял. Если хочешь сделать то же самое с sftp то создаёшь системные аккаунты для этих юзеров с $HOME = директориями куда «доступ», в конфиге sshd прописываешь для этих юзеров (можно по группе чтобы список не писать)

Subsystem sftp internal-sftp  (чтобы не зависеть от отдельного бинарника после chroot)
ForceCommand internal-sftp (чтобы запретить шеллы)
ChrootDirectory %h

Чтобы сделать без дыры, нужно всем фтп юзерам сделать разный uid, вебскрипты (которые они туда зальют) запускать тоже от разных uid и настроить права чтобы они друг к другу не могли лазить.

Тогда это называется «редактировать файлы прямо на сервере». Коммитом обычно называют отправку пачки правок в vcs.

А может научить их vcs пользоваться? Можно написать скрипт который автоматом забирает апдейты с svn репозитория и коммитит в него же все найденные локальные правки и научить их его запускать после внесения этих самых правок.

А может научить их vcs пользоваться?

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

С этого надо было начать.

Поправочка! Тогда начнём с chroot* :)

Учти что chroot в данной реализации будет чисто для удобства, безопасности он не добавит т.к. в этой схеме при желании обходится. Чтобы не обходился, надо посадить в строго тот же chroot и сами сайты, к которым соответствующий sftp-доступ, либо другим способом гарантированно убедиться, что они не смогут вылезти за пределы этого корня с правом на запись (в т.ч. в /tmp), и не смогут залезть куда не надо с правом на чтение.

Поправочка! Тогда начнём с chroot* :)

На гуле забанили?

Очень правильное дополнение!

Так оно и будет!

Допустим каталог /var/www/site1 является одновременно и хомяком для конкретного пользователя и chroot для него. В этом каталоге есть подкаталог ./data с acl-правами только для этого пользователя и общего пользователя www-data. В подкаталог ./data и будут сваливаться сайты/код и т.д.

Да и конкретно защиты от chroot особо не требуется. Главное чтобы нельзя было выбраться во внешние каталоги через sftp-клиент.

Иногда проще тут поймать ответ чем лезть в гугл. :)

Ну совсем обленились... здесь вам максимум дадут туже ссылку в гуле, никто не будет расписывать полную инструкцию. Вот поправить если не взлетело это завсегда пожалуйста :) Я когда-то давно эту тему не более чем опытным путем подбирал, там не сложно, вас интересуют нужные девайсы+бинарники+немного-конфигов, по бинарникам выясняем нужные либы + тех кого не хватит.
Из девайсов вроде хватает:
null
tty
urandom
zero

про качество авторской задумки тут уже все высказались, решение вот: https://superuser.com/questions/1080616/openssh-with-virtual-users-and-chroot