Периодически возникает необходимость дать ограниченный доступ
пользователям по протоколу ssh. Например это может быть пользователь
хостинга, которому необходима возможность вносить исправления
непосредственно на сервере или же загружать контент используя безопасные
протоколы. К сожалению классический ftp передает логин и пароль
пользователя в открытом виде, что не всегда устраивает.
1. Установка
Все происходящее проверялось на 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
2. Создание 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:
Это тот минимум, который необходим для запуска /bin/bash
Опять таки, это в случае использования Debian, в любом другом случае
перед копирование какого либо исполняемого файла в
/var/www/client-site.com/bin необходимо проверить, от каких библиотек
зависит его выполнение и скопировать их также.
Для проверки работоспособности 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.
3. Настройка 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 порт.
Возможных решений два: не использовать стандартный ssh и полностью
перейти на chrooted ssh. Либо же продолжать использовать оба запретив
пользователю вход с помощью директив: DenyGroups или DenyUsers в файле
конфигурации sshd_config.
P.S. Часто возникают вопросы по поводу функциональности sftp-сервера в
chroot. К сожалению имеющаяся на данный момент версия не реализует этого
функционала. Точнее возможно и реализует, но я не нашел способа.
Зато нашел большое количество желающих это сделать. :) Подробнее можете
посмотреть в листе рассылки архив которой доступен на сайте http://chrootssh.sourceforge.net/
Vova
