Вопрос: Переслать пользователя SFTP в подкаталог chroot после аутентификации


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

После аутентификации пользователи оказываются непосредственно внутри /chroot, директорию, в которую им не разрешено записывать. Поэтому я поставил /subdirectory в /chroot у них есть доступ на запись (вдохновленный это сообщение в блоге), который отлично работает.

Однако из-за характера проекта, над которым я работаю, пользователи должны находиться непосредственно в папке, которую им разрешено записывать после аутентификации. Пересылка их в /chroot/subdirectory может быть лучшим решением, но я не нашел ресурса, объясняющего, как этого достичь.

Это можно сделать? Как?


6
2017-07-10 13:13


Источник




Ответы:


[РЕДАКТИРОВАТЬ] Да, я считаю, что это возможно, но я также верю не в openssh:

Вот как я chroot sftp с помощью openssh:

Я поставил пользователей sftp в специальную группу sftponly который идентифицирован в sshd_config файл. Я уверен, что у пользователей sftp нет оболочки (поэтому они не могут войти в систему с ssh) и использовать .%h переменную среды, чтобы принудительно включить их в поддиректор chftot sftp, названный в честь своего домашнего каталога, используя ChrootDirectory директивы. Другие переменные среды, интерпретируемые sshd_config, описаны в Страница руководства sshd_conf вот так:

Путь может содержать следующие токены, которые   после того, как соединительный пользователь был аутентифицирован: %% is   заменяется литеральным «%»,% h заменяется домашним каталогом   пользователь аутентифицируется, а% u заменяется на имя пользователя этого   пользователь.

Вот копия моих заметок для достижения этого на OpenBSD, если вы используете другую систему, .%h переменная среды, разумеется, может различаться:

# 1. Create the sftp jail directories
# These directory permissions work with this /etc/ssh/sshd_config:
# drwxr-xr-x  4 root    wheel  512 May 14 16:20 /home/sftproot
# drwxr-xr-x  3 root  wheel  512 May 14 16:21 /home/sftproot/home
# drwxr-xr-x  3 root  wheel  512 May 14 16:37 /home/sftproot/home/User01
# drwxr-xr-x  3 User01  sftponly  512 May 14 16:39 /home/sftproot/home/User01/upload
# drwxr-xr-x  3 root  wheel  512 May 14 16:37 /home/sftproot/home/User02
# drwxr-xr-x  3 User02  sftponly  512 May 14 16:39 /home/sftproot/home/User02/upload

# 2. Make sure /etc/ssh/sshd_config jails /home/sftproot/.%h

# 3. Create a group whose members will only be allowed sftp access
# groupadd sftponly

# 4. Create User01 + User02 whom will only get sftp access
# useradd -s /sbin/nologin -m -G sftponly User01
# useradd -s /sbin/nologin -m -G sftponly User02

# 5. In /etc/ssh/sshd_config enable use of chroot(internal-sftp) then force chroot dirs per user:
# override default of no subsystems
# Subsystem     sftp    /usr/libexec/sftp-server
# Subsystem       sftp    internal-sftp
# Rules for sftponly members
# Match group sftponly
#         ChrootDirectory /home/sftproot/.%h
#         X11Forwarding no
#         AllowTcpForwarding no
#        ForceCommand internal-sftp

# [Comment] Make sure /etc/ssh/sshd_config jails /home/sftproot/.%h
# Which will translate .%h to /home/$username

# [Comment] The sftp users will not be able to log in outside of sftp (as they have no shell).
# As they sftp in they will land in the /home/sftproot/home/Userxx directory which
# will be named "./" and where they have no write access.
# However the directory ./upload is read/writable.

[EDIT часть 2] Однако Страница руководства sshd_conf также указывает, что:

ChrootDirectory

Указывает путь к каталогу chroot (2) после   аутентификация. При запуске сеанса sshd (8) проверяет, что все компоненты   имени пути являются корневыми каталогами, которые не могут быть перезаписаны   любого другого пользователя или группы. После chroot sshd (8) изменяет рабочий   каталог в домашний каталог пользователя.

Таким образом, путь каталога chroot, включая часть, указанную расширением переменной, ожидается и проверен на то, чтобы sshd принадлежал и был доступен для записи исключительно root. Таким образом, пользователю chrooted-сервиса openssh sftp нужны записываемые подкаталоги для записи в домашний каталог.

Я считаю, что это не требование со всеми серверами ssh. Мы также используем Tectia где я наблюдаю, что пользователи могут писать в соответствующие корневые каталоги. Однако мы запускаем его только там, где требуется Windows, поэтому, к сожалению, я не могу легко проверить соответствующую конфигурацию * nix. Страница поддержки txtia sftp chrooting явно не указывает, что пользовательский дом должен принадлежать root в среде Unix. Поэтому я предполагал, что с Tectia это не является обязательным требованием, но владение домашним rootdir домашним пользователем может быть как у фактического пользователя.


3
2017-07-10 15:08



Благодаря! К сожалению, я не думаю, что это решает мою проблему. Как указано в моем вопросе, «пользователи должны найти себя непосредственно в папке, которую им разрешено записывать после аутентификации». Но в соответствии с вашими комментариями кода: «... они приземлятся в каталоге / home / sftproot / home / Userxx, который будет называться« ./ »и где у них нет доступа на запись. Однако каталог ./upload читается / записываемый «. Как я могу перенаправить пользователей напрямую на «./upload», если они никогда не видят «./»? - zerodot
Мой плохой, я пропустил это. Я отредактировал ответ соответственно. - ErikE
Спасибо за редактирование. Я боюсь, что Tectia не является решением, которое мы можем использовать, но я буду исследовать его дальше и обновить эту тему. - zerodot


ChrootDirectory / upload /% u

Данные ForceCommand internal-sftp -d

Это поместит каталог sftp in / upload / UserXX / data. Каталог данных принадлежит и доступен для чтения / записи пользователем UserXX


0
2018-06-14 14:37