Freebsd chroot linux debian

Настройка домашнего каталога SFTP или SSH Chroot

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

1. Настройка SSH

Открываем конфигурационный файл openssh:

Комментируем следующую строку:

#Subsystem sftp /usr/lib/openssh/sftp-server

Добавляем следующее (обязательно в самый конец файла).

Для определенного пользователя:

Subsystem sftp internal-sftp -f AUTH -l VERBOSE
Match user sftpuser
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no

* где sftpuser — имя пользователя, для которого срабатывает набор правил; %h (home directory) — домашняя директория пользователя (здесь также можно указать конкретный каталог); ForceCommand internal-sftp — использовать только sftp, встроенный в ssh.
** если данные строки добавить не в конец файла, сервис ssh может не запуститься.

Для группы пользователей:

Subsystem sftp internal-sftp -f AUTH -l VERBOSE
Match group sftpgroup
ChrootDirectory /home/%u
ForceCommand internal-sftp
AllowTcpForwarding no

* как видим, в данном примере все то же самое — только меняем user на group. /home/%u — другой способ прописать путь к домашней директории (/home + имя пользователя).

После перезапускаем службу:

systemctl restart ssh || systemctl restart sshd || service ssh restart || service sshd restart

* команда рассчитана на запуск в разных версиях Linux (CentOS / Ubuntu / Red Hat / Debian и так далее, а также на базе systemd или ранних версий), так как служба может называться ssh или sshd.

2. Создание пользователя и группы

Если в системе еще нет группы или пользователя, для которого мы настроили SSH chroot, выполняем следующие команды.

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

useradd sftpuser -d /home/sftpuser -m

* где sftpuser — имя пользователя; /home/sftpuser — домашний каталог пользователя.

Задаем пароль для пользователя:

Создание группы

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

usermod sftpuser -G sftpgroup

или отредактировать файл:

* 1004 — идентификатор группы (может быть любым числом).

3. Выставление прав на каталог

При попытке подключиться по SFTP мы получим ошибку fatal: bad ownership or modes for chroot directory, так как необходимо выставить правильные права. Система требует, чтобы все каталоги пути имели права 755 и их владельцем был root.

В нашем примере мы выполняем следующие команды:

chown root: /home/sftpuser

chmod 755 /home/sftpuser

Права будут следующие:

drwxr-xr-x 2 root root 4096 окт. 30 09:00 /home/sftpuser/

Проверка и решение проблем

Проверить настройку можно с помощью любого sftp-клиента, например Filezilla или WinSCP.

При возникновении проблем, стоит просмотреть лог

tail -f -n20 /var/log/auth.log

tail -f -n20 /var/log/secure

* первая команда подходит для систем на базе RPM, вторая — Debian.

Lshell как альтернатива chroot ssh

По сути, это более простой способ настроить окружение chroot для пользователя UNIX систем.

Его развертывание сводится к установке:

yum install lshell

apt-get install lshell

* первая команда для Red Hat / CentOS / Fedora . вторая — Debian / Ubuntu.

Источник

LaurVas

Chroot-окружение — это самый доступный способ запустить линукс внутри линукса (т.н. контейнер). Внутренняя система будет изолирована от основной только на уровне корневой файловой системы (rootfs). Сетевой стэк, псевдо-файловые системы /proc , /sys , /dev будут общими для хоста и контейнера. Поэтому не стоит считать chroot-окружение достаточной мерой для изоляции опасных/недоверенных приложений. Для этого больше подходит systemd-nspawn или docker.

• Из chroot-окружения можно убивать процессы хоста.
• Система из chroot-окружения имеет доступ к дисковым устройствам. Являясь рутом в контейнере, можно примонтировать блочное устройство хоста (какой-нибудь /dev/sda1 ) и делать с ним всё что угодно.

Если chroot так несовершенен, то зачем он нужен сегодня?

Не всё работает в systemd-nspawn контейнере. Из-за усиленных защитных мер в контейнере systemd-nspawn нельзя натянуть файл на петлевое устройство (loop device) и нельзя запустить ещё один контейнер (линукс внутри линукса внутри линукса). В чруте можно и то, и другое. Это может понадобится, например, для сборки livecd.

Не везде есть systemd. Таких дистрибутивов почти не осталось. Это либо что-то старое, либо Gentoo или Alpine. Chroot работает везде.

Дальше я расскажу как создать контейнер с Debian-based системой (Debian, Ubuntu, Kali). Делать надо то же самое, что и при создании systemd-nspawn контейнера, но есть небольшие отличия.

Нам понадобятся…

Для запуска контейнера ничего дополнительного не требуется.

Запускать 32-битную систему можно как из 32-битной, так и из 64-битной. А вот 64-битную из 32-битной нельзя.

Для создания контейнера с Debian/Ubuntu понадобится утилита debootstrap из одноимённого пакета. Он точно есть в Debian, Ubuntu, Archlinux и Gentoo. Наверняка есть и в других дистрибутивах. В конце концов это всего лишь набор shell-скриптов.

Шаг 1. Debootstrap

