Как ограничить доступ пользователей SSH к определенным каталогам в Ubuntu 24.04

Самый безопасный способ ограничить доступ пользователей SSH к определенному каталогу в Ubuntu 24.04 — использовать OpenSSH ChrootDirectoryс параметром `--` ForceCommand internal-sftp. Это идеально подходит, когда учетной записи требуется только передача файлов. Это предоставляет пользователю SFTP-интерфейс, корневой каталог файловой системы которого совпадает с выбранным каталогом, блокируя при этом интерактивную оболочку и переадресацию SSH.

Если пользователю действительно нужна обычная оболочка, решение другое. Для интерактивной оболочки в изолированной среде (chroot) требуется собственный исполняемый файл оболочки, библиотеки, узлы устройств и вспомогательные файлы внутри изолированной среды (jail). OpenSSH это явно документирует. Для большинства учетных записей для загрузки, резервного копирования, агентских, сторонних и общих хостингов chroot только для SFTP гораздо проще и менее подвержен ошибкам. Для ненадежных пользователей, которым нужна полноценная командная среда, контейнер или выделенная виртуальная машина обычно проще в обслуживании, чем создание chroot-окружения вручную.

В этом руководстве используется Ubuntu 24.04 LTS и пример пользователя с именем alice. Пользователь будет ограничен доступом к каталогу /srv/sftp/aliceи сможет записывать данные только внутри него /files. Замените имена и пути в соответствии с вашим сервером.

Прежде чем начать: разберитесь в правиле собственности.

Наиболее распространенная ошибка chroot вызвана правами доступа. OpenSSH требует, чтобы каждый компонент пути ChrootDirectoryпринадлежал root и не был доступен для записи группой или другими пользователями . Это требование проверяется безусловно. Это означает, что вы не должны устанавливать /srv/sftp/aliceправа на запись для root alice.

Вместо этого сделайте так, чтобы права доступа к виртуальной машине принадлежали root, и создайте дочерний каталог с правами на запись:

/srv/sftp/alice        root:root   755
└── files              alice:alice 755

Данная архитектура соответствует поведению, описанному в руководстве Ubuntu 24.04sshd_config(5) . В том же руководстве отмечается, что internal-sftpвнутри chroot не требуются дополнительные файлы среды выполнения, поэтому она лучше всего подходит для учетной записи с ограниченными правами на передачу файлов.

Шаг 1: Убедитесь, что OpenSSH Server установлен.

При необходимости установите серверный пакет:

sudo apt update
sudo apt install openssh-server
sudo systemctl status ssh.service

В официальной документации Ubuntu по OpenSSH используется openssh-serverпакет демона и ssh.serviceдля управления службами. См. руководство по OpenSSH для Ubuntu Server .

Если это удалённый компьютер, и SSH — ваш единственный путь администрирования, оставьте текущую сессию администратора открытой во время внесения изменений. Неправильная конфигурация SSH может заблокировать вам доступ.

Шаг 2: Создайте группу и добавьте в нее пользователя с ограниченными правами.

Создайте группу для пользователей с ограниченными правами. Если группа aliceуже существует, добавьте в неё только её:

sudo groupadd sftpusers
sudo adduser alice
sudo usermod -aG sftpusers alice
id alice

Если вы уже используете открытые ключи SSH, продолжайте это делать. Конфигурация chroot контролирует то, что происходит после аутентификации ; она не требует от вас перехода от аутентификации по ключу к аутентификации по паролю.

Групповое правило обычно лучше, чем отдельный Match Userблок для каждой учетной записи. Оно позволяет хранить политику в одном месте. Правило для каждого пользователя по-прежнему полезно, когда необходимо ограничить разных пользователей разными макетами.

Шаг 3: Создайте виртуальную среду (jail) с правами root и подкаталог с возможностью записи.

Создайте иерархию каталогов:

sudo mkdir -p /srv/sftp/alice/files
sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files
sudo chmod 755 /srv/sftp/alice/files

