LINUX.ORG.RU
решено Форум — Admin  

Аккаунтинг SFTP

 , ,


0

1

Хай! Надо перевести корпоративных веб-макак с FTP на SFTP. И встаёт вопрос о контроле доступа к целевым шарам. Допустим у нас есть пользователь www-data от которого крутится веб-сервер. В домашнем каталоге этого пользователя есть подкаталоги с сайтами. Вот на уровне этих подкаталогов нужно запереть пользователей при этом сохранив им право писать/читать от www-data. Авторизация должна быть по уникальным, для каждого суб-аккаунта, ключам. С FTP это делается просто. А куда копать в случае SFTP?

☆

Ответ на: комментарий от Hg194

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

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

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

emorozov ☆
()

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

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

annulen ★★★★★
()
Ответ на: комментарий от emorozov

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

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

Hg194 ☆
() автор топика
Ответ на: комментарий от Hg194

Я его ни разу не настраивал, только пользовался, но вроде здесь понятно написано: 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

annulen ★★★★★
()
Ответ на: комментарий от Hg194

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

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

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

Нет слов…

emorozov ☆
()
Ответ на: комментарий от emorozov

Нет слов…

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

Hg194 ☆
() автор топика

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

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

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

goingUp ★★★★★
()
Ответ на: комментарий от Hg194

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

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

thesis ★★★★★
()
Ответ на: комментарий от Hg194

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

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

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)

Немного покурив и почитав маны по 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 и будет топ!

Hg194 ☆
() автор топика
Ответ на: комментарий от Hg194

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

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

firkax ★★★★★
()

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

Subsystem sftp internal-sftp  (чтобы не зависеть от отдельного бинарника после chroot)
ForceCommand internal-sftp (чтобы запретить шеллы)
ChrootDirectory %h
+ ставишь no на всякие AllowXXXForwarding и подобное. Но учти что чтобы оттуда писались логи их обращений к файлам - надо в их chroot-ы пробросить syslog-сокеты, будет не очень красиво смотреться.

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

firkax ★★★★★
()
Ответ на: комментарий от Hg194

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

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

firkax ★★★★★
()
Ответ на: комментарий от firkax

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

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

Hg194 ☆
() автор топика
Ответ на: комментарий от Hg194

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

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)
Ответ на: комментарий от firkax

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

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

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

Hg194 ☆
() автор топика
Ответ на: комментарий от Hg194

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

anc ★★★★★
()
Admin