помещение ssh-пользователей в изолированное окружение

вступление

Периодически возникает необходимость дать ограниченный доступ пользователям по протоколу ssh. Например, это может быть пользователь хостинга, которому необходимо вносить исправления непосредственно на сервере или же загружать контент, используя безопасные протоколы. К сожалению классический FTP передает логин и пароль пользователя в открытом виде, что не всегда устраивает.

установка

Все происходящее проверялось на Debian Etch и Suse Ent. 9.

Необходимо загрузить последнюю версию пакета openssh с chroot-патчем с
сайта http://chrootssh.sourceforge.net/download/. Я использовал пакет openssh-4.5p1-chroot.tar.bz2.

Дополнительно могут понадобится пакеты zlib1g-dev и libssl-dev.

Это относится к Debian, в случае другого дистрибутива, пакеты могут называться иначе.

Я использовал переменную --prefix при сборке, для того, чтобы не затереть тот openssh, который поставляется с системой. Новый пакет я размещаю в отдельной директории. Это упростит обслуживание в дальнейшем.

Соответственно, команда конфигурации:

./configure --prefix=/usr/local/chrooted-openssh

Далее собираем и устанавливаем пакет:

# make && make install

создание chroot-окружения

Немного ручной работы - необходимо создать окружение chroot. Допустим, пользовательский сайт находится в директории: /var/www/client-site.com Создадим дерево директорий:

# pwd
/var/www/client-site.com
# mkdir -p dev bin usr/local


Создадим псевдоустройства:

# mknod ./dev/zero c 13 12
# mknod ./dev/null c 13 2


заполним окружение chroot

Файлы необходимые в директории /var/www/client-site.com/bin: cp, ls, mkdir, mv, rm, rmdir, bash.

Файлы необходимые в директории /var/www/client-site.com/usr/lib:

- ld-linux.so.2;

- libc.so.6;

- libdl.so.2;

- libncurses.so.5.

Это тот минимум, который необходим для запуска /bin/bash.

Опять-таки, это в случае использования Debian, в любом другом случае перед копированием какого-либо исполняемого файла в /var/www/client- site.com/bin необходимо проверить, от каких библиотек зависит его выполнение, и скопировать их также.

Например:

# ldd /bin/sh
linux-gate.so.1 => (0xffffe000)
libncurses.so.5 => /lib/libncurses.so.5 (0xa7f3c000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xa7f38000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xa7e06000)
/lib/ld-linux.so.2 (0xa7f84000)


Для проверки работоспособности chroot можно выполнить команду:

# chroot /var/www/client-site.com/ /bin/sh

После этого текущим корневым каталогом станет /var/www/client-site.com/, это можно проверить с помощью команд ls и pwd (если конечно, скопированы необходимые библиотеки). В случае, если запуск chroot выдает что-то вроде

chroot: cannot run command `/bin/sh': No such file or directory

необходимо проверить, все ли библиотеки скопированы в chroot-окружение. Проверьте с помощью ldd.

настройка chrooted ssh

Необходимо изменить номер порта, который будет слушать новый демон. По умолчанию 22, но у нас же уже есть один ssh, который слушает 22 порт. Я использую порт 8022. Добиться этого можно, добавив в файл /usr/local/chrooted-openssh/etc/sshd_config строку:

Port 8022

добавление пользователя

Следующий шаг - добавление пользователя, который будет использовать эту тюрьму. :)

Стандартными средствами необходимо добавить пользователя.

Следует учесть, что если пользователь использует не bash, а какой-либо другой shell, необходимо скопировать shell и все необходимы ему библиотеки в chroot-окружение.

# adduser --home /var/www/client-site.com --shell /bin/bash --no-create-home --gecos Test_chrooted chrooted
Adding user `chrooted' ...
Adding new group `chrooted' (1002) ...
Adding new user `chrooted' (1002) with group `chrooted' ...
Not creating home directory `/var/www/client-site.com'.
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully


На данном этапе пользователь chrooted имеет обычный доступ по ssh (не chrooted). Демон openssh определяет необходимость запихнуть в chroot пользователя по наличию у него в поле home точки. Точка указывает каталог, от которого начинается chroot. То есть поддиректорими точки должны быть bin/, usr/ и прочие.

В нашем случае необходимо изменить значение home пользователя на что-то вроде /var/www/client-site.com/./

После этого можно пробовать зайти по ssh (используя порт 8022) под пользователем chrooted. Пользователь должен быть заперт в домашней директории. Однако у пользователя по-прежнему остается возможность зайти с своим логином/паролем на стандартный ssh, который слушает 22 порт. Возможных решений два:

1. Не использовать стандартный ssh и полностью перейти на chrooted ssh.

2. Продолжать использовать оба, запретив пользователю вход с помощью директив DenyGroups или DenyUsers в файле конфигурации sshd_config.

P.S. Часто возникают вопросы по поводу функциональности sftp-сервера в chroot. К сожалению, имеющаяся на данный момент версия не реализует этого функционала. Точнее, возможно и реализует, но я не нашел способа. Зато нашел большое количество желающих это сделать. :) Подробнее можете посмотреть в листе рассылки, архив которой доступен на сайте http://chrootssh.sourceforge.net/.



Миша Володько


Сетевые решения. Статья была опубликована в номере 07 за 2007 год в рубрике sysadmin

©1999-2024 Сетевые решения