Подтвердите право собственности:

ls -ld /srv /srv/sftp /srv/sftp/alice /srv/sftp/alice/files
namei -l /srv/sftp/alice

Если /srvпуть /srv/sftpдоступен для записи группой или пользователем, исправьте и это. OpenSSH проверяет все компоненты пути, а не только конечный каталог.

Шаг 4: Добавьте правило соответствия в файл sshd_config.d

В текущей документации Ubuntu для серверных приложений рекомендуется сохранять пользовательские настройки SSH, /etc/ssh/sshd_config.d/а не смешивать их с основным файлом пакета. Создайте фрагмент кода:

sudo nano /etc/ssh/sshd_config.d/90-sftp-restricted.conf

Добавлять:

Match Group sftpusers
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp -d /files
    DisableForwarding yes
    PermitTTY no

Match all

%uРазворачивается в аутентифицированное имя пользователя, поэтому aliceпомещается в /srv/sftp/alice. -d /filesАргумент указывает внутреннему SFTP-серверу запускаться внутри доступного для записи дочернего каталога. DisableForwarding yesОтключает пересылку X11, агента, TCP и StreamLocal одной директивой; это специально задокументировано для упрощения конфигураций с ограниченными правами.

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

Шаг 5: Выберите между ограничениями на уровне групп и ограничениями для каждого пользователя.

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

Match User vendor1
    ChrootDirectory /srv/vendor/vendor1
    ForceCommand internal-sftp -d /incoming
    DisableForwarding yes
    PermitTTY no

Match all

Выберите вариант, исходя из административных расходов:

Шаг 6: Проверьте конфигурацию SSH перед перезапуском.

Никогда не перезапускайте SSH сразу после редактирования файла. Сначала выполните проверку синтаксиса, рекомендованную Ubuntu:

sudo sshd -t

Отсутствие вывода означает, что проверка синтаксиса прошла успешно. Вы также можете проверить фактическую конфигурацию для конкретного пользователя:

sudo sshd -T -C user=alice,host=localhost,addr=127.0.0.1   | grep -E 'chrootdirectory|forcecommand|disableforwarding|permittty'

Вы должны увидеть ожидаемый путь к chroot-окружению и принудительную команду SFTP. Это особенно полезно в Ubuntu, поскольку настройки могут поступать как из файлов, так /etc/ssh/sshd_configи из файлов в каталоге /etc/ssh/sshd_config.d/. Ubuntu отмечает, что OpenSSH обычно использует первое полученное значение для большинства директив, поэтому проверка эффективной конфигурации безопаснее, чем предположение о том, какой файл имеет приоритет.

Шаг 7: Перезапустите SSH и проверьте работу с SFTP.

Внесите изменения:

sudo systemctl restart ssh.service
sudo systemctl status ssh.service

Затем подключитесь из другого терминала:

sftp alice@server.example.com

Внутри SFTP выполните тест:

pwd
ls
put test.txt
ls -l

При указанной выше конфигурации начальный каталог SFTP должен быть /files. Косая черта, отображаемая SFTP, обозначает корень chroot-окружения, а не реальный корень сервера.

Обычная попытка использования оболочки не должна приводить к получению неограниченной оболочки:

ssh alice@server.example.com

Поскольку ForceCommand internal-sftpэта учетная запись заменяет запрошенную сессию на сессию, запущенную непосредственно на SFTP-сервере, она предназначена для передачи файлов, а не для выполнения команд.

Шаг 8: Подтвердите, что пользователь не может покинуть тюрьму.

Попробуйте перейти к более закрытым, на первый взгляд, корневым путям и проверить конфиденциальные пути к хосту:

cd ..
ls /
ls /etc
ls /root

Внутри chroot-окружения /это представляет собой каталог /srv/sftp/aliceна хосте. Если вы не создали каталог etcили внутри этого окружения, пользователь не сможет получить доступ к реальному каталогу или каталогу rootхоста ./etc/root

