Назад | Перейти на главную страницу

Создание нескольких пользователей SFTP для одной учетной записи

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

Я планирую заменить это на SFTP, но мне нужен способ создать несколько пользователей SFTP, соответствующих одной учетной записи UNIX. У клиента есть одна учетная запись на машине (например, customer) с домашним каталогом, например /home/customer/.

Наши клиенты привыкли создавать произвольное количество учетных записей FTP для своих доменов (чтобы раздавать их разным людям). Нам нужна такая же возможность с SFTP.

Моя первая мысль - использовать ключи SSH и просто добавлять каждого нового «пользователя» в authorized_keys, но это сбивает с толку наших клиентов, многие из которых не обладают техническими знаниями и предпочитают использовать пароли.

SSH не проблема, доступен только SFTP. Как мы можем создать несколько учетных записей SFTP (customer, customer_developer1, customer_developer2и т. д.), которые функционируют как эквиваленты и не влияют на права доступа к файлам (в идеале все файлы должны сохранять customer как их владелец)?

Моей первоначальной мыслью был какой-то модуль PAM, но у меня нет четкого представления о том, как это сделать в рамках наших ограничений. Мы открыты для использования альтернативного демона SSH, если OpenSSH не подходит для нашей ситуации; опять же, он должен поддерживать только SFTP, а не SSH.

В настоящее время в нашу конфигурацию SSH добавлено следующее, чтобы помещать пользователей в тюрьму в их собственных каталогах:

# all customers have group 'customer'
Match group customer
    ChrootDirectory /home/%u    # jail in home directories
    AllowTcpForwarding no
    X11Forwarding no
    ForceCommand internal-sftp  # force SFTP
    PasswordAuthentication yes  # for non-customer accounts we use keys instead

Наши серверы работают под управлением Ubuntu 12.04 LTS.

linux ssh sftp

Наше решение - создать основную учетную запись пользователя для каждого клиента, например flowershop. Каждый клиент может создать произвольное количество дополнительных учетных записей со своими паролями, например flowershop_developer, flowershop_tester, flowershop_dbaи т. д. Это позволяет им раздавать учетные записи, не сообщая пароль своей основной учетной записи, что лучше по целому ряду причин (например, если им нужно удалить учетную запись администратора базы данных, они могут легко сделать это, не меняя свои собственные пароли) .

Каждая из этих учетных записей находится в flowershop группа, с домашней папкой /home/flowershop/. SSH использует это как корневой каталог (/home/%u, как показано в конфигурации в вопросе).

Затем мы используем ACL для включения каждого пользователя в группе flowershop чтобы изменить все файлы. Когда создается новая учетная запись клиента, мы устанавливаем ACL следующим образом:

setfacl -Rm \
d:group:admin:rwx,d:user:www-data:r-x,d:user:$USERNAME:rwx,d:group:$USERNAME:rwx,\
  group:admin:rwx,  user:www-data:r-x,  user:$USERNAME:rwx,  group:$USERNAME:rwx \
/home/$USERNAME/

Это делает следующее:

Дает группу admin (для нас, хостинг-провайдеров) rwx
Дает пользователю www-data (Апач) r-x в файлы *
Дает пользователю $USERNAME rwx к файлам
Дает группу $USERNAME rwx к файлам

Похоже, что эта настройка работает у нас хорошо, но мы открыты для любых предложений по ее улучшению.

_{* мы используем suexec для CGI / PHP, работающего как учетная запись клиента}

Не уверен, как приведенное выше решение помогает решить проблему Оператора. Если flowershop_developer войдет в систему, он будет chroot для /home/%u т.е. /home/flowershop_developer каталог. То же самое и для других пользователей.

Как они могут увидеть содержание /home/flowershop каталог, если они заключены в тюрьму в их домашний каталог?

Надеюсь, я не упускаю что-то столь тривиальное. У меня есть рабочее решение, использующее mount -o опция привязки, которая позволит мне установить /home/flowershop в пределах /home/flowershop_developer но надеялся, что есть более простое и элегантное решение.

Я не уверен, что вы имеете в виду под «эквивалентами». Должны ли все учетные записи иметь свой собственный домашний каталог? В этом случае просто создайте индивидуальные учетные записи с индивидуальными домашними каталогами. Или все учетные записи должны использовать один и тот же домашний каталог? Это, вероятно, не слишком хорошая идея, но вы можете создать все учетные записи с одной и той же основной (или дополнительной) группой и использовать ACL для обработки разрешений.