Debootstrap разворачивает в указанном каталоге минимальный набор пакетов, необходимый для самостоятельной работы системы. Это самый важный шаг. Если сейчас допустить ошибку, то всё придётся переделывать сначала. Инструкцию я вынес в отдельный пост debootstrap.

Рекомендую сделать бэкап сразу после этого шага, чтобы в случае чего можно было откатиться назад, а не переделывать всё с начала. Ну, как в компьютерной игре сохраниться. Я разворачиваю Debian Jessie, поэтому мои бэкапы содержат jessie в названии. Команды подсмотрены в Ubuntu community help wiki.

Здесь jessie — это каталог с корнем chroot-системы.

Наибольшее сжатие будет у .tar.xz архива, самое быстрое у tar.gz . Посередине находится tar.bz2 . У меня в цифрах получилось так:

Сжатие	Размер архива, MiB	Время компрессии, с
gzip	91	7.5
bzip2	83	16.6
xz	68	68.2

Восстановление из бэкапа:

Шаг 2. Вход в систему (chroot)

Чтобы процессы из chroot-окружения могли полноценно работать, необходимо примонтировать псевдо-файловые системы /proc , /sys , /dev внутрь контейнера:

/dev/pts — виртуальная файловая система, которая динамически создаёт файлы терминалов /dev/pts/X для каждого нового подключения. Это необходимо для нормального функционирования многих программ, работающих с терминалом, в т.ч. скриптов debconfig.

После того, как всё необходимое смонтировано, входим в контейнер:

Стоп, так делать не надо! Такой чрут потянет за собой переменные окружения из внешней системы (проверяется командой env ). Вот правильный чрут:

Всё, мы внутри! В дальнейшем по тексту я буду отмечать чрутовый шелл приглашением (chroot)# .

Можно ли поиметь сразу несколько терминалов для одного chroot-окружения? Да, просто делаем ещё один точно такой же чрут и получаем второй терминал. Повторно монтировать ничего не надо.

Шаг 3. Первичная настройка системы

Задаём пароль рута:

Устанавливаем часовой пояс:

Если создать файл /etc/debian_chroot с именем гостевой ОС, то bash будет выводить его в начале приглашения командной строки. Это позволит определить какой терминал в какой системе находится, поскольку хостнэйм у контейнера такой же, как у хоста.

В чруте будет как-то так (white — имя моей основной системы):

Чтобы df корректно работал, нужно сделать mtab:

Сеть должна работать без дополнительных манипуляций. Проверяем:

Если возникли проблемы с DNS, берём /etc/resolv.conf с основной системы:

• Вы можете не использовать echo , а раскомментировать необходимые локали в /etc/locale.gen вручную.
• Вместо en_US.UTF-8 можно прописать ru_RU.UTF-8 , тогда всё будет по-русски.
• Последние 3 команды можно заменить интерактивной dpkg-reconfigure locales .

Проверяем список доступных локалей и текущую локаль:

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

• Вручную проэкспортировать все необходимые переменные окружения через шелл:

• Входить в чрут по ssh. Вариант рабочий, но неудобный, т.к. требует запущенного ssh-сервера в чруте.

Конфигурируем менеджер пакетов

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

/etc/apt/sources.list для Debian Squeeze

Спортсмены отключают установку рекомендованных пакетов:

Мне нравится устанавливать и обновлять пакеты без подтверждения Do you want to continue? [Y/n] . Ведь если я приказал установить пакет, значит я в этом уверен и не надо переспрашивать. К тому же так быстрее получается. Отключаем подтверждение:

В простейшей конфигурации контейнера гостевая и хостовая система используют один и тот же сетевой стэк. Это значит, что если 22 порт уже занят ssh-сервером хостовой системы, то ssh-сервер гостевой системы не запустится. Необходимо в его настройках изменить номер порта. Это же справедливо для веб-серверов и прочих сервисов, работающих на стандартных портах.

Чтобы сервисы не стартовали сразу после установки пакетов:

Самое время сделать второй бэкап:

