Ubuntu Server 22.04 SSH ChrootDirectory ведет себя не так, как ожидалось при доступе через SFTP

Question

Обычно после успешного входа в систему sftpи выполнения putкоманды я ожидаю, что мой файл будет перемещен в $HOMEкаталог вошедшего в систему пользователя. Это работает из коробки, но я хотел бы ограничить пользователя sftpего $HOMEкаталогом (чтобы он не мог cdподняться на более высокие уровни, например).

Вот где я использую ChrootDirectory- согласно документации (https://linux.die.net/man/5/sshd_config)

ChrootDirectory: Указывает путь к chroot(2) после аутентификации. Этот путь и все его компоненты должны быть каталогами, принадлежащими root, которые не могут быть записаны никаким другим пользователем или группой

Я считаю, что правильно настроил папки / разрешения. Следующее предложение документации, как мне кажется, не работает или ведет себя не так, как ожидалось.

После chroot sshd(8) изменяет рабочий каталог на домашний каталог пользователя.

После изменения sshd_configдля использования ChrootDirectoryи успешного доступа к серверу через sftpрабочий каталог пользователя НЕ устанавливается в каталог $HOME пользователя, а на самом деле устанавливается на один уровень выше. (например, /homeвместо /home/userTest) Очевидным решением для пользователя является переход в нужный каталог на один уровень ниже, но если вы используете какую-то автоматизированную систему, которая просто передает данные по FTP в текущий рабочий каталог, это может быть очень проблематично.

Сначала я покажу общий случай, а затем модифицирую его, чтобы показать, как изменяется поведение рабочего каталога по умолчанию после ChrootDirectoryего внедрения.sshd_config

Это работает так, как и ожидалось:

1. Создайте пользователя (используйте -mдля создания домашнего каталога этого пользователя):sudo useradd -m userTest
2. Дайте пользователю пароль:sudo passwd userTest
3. Обратите внимание userTestна каталог $HOME: cat /etc/passwd->userTest:x:1002:1004::/home/userTest:/bin/sh
4. sftp на ваш сервер для пользователя, которого вы только что создали:sftp userTest@<your-server>
5. Обратите внимание на рабочий каталог после успешного входа в систему: pwd->Remote working directory: /home/userTest

Приведенный выше пример работает именно так, как и ожидалось, единственная проблема в том, что userTestон не заблокирован в рабочем каталоге и может привести cd ..к сбросу файловой системы.

В нескольких руководствах было одно и то же базовое решение этой проблемы (https://linuxconfig.org/how-to-setup-sftp-server-on-ubuntu-20-04-focal-fossa-linux)

Дополнение к предыдущим шагам

1. Добавьте группу sftp (она будет использоваться как ключ для нашего Matchблока в sshd_config):sudo addgroup sftp
2. Добавить userTestпользователя в группу:sudo usermod -a -G sftp userTest
3. Редактировать sshd_config:sudo nano /etc/ssh/sshd_config
4. Добавьте следующие строки в конец файла

Match group sftp
ChrootDirectory /home
ForceCommand internal-sftp

(По сути, это означает, что любой пользователь, принадлежащий к sftpгруппе, будет подчиняться правилам ChrootDirectoryи ForceCommand)

Сохраните файл и перезапустите ssh: sudo systemctl restart ssh

Убедитесь, что указанный каталог ChrootDirectoryудовлетворяет требованиям из документации выше: ls -ltr-> drwxr-xr-x 4 root root 4096 Jun 10 09:02 home(я полагаю, что это выполнено)

Сравните результаты стандартной настройки с результатами нашей новой конфигурации sftp, используя userTestеще раз:sftp userTest@<your-server>

Обратите внимание на текущий рабочий каталог: pwd->Remote working directory: /

Это не является явным признаком того, что что-то не так, мы ожидаем, что рабочий каталог изменится... однако давайте быстро проверим содержимое текущего рабочего каталога:

ls -ltr-> drwxr-x--- 3 1002 1004 4096 Jun 10 09:10 userTest(!!!)

Согласно документации:

После chroot sshd(8) изменяет рабочий каталог на домашний каталог пользователя.

ls -ltrпоказывает нам, что рабочий каталог НЕ находится в userTestдомашнем каталоге, а на самом деле находится на один уровень ВЫШЕ.

Есть ли способ настроить ChrootDirectoryили какой-то другой способ заставить это работать так, как ожидается?

ПРИМЕЧАНИЕ: Удаление ForceCommandиз sshd_config на самом деле приводит к этой другой проблеме, которая была закрыта как ERRATA 11 лет назад? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=681202