Также протестируйте загрузку в /files. Конфигурация, которая блокирует выход из системы, но случайно делает весь jail доступным только для чтения, является безопасной, но бесполезной для учетной записи для загрузки.

Устранение неполадок: «неверные права доступа или режимы для каталога chroot»

Если вход в систему не удается сразу, проверьте журнал службы SSH:

sudo journalctl -fu ssh.service

В руководстве по OpenSSH в Ubuntu рекомендуется использовать журнал службы SSH для устранения неполадок. Если вы видите ошибку владения или режима доступа, проверьте все родительские каталоги:

namei -l /srv/sftp/alice

Путь к chroot-окружению должен принадлежать пользователю root и быть недоступен для записи группой или другими пользователями. Распространенная ошибка заключается в следующем:

sudo chown alice:alice /srv/sftp/alice

Не решайте проблему, ослабляя проверки OpenSSH. Вместо этого разместите область записи пользователя ниже корневого каталога chroot:

sudo chown root:root /srv/sftp/alice
sudo chmod 755 /srv/sftp/alice
sudo chown alice:alice /srv/sftp/alice/files

А что, если пользователю нужен доступ к SSH-оболочке, а не только к SFTP?

ChrootDirectoryЕго также можно использовать с интерактивной оболочкой, но настройка значительно сложнее. OpenSSH заявляет, что для интерактивного chroot требуется как минимум оболочка и базовые /devузлы, а также любые исполняемые файлы, библиотеки, файлы разрешения имен и другие зависимости, необходимые для разрешенных вами команд.

Для строго контролируемой учетной записи виртуального устройства создание такой изолированной среды может быть оправдано. Для общего доступа к командам Linux это часто создает дополнительную нагрузку на обслуживание: обновления безопасности для инструментов и библиотек также должны отражаться внутри изолированной среды. Если же ваша реальная задача — «разрешить этому человеку выполнять команды, но изолировать его от хоста», то контейнер, виртуальная машина или специально созданная служба с ограниченным доступом обычно проще для аудита.

Стоит добавить улучшения в области безопасности.

Ограничение доступа к каталогам — это лишь один уровень. Для серверов, доступных из интернета, следует также учитывать следующее:

• По возможности используйте аутентификацию по открытому ключу SSH для учетных записей пользователей и автоматизированных систем.
• Не предоставляйте ограниченный sudoдоступ пользователям, осуществляющим передачу файлов.
• Используйте этот протокол DisableForwarding yesтолько для учетных записей SFTP, чтобы SSH-соединение нельзя было перенаправить на туннелирование или переадресацию агента.
• Ограничьте доступ к каталогам для записи минимальным объемом, необходимым для выполнения рабочего процесса.
• journalctl -u ssh.serviceПосле добавления пользователей проверьте права собственности на файлы и оцените их.
• Во время тестирования изменений в конфигурации удаленного SSH оставьте открытой сессию администратора.

Для получения подробной информации о работе ChrootDirectory, Match, ForceCommand, и DisableForwardingиспользуйте руководство по настройке сервера OpenSSH в Ubuntu 24.04 . Для получения информации о конфигурации, проверке, командах перезапуска и логировании, специфичных для Ubuntu, обратитесь к официальной документации сервера OpenSSH в Ubuntu .

Итог

Если цель состоит в том, чтобы «эта учетная запись SSH могла загружать и скачивать файлы только из одной директории», используйте учетную запись root ChrootDirectory, разместите доступный для записи контент в дочерней директории, принадлежащей пользователю, и принудительно установите флаг `--` internal-sftp. Проверьте флаг `--` с помощью команды `--` sshd -tперед перезапуском, затем протестируйте разрешенный путь загрузки и попытку доступа за пределами chroot-окружения. Это обеспечит вам небольшую, понятную границу безопасности без необходимости создания полноценной среды Linux внутри chroot.