Чтобы архив занимал меньше места, мы исключаем:
/var/cache/apt/archives/*.deb — кэш deb-пакетов apt’а
/var/lib/apt/lists/* — сохранённые индексы репозиториев (что лежит в таком-то репозитории)
/var/cache/apt/*.bin — какая-то база данных apt’а

Шаг 4. Доведение до ума

Дополнительные пакеты, которые могут понадобиться:
build-essential для сборки deb-пакетов
cron — планировщик задач
file — утилита для определения типа файла
less — утилита просмотра текста с возможностью скроллить
logrotate
nano — простенький консольный текстовый редактор
ncurses-term для поддержки терминала rxvt-unicode-256color и других
openssh-server
rsync для синхронизации файлов и каталогов, в т.ч. по сети
sudo
vim или vim-tiny
zsh

Напоминаю, что посмотреть описание пакета можно командой

Чтобы получать zsh вместо bash, входить в контейнер нужно так:

Создаём пользователя vas, входящего в группу sudo . Вы можете создать другого 🙂

Переключение с рута на пользователя делается командой:

Иногда бывает удобно сделать sudo без ввода пароля. На хостовой системе я себе таких шалостей не позволяю, а в контейнере можно. Только не редактируйте /etc/sudoers напрямую! Используйте команду visudo .

Разрешаем sudo без пароля для всех пользователей, входящих в группу sudo :

В качестве вишенки на торте возьмём zshrc, vimrc и т.п. с хостовой системы.

Можно немного облегчить систему за счёт man-страниц, документации, локалей. Это для особо целеустремлённых спортсменов.

И последний бэкап на сегодня:

Всё, контейнер jessie готов к работе в chroot-окружении! Благодаря бэкапу, в любой момент можно откатиться к чистому состоянию или сделать ещё несколько однотипных контейнеров.

Размонтируем примонтированное, если контейнер пока не нужен:

Иногда что-то не хочет размонтироваться. Так бывает, когда в чруте остались работающие процессы. Их надо найти и убить.

Первое, что приходит в голову — поискать pid-файлы сервисов:

Pid-файлы есть только у сервисов, а ведь могут остаться и другие процессы. А как их найти? Посмотрим в ядре!

Здесь цикл проходит по всем процессам и смотрит их параметр root , который является симлинком на корневую ФС процесса. Если симлинк ведёт в каталог нашего контейнера ( /home/chroot/jessie в моём случае), печатается PID этого процесса. С помощью xargs вывод цикла превращается в аргументы для команды ps, чтобы показать вам процессы в удобном виде. Замените ps на kill , чтобы прибить их.

Некоторые процессы могут не захотеть умирать добровольно, тогда вам нужен смертельный kill -9 .

Шаг 5. Использование готового контейнера

В принципе вы его уже использовали, пока готовили. Но предположим, что он какое-то время лежал без дела и вдруг понадобился. Тогда первым делом монтируем всё необходимое:

Если чрут будет использоваться регулярно, то имеет смысл настроить автоматическое монтирование (через /etc/fstab ), чтобы не набивать эти команды руками.

После правки fstab проверим что всё монтируется как положено:

Входим в контейнер:

и занимаемся в нём своими делами. Если надо запускать какие-то сервисы, то пуск и останов через systemd работать не будет. Однако старые добрые init-скрипты работают. Пример запуска ssh-сервера в чруте:

Источник

• chroot

chroot on Unix-like operating systems is an operation that changes the apparent root directory for the current running process and its children.

Basic Installation

Building a «chroot» is very easy in Debian.

You will need:

• Install the required packages

Either select a close network mirror manually, use one of the dns based mirrors such as ftp.XX.debian.org where XX is your geographic country code, or use the deb.debian.org CDN which will do this for you automatically. The deb.debian.org is easier to document and becoming the generally preferred method and is therefore recommended if you don’t have your own fast preferred local mirror. See http://deb.debian.org/ for documentation and details.

• To enter (see below for configuration that may be required within the chroot):

A more convenient way to enter the chroot is provided by the schroot package. This wrapper allows unprivileged users to have access to one or more chroot environments. schroot handles the chroot(2) call as well as dropping privileges inside the chroot, setting up /etc/resolv.conf and bind mounting resources into the chroot (like home directories, /dev, /sys, /proc).

Configuration

In general, it is necessary to create/edit key configuration points.

Create a /usr/sbin/policy-rc.d file IN THE CHROOT so that dpkg won’t start daemons unless desired. This example prevents all daemons from being started in the chroot.

The ischroot command is buggy and does not detect that it is running in a chroot (685034). Several packages depend upon ischroot for determining correct behavior in a chroot and will operate incorrectly during upgrades if it is not fixed. The easiest way to fix it is to replace ischroot with the /bin/true command.

Configuring a chroot is relatively static and very specific, it may be possible to dispense with the command «top-level» and directly edit files.

• Users defined in the chroot

• Settings network settings in the chroot

• Mounts filesystems from the underlying host (NOT in the chroot)

• To edit the bash prompt, add an identifier to /etc/debian_chroot. It’s contents get added to $PS1

Mounting pseudo filesystems

• Check the chrooted system the presence of /proc if the chroot is not likely to be fully operational. A priori, since version debootstrap Debian/Wheezy integrates natively mount /proc and /sys

/dev/pts

It is also advisable to do a «bind» /dev/pts. This prevents error messages like Must be connected to a terminal or Can not access '/dev/pts/0': No such file or directory of this type with using the control screen.

In this case, the primary system, run the command:

Default Configurations

Generally the file /etc/fstab might look like this:

Therefore mount on the primary system would be:

Adding / removing packages

• Eliminate unnecessary packages (all depends on the purpose of the chroot)

Complementary list svgalibg1 whiptail

• Add a little comfort

Usage

Common examples of chroot usage:

Recompiling application in a context other than the machine that hosts the chroot (backport, cross-compiling, . )

Update service production by tilting the old service (host machine) to the new (installed in the chroot)

Securing a service «chrooted» from the host machine (and vice versa)

Copy and Paste

The above ready for copy and paste.

First the part where we set shell variables.

From here the further copy and paste stuff, preferable careful.

# Entering the chroot, leave it with exit

TODO — Clean up from French translation.

Источник