Ssh chroot. настройка домашнего каталога для sftp

Настройка SFTP доступа

Если по какой-то причине потребовалось дать удаленный доступ к файлам на компьютер под управлением операционной системы из семейства Linux, то безопаснее всего будет это сделать через SFTP. SFTP обозначает SSH File Transfer Protocol, и не имеет никакого отношения к обычному FTP протоколу, а так же в разы безопаснее. Однако, приступим к настройке.

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

Создаем нового пользователя:

useradd -m -s /sbin/nologin crazyadmin

-m — указывает необходимость создать домашнюю директорию пользователя в каталоге /home; -s — задает оболочку пользователя — /sbin/nologin запрещает пользователю использовать shell.

crazyadmin — имя пользователя

Устанавливаем созданному пользователю пароль:

passwd crazyadmin

Если что-то пошло не так, то всегда можно удалить пользователя командой userdel username, например:

userdel crazyadmin

И создадим для нового пользователя папку chroot, о её предназначении будет рассказано ниже.

mkdir /home/crazysadmin/chroot

Настройка сервера SSH

Теперь отправляемся в конфиг SSH — /etc/ssh/sshd_config

Ищем следующую строчку:

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

и меняем на

Subsystem sftp internal-sftp

Теперь отправляемся в самый конец конфига, и там дописываем:

Match User crazyadmin X11Forwarding no AllowTcpForwarding no AllowAgentForwarding no PermitTunnel no ForceCommand internal-sftp ChrootDirectory %h/chroot

ChrootDirectory — родительский каталог той папки, к которой мы хотим открыть доступ по SFTP. В данном примере используется директория chroot, которая лежит в папке пользователя.

Если на вашем сервере настроен доступ по SSH только через файл ключа, а нужно сделать возможность заходить по паролю, то тогда дописываем еще следующее:

PasswordAuthentication yes

После завершения всех манипуляций с SSH сервером, его нужно перезагрузить:

service ssh restart

Настройка директорий для пользователя SFTP

Отправляемся в директорию /home и там ищем папку свежесозданного пользователя, а в ней папку chroot. Устанавливаем её владельцем пользователя root:

chown root:root /home/crazyadmin/chroot

Устанавливаем нужные права на папку:

chmod 755 /home/crazyadminВнимание! Ни в коем случае не следует выставлять ChrootDirectory какие-либо другие права, в таком случае будет выскакивать следующая ошибка: fatal: bad ownership or modes for chroot directory component.

Теперь представим, что нам нужно предоставить доступ к нескольким папкам, и они все лежат за пределами ChrootDirectory. Выход из ситуации следующий:

Допустим нам нужно разрешить доступ к папке /var/www/sysadmin.ru. Создаем в домашнем каталоге пользотвателя /home/crazyadmin папку с названием sysadmin.ru.

mkdir /home/crazyadmin/sysadmin.ru

Теперь смонтируем в эту папку ту директорию, доступ к которой нам нужно обеспечить:

mount —bind /var/www/sysadmin.ru/ /home/crazyadmin/sysadmin.ru/chroot

Выставляем необходимые для редактирования права для нашей директории /var/www/sysadmin.ru:

chmod 777 /var/www/sysadmin.ru find /var/www/sysadmin.ru -type f -exec chmod 664 {} + find /var/www/sysadmin.ru -type d -exec chmod 777 {} +

Если в процессе монтирования директории что-то пошло не так, то можно убрать монтирование командой unmount:

umount /home/crazysyadmin/sysadmin.ru

На этом настройка SFTP сервера завершена.

Частые ошибки

  • fatal: bad ownership or modes for chroot directory component — как писалось выше, данная ошибка появляется тогда, когда владельцем ChrootDirectory является не пользователь root, и права не равны 755.
  • No supported authentication methods available (server sent public key) — сервер настроен на авторизацию по ключу. Если нужна авторизация по паролю, то в конфиге /etc/ssh/sshd_config нужно поменять значение у переменной PasswordAuthentication с no на yes, а после перезапустить сервер командой service ssh restart.

Источник: https://sysadmin.ru/articles/nastrojka-sftp-dostupa

Chroot-окружение SSH/SFTP

С версии 4.8 OpenSSH нативно поддерживает установку chroot-окружения и для этого больше не нужны патчи. Эта статья описывает настройку chroot-окружения для ваших пользователей при использовании SSH/SFTP. Пользователь будет “заперт” в своем каталоге без возможности доступа к основной системе

Описывается настройка chroot-окружения для OpenSSH версии 4.8 для Debian Lenny Для примера я буду использовать пользователя boombick с домашней директорией /home/boombick. Пользователь boombick входит в группу users. Chroot-окружение будет ограничено директорией /home Установка OpenSSH Если OpenSSH-сервер еще не установлен в вашей системе, то установите его командой

# aptitude install ssh openssh-server

Включить SFTP-доступ очень просто. Отредактируйте файл /etc/ssh/sshd_config следующим образом:

# vim /etc/ssh/sshd_config[…]
Subsystem sftp /usr/lib/openssh/sftp-server
[…]

и добавьте в конец файла следующие строки (для каждого пользователя, которого вы хотите поместить в chroot):

[…]
Match User boombick ChrootDirectory /home AllowTCPForwarding no X11Forwarding no ForceCommand /usr/lib/openssh/sftp-server

… либо для группы пользователей:

[…]
Match Group users ChrootDirectory /home AllowTCPForwarding no X11Forwarding no ForceCommand /usr/lib/openssh/sftp-server

Последний вариант поместит всех пользователей, входящих в группу users, в chroot Перезапустите ssh-сервер

# /etc/init.d/ssh restart

Если вы настраиваете chroot для нескольких пользователей в одну директорию (/home в нашем примере) и не хотите, чтобы они просматривали личные директории друг друга, то не забудьте присвоить верные права для директорий:

chmod 700 /home/boombick

Теперь вы можете зайти на сервер при помощи SFTP-клиента и работать в chroot-окружении. SSH в chroot-окружении

Настройка chroot для SSH более трудоемка из-за того, что необходимо настроить еще и программное окружение, то есть поместить в chroot такие программы как /bin/bash, /bin/cp и т. д.

Это значит, что мы должны будем скопировать эти программы и библиотеки, которые они используют, в наше chroot-окружение.

Вы можете сделать это вручную, с помощью команды cp, а узнать список библиотек вам поможет команда ldd:

# ldd /bin/bash linux-gate.so.1 => (0xb7fbd000) libncurses.so.5 => /lib/libncurses.so.5 (0xb7f75000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7f71000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7e0f000) /lib/ld-linux.so.2 (0xb7fbe000)

Также надо создать системные устройства /dev/null, /dev/zero, /dev/tty и /dev/urandom.

Это можно сделать командой mknod Но делать это вручную весьма утомительно 🙂 Хорошо, что есть люди, которые помогли облегчить нам эту процедуру.

Wolfgang Fuschlberger написал bash-скрипт, который позволяет автоматизировать процесс создания chroot-окружения. Для начала установим некоторые необходимые пакеты:

aptitutde install sudo debianutils coreutils

Затем скачаем скрипт, пометим его в /usr/local/sbin сделаем его исполняемым

chmod 700 /usr/local/sbin/make_chroot_jail.sh

Но перед стартом добавим некоторые приложения, которые мы хотим сделать доступными для использования в chroot, например, vim

vim /usr/local/sbin/make_chroot_jail.sh[…]
elif [ «$DISTRO» = DEBIAN ]; then APPS=»/bin/bash /bin/cp /usr/bin/dircolors /bin/ls /bin/mkdir /bin/mv /bin/rm /bin/rmdir /bin/sh /bin/su /usr/bin/groups /usr/bin/id /usr/bin/rsync /usr/bin/ssh /usr/bin/scp /sbin/unix_chkpwd /usr/bin/vim»
else
[…]

Затем создадим симлинк в /home, указывающий на сам /home

cd /home
ln -s . home

Теперь можно запускать скрипт. Его запускают со следующими параметрами

make_chroot_jail.sh username [/path/to/chroot-shell [/path/to/chroot]]

chroot-shell – это специальная оболочка для пользователей в chroot, которую создает скрипт. Но OpenSSH поддерживает chroot нативно, поэтому мы будем использовать обычный /bin/bash или /bin/sh Не имеет значения, существует ли пользователь в системе или нет. Если пользователя нет, то он будет создан. Если есть – его данные будут обновлены.

# make_chroot_jail.sh boombick /bin/bash /home

Эта команда создаст/обновит данные пользователя boombick для его работы в chroot Для обновления всех файлов/библиотек в chroot выполните

make_chroot_jail.sh update /bin/bash /home

Теперь немного подредактируем конфиг (примерно так же, как мы делали для SFTP)

vim /etc/ssh/sshd_config

И добавим следующие строки для каждого пользователя в chroot

[…]
Match User boombick ChrootDirectory /home AllowTCPForwarding no X11Forwarding no

Или для группы пользователей

[…]
Match Group users ChrootDirectory /home AllowTCPForwarding no X11Forwarding no

Разница в том, что мы не добавляем строку ForceCommand /usr/lib/openssh/sftp-server в выражение Match Таким образом пользователи могут использовать не только chroot-SFTP (убедитесь, что в /etc/ssh/sshd_config есть строка Subsystem sftp /usr/lib/openssh/sftp-server) Не забудьте перезапустить ssh-сервер

# /etc/init.d/ssh restart

Источник: http://docs.mirocow.com/doku.php?id=system:chroot_ssh

lshell — отличная альтернатива chroot для ограничения возможностей пользователей, приходящих по ssh и sftp (с дополнительной помощью MySecureShell)

chroot — это, по сути, процесс (и соответствующая команда) для изменения корневой директории для пользователя. Незаменим в ситуации, когда, например, требуется запустить незнакомую программу.

А также в тех случаях, когда надо пустить на сервер пользователя, дав ему возможность использовать железо на в полную мощность (т.е.

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

Недостаток chroot в том, что для запертого в нём пользователя, требуется собирать какое-то минимальное окружение. Например, копировать в виртуальный корень файл /bin/bash и все связанные файлы для того, чтобы у пользователя появилось приличное окружение.

Грубо говоря, в виртуальный корень придётся скопировать часть основной системы.

Это приводит к дублированию данных (например, на VPS для этого может не быть лишнего дискового пространства), усложняет обновления (если в настоящий системе обновились какие-то файлы, то их свежие копии вручную придётся копировать в chroot-окружение) и пр.

Мне захотелось как-то избавиться от этих неудобств. Притом пользователей надо было пускать в консоль только для того, чтобы они могли с помощью tar и mysqldump делать резервные копии своих сайтов и баз данных.

Нашлось изящное решение — lshell.

Это пользовательский шел который разрешает залоснившемуся пользователю выполнять строго разрешённые команды. Он есть в стандартных репозиториях Ubuntu 10.10 и установить его можно так:
sudo apt-get install lshell

Теперь создадим пользователя, права которого надо сурово ограничить:

После этого, в для любого пользователя задать новую оболочку командой:
sudo adduser john

Утилита попросит вас задать пароль и указать личные данные пользователя (их можно не вводить и оставить пустыми, тупо нажимая Enter). Для нового пользователя автоматически будет добавлен домашний каталог /home/john.

А мы установим ему нужную оболочку:
sudo usermod -s /usr/bin/lshell john

Отредактируем файл настрое lshell так, чтобы разрешить нашему новому юзеру выполнять строго определённый набор команд:
sudo nano /etc/lshell.conf

В конец файла добавим:
[john] sftp : 1 # можно соединяться по sftp allowed : ['cd','exit','ls','tar','mysqldump','mysql'] # только эти команды можно выполнять forbidden : [';', '&','`','$(', '${'] # эти управляющие символы запрещены

path : ['/var/www'] # можно кроме домашнего каталога ходить и по указанному пути

Сохраним файл (проще всего нажать F2 для этого).

И испытаем, что же дозволено нашему новичку, зайдя под ним на сервер через ssh:
ssh john@localhost

Если увидим следующее, то значит всё получилось:
You are in a limited shell. Type '?' or 'help' to get the list of allowed commands

john:~$

Набрать действительно help стоит для того, чтобы узнать, какие команды разрешено исполнять пользователю в этой оболочке. Кроме этого рекомендую набрать lpath, чтобы проверить, какие пути доступны пользователю. В частности, наш пользователь может перейти в указанную директорию за приделами его домашней: cd /var/www

Всё здорово.

Сразу вас предостерегу: не разрешайте пользователю запускать bash или, например, mc, добавляя их в перечень разрешенных команд — внутри всякого рода оболочек пропадут ограничения и пользователь сможет бродить по всему диску (т.е.

lshell отслеживает и ограничивает только пути, указываемые в параметрах командной строки). Это нормально, если пользователю надо многое разрешить (тот же bash целиком, например), то следует настраивать chroot.

Но есть другого рода проблема: если вы попытаетесь зайти от имени john по протоколу SFTP на сервер от имени юзера, то вас туда пустит (не зря устанавливали в конфиге sftp : 1), но ограничены вы там никак не будите. То есть тоже сможете облазить всю файловую систему, а мы же так старательно с этим боролись.

OpenSSH позволяет делать chroot и для sftp, но если этой возможностью воспользоваться, то не доступной окажется сама оболочка /usr/bin/lshell. Поэтому есть немного кривой, но гарантированно работающий метод: надо отдать обработку sftp соединений стороннему демону (а не OpenSSH).

Читайте также:  L2tp vpn-сервер на centos 7. установка и настройка сервера впн

Есть достойный кандидат: MySecureShell.

Для его установки надо добавить репозитории. В конец файла /etc/apt/sources.list добавляем:
deb http://mysecureshell.free.fr/repository/index.php/ubuntu testing main
deb-src http://mysecureshell.free.fr/repository/index.php/ubuntu testing main

Потом добавляем ключ этого репозитория:
gpg —keyserver hkp://pool.sks-keyservers.net —recv-keys E328F22B; gpg —export E328F22B | sudo apt-key add —

Обновляем список пакетов и устанавливаем нашего героя:
sudo apt-get update
sudo apt-get install mysecureshell

После установки демон сам запустится. Конфиг его, если что, лежит тут: /etc/ssh/sftp_config

Но там можно ничего не менять (по умолчанию выполняется chroot), зато надо научить OpenSSH при sftp соединении отправлять пользователя к MySecureShell.

Для этого правим /etc/ssh/sshd_config, находим там примерно такую строку:
Subsystem sftp /usr/lib/openssh/sftp-server

И заменяем её на:
Subsystem sftp /bin/MySecureShell -c sftp-server

Сохраняем файл, перезапускам демона:
service ssh resrart

Готово, можно заходить от имени john по sftp и радоваться тому, как в качестве корня файловой системы пользователю виден его домашний каталог. При этом в /var/www доступа по sftp не будет. Если вдруг очень хочется его туда пустить и по sftp, то можно предпринять следующее:
mkdir /home/john/www chmod 777 /home/john/www

mount /var/www /home/john/www -o bind

Настоящая директория /var/www примонтируется как поддиректория в домашний каталог пользователя.

»

Источник: http://aboutubuntu.ru/content/chroot-vs-lshell-and-mysecureshell.html

Доступ к сайту по sftp вместо обычного ftp с ограничением директории

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

Введение

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

В один прекрасный день решили обновить один из сайтов. Попросили предоставить доступ к исходникам. В принципе, ничего сложного, думал за 5-10 минут все сделаю. Пошел по простому пути. Решил настроить ftp сервер, благо совсем недавно написал обширную статью на эту тему.

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

Тут началось самое интересное. Я давно не работал с ftp и подзабыл как там с ним и что. А проблем с ним навалом. Простого проброса 21-го порта недостаточно. Я не смог подключиться извне ни в активном, ни в пассивном режиме.

На сервере установлен firewall pf, я с ним не очень знаком, почти не работал. Стал читать, как организуют проброс ftp на нем.

Оказалось, что необходимо поднять локальный FTP proxy, редиректить на него все подключения и он динамически будет создавать правила для корректной работы ftp.

Мне очень не понравились перспектива ковырять незнакомый фаервол с кучей правил. К тому же нельзя было допустить ошибку и нарушить работу шлюза. Но делать нечего, решил попробовать. Информации в интернете не очень много на эту тему. По тем примерам, что мне попались не смог корректно настроить. То в синтаксисе ошибка, то просто не работает.

Решил не терять время на ковыряния не нужного для меня фаервола и пойти другим путем. Естественно, подумал сразу на sftp. Там нет таких проблем с пробросом портов. Единственное, чего я не делал раньше, так это ограничение доступа по sftp в пределах какого-то каталога. Но как оказалось это не сложно, задача легко и быстро решается.

Добавляем пользователя ssh в chroot директорию

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

# useradd -s /sbin/nologin sftpuser

Дальше редактируем конфиг ssh. Открываем /etc/ssh/sshd_config. Комментируем существующую строку и добавляем следом за ней еще несколько:

# mcedit /etc/ssh/sshd_config#Subsystem sftp /usr/libexec/openssh/sftp-server
Subsystem sftp internal-sftp
Match User sftpuser
ChrootDirectory /var/www/site.ru
ForceCommand internal-sftp

Сохраняем и перезапускаем ssh. В случае с centos 6 команда такая:

# service sshd restart

Настройка подключения sftp с ограничением доступа за пределами конкретной папки закончена.

Ошибка ssh bad ownership or modes for chroot directory

Можно пробовать подключаться через sftp клиент. Я в данном случае предпочитаю пользоваться бесплатным WinSCP. Скорее всего вы не подключитесь и получите ошибку в лог файле /var/log/secure:

Apr 11 14:53:20 web sshd[5026]: Accepted password for sftpuser from 75.37.234.139 port 40923 ssh2
Apr 11 14:53:20 web sshd[5026]: pam_unix(sshd:session): session opened for user sftpuser by (uid=0)
Apr 11 14:53:20 web sshd[5028]: fatal: bad ownership or modes for chroot directory «/var/www/site.ru»
Apr 11 14:53:20 web sshd[5026]: pam_unix(sshd:session): session closed for user sftpuser

Ошибка возникает, если владелец необходимой папки не root и права доступа на запись есть у кого-то еще, кроме владельца. Такой вот нюанс. В этом есть некоторое неудобство, но в данном случае лично мне это не помешало. Делаем владельцем каталога /var/www/site.

ru рута, у остальных убираем права на запись в него. Дальше в этом каталоге две папки — одна с логами веб сервера для виртуального хоста, другая с исходниками сайта. На эти папки может быть любой владелец и права доступа.

Так что подключившийся пользователь сможет без проблем работать с исходниками сайта.

Заключение

На смену ftp приходит sftp. Я давно пользуюсь этим для доступа к отдельным файлам на сервере. Но есть большой минус — скорость по sftp низкая. Когда приходится качать что-то объемное, начинаешь грустить.

Это нужно учитывать. Для работы с исходниками сайтов существующей скорости вполне достаточно. Для передачи объемных файлов нужно искать другие варианты подключения, тот же ftp, либо через vpn cifs или nfs.

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

Помогла статья? Есть возможность отблагодарить автора

Источник: https://serveradmin.ru/dostup-k-saytu-po-sftp-vmesto-obyichnogo-ftp/

How can I chroot sftp-only SSH users into their homes?

I spent the whole day trying to get a network share on my raspberry. I wanted to lock the user so that it would not be able to navigate through the whole file system, no ssh login access and I wanted to have write access to the network share.

First I created a user:

sudo useradd netdrive

Then edited /etc/passwd and made sure it has /bin/false for the user so the line was:

netdrive:x:1001:1004:Net Drive User,,,:/home/netdrive:/bin/false

I edited /etc/ssh/sshd_config to include:

Match User netdrive ChrootDirectory /home/netdrive ForceCommand internal-sftp AllowTcpForwarding no X11Forwarding no

Changed home directory owner and permissions:

sudo chown root:root /home/netdrive/
sudo chmod 755 /home/netdrive/

Ok so after all this I was able to connect using sshfs but in read only mode. What I had to do to get a writable folder:

sudo mkdir -p /home/netdrive/home/netdrive/
sudo chown netdrive:netdrive /home/netdrive/home/netdrive/
sudo chmod 755 /home/netdrive/home/netdrive/

That was it, it worked without any further changes. Note that I have only writable permissions to the user, not to the group as many other solutions online. I was able to create/delete/edit/rename files/folders without problems.

When accessing using sshfs with the netdrive user because of chroot configuration I would only see things stored inside server's /home/netdrive/ directory, perfect. The repeated /home/netdrive/home/netdrive/ directory structure is what made it work for me in having a clean chroot ssh writable solution.

You should probably not execute the following paragraphs:

After looking at the above solutions (and many others on the net which even used acl (access control lists)) I was still not able to get it working because what I did next was:

The following did NOT work for me:

sudo mkdir /home/netdrive/writable/
sudo chown netdrive:netdrive /home/netdrive/writable/
sudo chmod 755 /home/netdrive/writable/

Because the netdrive user was still not able to write in that /home/netdrive/writable/ directory despite owning the folder and having the permissions.

Then I did: sudo chmod 775 /home/netdrive/writable/ And now I could create a directory and delete it but I was not able to edit it because it was being created without group writable permissions. Here from what I saw on the net people use acl to fix it.

But I was not happy with that since it I had to install acl, then configure mount points, etc. Also I have no idea why I would need group permission to write to a folder owned by the same user.

It seems that for some reason creating /home/netdrive/home/netdrive and giving ownership to the last netdrive folder I was able to make everything work without messing with group permissions.

Источник: https://askubuntu.com/q/134425

SSH FTP (SFTP) instead/вместо FTP

Недавно передо мной предстала задача организовать доступ к файлам сервера. Точнее доступ был, но по каким-то причинам FTP сервер перестал работать.

Разбираться в причинах было лень, и тем более, давно хотелось заменить протокол FTP чем нибудь по надёжнее.

Вам, Уважаемое хабрасообщество, да будет известно, что FTP передаёт данные в не шифрованном виде.

И нам, параноикам мира сего, немного сцыкотно страшно за сервер наш и данные на нём хранящиеся.

По этому решил полностью отказаться от FTP в пользу SFTP.

Я использую Ubuntu Server, и по умолчанию установленный в нём OpenSSH, также мне известно, что он поддерживает SFTP из коробки, поэтому задача казалась мне крайне простой и я быстро приступил к воплощению её в жизнь.

С той же скоростью, с которой выполнялась задача, я столкнулся с досадным фактом того, что OpenSSH по умолчанию даёт пользователю доступ ко всей файловой системе, то есть к / — корню.

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

Тут я подробно расскажу как тюнинговать OpenSSH сервер в Ubuntu Linux для того что бы chroot-нуть пользователя в необходимом нам каталоге.

Почему я говорю тюниговать? — Да просто по тому, что, как я уже сказал, для работы SFTP достаточно всего лишь выполнить:

Читайте также:  Диспетчер задач отключен администратором. как разблокировать диспетчер задач. использование avz для включения диспетчера задач

sudo aptitude install openssh-server

Что приведёт к установке и запуску сервера, а также откроет, по умолчанию, 22 порт. Осуществив соединение на который, при помощи, например Filezilla, можно получить доступ к файловой системе удалённого компьютера/сервера по ШИФРОВАННОМУ протоколу.

Но как я уже намекнул, настройки «по умолчанию» нас не устраивают.

Поэтому открываем файл настройки OpenSSH сервера sudo mcedit1 /etc/ssh/sshd_config и кое-что там изменяем/добавляем.

Находим опцию Subsystem и придаём ей следующий вид:

Subsystem sftp internal-sftp

Плюс добавляем следующие опции:

Match User test ChrootDirectory %h

ForceCommand internal-sftp

Теперь перезапускаем OpenSSH sudo service ssh restart и вроде бы готово.

Game Over?

NO!

Как Вы наверное уже догадались, право входа в систему по протоколу SFTP будут иметь пользователи которые имеют системные2 учётные записи. Поэтому необходимо создать учётную запись, под которой будут осуществляться манипуляции с файлами. Поскольку выше было написано Match User test создавать необходимо учётную запись пользователя test.

adduser test

Создается пользователь, задаётся пароль, домашний каталог по умолчанию — /home/test ..

Теперь можно попробовать соединиться с сервером, и передать файлы. Предварительно заходим в логи, что бы наблюдать за процессом…

tail -f /var/log/auth.

log
timestamp host sshd[2558]: Accepted password for test from IP_адрес port 59667 ssh2
timestamp host sshd[2558]: pam_unix(sshd:session): session opened for user test by (uid=0)
timestamp host sshd[2596]: fatal: bad ownership or modes for chroot directory «/home/test» timestamp host sshd[2558]: pam_unix(sshd:session): session closed for user test

Как видите, в логах написано: — сессия открыта для пользователя test используя UID=0, то есть идентификатор пользователя root

— неправильные права собственности для того, что бы chroot-нуться в /home/test

Всё дело в том, что для каталога /home/test необходимо назначить владельцем пользователя root, что мы и делаем:

sudo chown root /home/test
Подключается и наблюдаем в логах:

timestamp host sshd[2630]: Accepted password for test from IP_адрес port 50152 ssh2 timestamp host sshd[2630]: pam_unix(sshd:session): session opened for user test by (uid=0)

timestamp host sshd[2669]: subsystem request for sftp

Mission complete

Подробности

В настройках OpenSSH мы описывали опцию Match User test, что само собой означает доступ отдельного, конкретного пользователя! — А если таковых много?

Описание каждого пользователя — как минимум не кошерно… Короче, я хочу рассказать про то, что можно задействовать группы пользователей используя Match Group.

И тогда конфиг может выглядеть приблизительно так:

Match Group sites ChrootDirectory /srv/www%h ForceCommand internal-sftp

А учётные записи пользователей в /etc/passwd так:

site1:x:5000:10003::/example.com/:/bin/false site2:x:5001:1000::/example.org/:/bin/false site3:x:5002:1000::/example.net/:/bin/false
Как видно из примера, у пользователей относительный домашний каталог, то есть в корне / нет каталогов /example.com/ и т.д.
Эти каталоги есть в /srv/www/ и OpenSSH должен отработать следующим образом:
— Домашний каталог пользователя, из /etc/passwd добавить к /srv/www и в итоге получить /srv/www/example.com и т.д. Не забываем, что владельцем каталога в который будут chroot-иться пользователи должен быть root. Группой владельцев, необходимо поставить sites и разрешить полный доступ. Также рекомендуется в качестве shell-а пользователя ставить /bin/false, что бы предотвратить доступ пользователя к командной строке.

Пояснения: 1 — mcedit — Мой любимый текстовый редактор. 2 — системные учётные записи — читать как: Созданные в системе пользователи. 3 — 1000 — всего лишь пример идентификатора группы sites

Mission Complete & Game Over

Источник: https://habr.com/post/89473/

sshfs/sftp chroot « Debian.pro

Несколько месяцев я задавался вопросом — как организовать chroot для sftp на сервере. И долгое время не мог этого сделать — приходилось обходиться средствами FTP-демонов.

В одном из последних релизов openssh-server эта возможность появилась, с чем я поздравляю всех хостеров (да и просто администраторов).

В то время, пока Red Hat’овцы всё ещё мучаются с jail — мы пойдём настраивать chroot встроенными средствами ssh-демона.

Для начала определимся для чего нужен SFTP. Сам sftp призван заменить архаичный scp — старое средство передачи файлов по ssh. Преимущества вполне очевидны — файлы передаются по зашифрованному туннелю, пароль из сети перехватить невозможно.

Но тут же всплывают и минусы — увеличенная нагрузка на CPU (и на сервере, и на клиенте), медленная скорость передачи файлов по сравнению с FTP.

Но в целом — sshfs достаточно давно используется и зарекомендовала себя как отличная замена FTP-демонам.

Из плюсов так же стоит отметить простоту конфигурации — любой пользователь в системе, который может зайти на сервер по ssh, уже может зайти по sftp на сервер. С другой стороны это было и минусом — любой пользователь по sftp мог скачать любые файлы, к которым у него есть доступ. Но сейчас мы это будем исправлять.

Если sshd ещё не установим — поставим его:

aptitude install openssh-server

Текущий openssh в Debian 5 уже поддерживает весь необходимый нам функционал.

По умолчанию у всех пользователей есть домашние каталоги /home/$USER. Но, к сожалению, openssh chroot() требует, чтобы каталог, в который мы будем собственно загонять пользователей, принадлежал пользователю root.

С одной стороны вы можете отдать корректные права на /home руту, а домашним каталогам раздать права 770.

С другой стороны, если вы используете sftp именно для файлообмена, можно передать все домашние каталоги пользователей root’у, а в каждом домашнем каталоге уже создать каталог, в который пользователь будет иметь полный доступ.

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

Для примера возьмём пользователя inky. Он уже создан в системе и вы можете зайти этим пользователем по ssh.

Создаём нужные каталоги:

mkdir -p /home/inky/data

И назначаем корректные права доступа:

chown -R root:root /home/inky && chmod -R 700 /home/inky && chown -R inky:inky /home/inky/data && chmod -R 770 /home/inky/data

Некоторые скажут, что такие права ужасны и их ни в коем случае нельзя использовать, но в нашем случае они обеспечивают необходимую степень безопасности. К тому же мы всё уже проверили.

Если существует необходимость запускать что-либо в дальнейшем от пользователя — вы можете изменить ему домашний каталог, например, на /home/inky/data. Сделать это можно в файле /etc/passwd

Теперь приступим к настройке самого sshd.

Открываем наш любимый текстовый редактор и дописываем туда следующее:

Subsystem sftp /usr/lib/openssh/sftp-server Match user inky ChrootDirectory /home/%u ForceCommand internal-sftp

AllowTcpForwarding no

Если у вас была какая-либо другая строка Subsystem sftp — закомментируйте её.

Теперь немного пояснений:

Match user inky — последующие опции будут применены для пользователя inky

ChrootDirectory /home/%u — зайдя по фтп пользователь попадёт в каталог /home/inky. %u — подставляет имя пользователя в имя каталога. Можно также использовать %h — домашний каталог пользователя и %g — имя группы авторизации пользователя.

ForceCommand internal-sftp — запрещаем пользователю входить на сервер по ssh. При попытке ввести любой символ после авторизации по ssh — сервер откажет пользователю в соединении. Тем не менее, все возможности sftp будут работать корректно.

AllowTcpForwarding no — запрещаем пользователю использовать возможности туннелинга, пробрасывания портов и подобное. Так же сейчас мы выключили ему возможность использовать «Instant socks proxy over SHH» — я раскажу в одной из следующих статей что это такое.

После этого перезагружаем sshd:
/etc/init.d/sshd restart

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

Теперь проверим работу sftp. Самый простой способ — в адресную строку наутилуса вводим приблизительно следующее:

sftp://user@host:port

Наутилус спросит пароль, вводим его и попадаем в указанный в sshd каталог.

Из командной строки мы можем попасть на sftp сервер вполне ожидаемой командой:
sftp user@host -p XX

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

Также для доступа к SFTP серверам можно использовать FileZilla — её преимущество в том, что мы сможем заливать (и скачивать файлы) в несколько потоков, увеличивая тем самым скорость (но и нагрузку на CPU).

sftp chroot правила можно также применять и к определенным группам пользователей, но об этом я расскажу в следующей статье, под названием «sftp chroot vs. ispmanager»

Источник: https://debian.pro/24

Как настроить SFTP-сервер с помощью пользователей chrooted в своих домашних каталогах?

Я пытаюсь настроить SFTP-сервер с несколькими пользователями, chrooting в свои домашние каталоги. Я последовал советам по этому руководству ( ссылка Archive.org ), а затем выполнил следующие команды в каталогах пользователя

chown root:root /home/user/ chmod 755 /home/user/

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

Как я исхожу отсюда? Конечная идея состоит в том, чтобы каждый пользователь на какой-либо другой машине использовал FileZilla для входа в свои chrooted домашние каталоги, а затем мог загружать каталоги и файлы. Все это в SFTP (более безопасно)

В этой статье также описывается, как получить доступ к chrooted shell, но поскольку вам просто нужна учетная запись sftp, просто следуйте этим инструкциям:

Измените /etc/ssh/sshd_config и добавьте строки:

SubSystem sftp internal-sftp Match Group sftp ChrootDirectory %h ForceCommand internal-sftp AllowTcpForwarding no

Найдите строку UsePAM yes и прокомментируйте ее:

#UsePAM yes

Не отключая это, мой SSH-сервер потерпел бы крах при перезагрузке / перезагрузке. Поскольку мне не нужны фантастические функции PAM, это прекрасно.

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

Поскольку SSH не может комбинировать AllowUsers и AllowGroups (логин должен выполнять оба правила), вы должны создать дополнительную группу, например, ssh-users .

Добавьте пользователей, которым разрешено входить в систему ( youruser ниже) через SSH:

sudo groupadd ssh-users sudo gpasswd -a youruser ssh-users

И добавьте следующую строку в /etc/ssh/sshd_config :

AllowGroups ssh-users sftp

Теперь приступим к модификации разрешений домашней директории пользователей, чтобы разрешить chrooting (например, пользователь sftp-user ):

sudo chown root:sftp-user /home/sftp-user sudo chmod 750 /home/sftp-user

Создайте каталог, в котором sftp-user может размещать в нем любые файлы:

sudo mkdir /home/sftp-user/public sudo chown sftp-user: /home/sftp-user/public sudo chmod 750 /home/sftp-user/public

Если у вас возникнут какие-либо проблемы, проверьте /var/log/syslog и /var/log/auth.log . Запустите ssh или -vvv параметром -vvv для отладки сообщений. Для sftp параметр должен появиться перед хостом, как в sftp -vvv user@host .

Читайте также:  Kvm на ubuntu server. установка, настройка и создание виртуальной машины

Я использую Ubuntu LTS 12.04 и после много боли, это сработало для меня.

Мои настройки для /etc/ssh/sshd_config

Subsystem sftp internal-sftp -f AUTH -l VERBOSE UsePAM yes Match group sftp ChrootDirectory %h ForceCommand internal-sftp AllowTcpForwarding no

  1. создать группу sftp:

    groupadd sftp

  2. Создайте пользователя напрямую с помощью новой группы sftp:

    sudo useradd -d /ftpusers/HomeFolder -m UserName -g sftp -s /bin/false

  3. установить разрешения для использования с ssh для sftp:

    chown root:root HomeFolder

    chmod 755 HomeFolder

  4. перезапуск службы:

    service ssh restart

Обратите внимание, домашняя папка для нового пользователя sftp должна быть предоставлена ​​владельцу root.

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

Источник

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

Вот пошаговое руководство, которое позволяет:

  1. SFTP-доступ к / home / bob / uploads для пользователя bob
  2. Блокировка bob из SSH
  3. Используйте имя пользователя / пароль, а не ключи:

Сначала отредактируйте файл / etc / ssh / sshd_config:

sudo nano /etc/ssh/sshd

Прокрутите вниз и измените:

PasswordAuthentication yes

и добавьте это внизу:

Match Group sftpusers ChrootDirectory %h ForceCommand internal-sftp AllowTcpForwarding no

Нажмите Ctrl-X, чтобы выйти и сохранить.

Теперь добавьте пользователя:

sudo useradd bob sudo passwd bob

Теперь добавьте группы и отключите ssh:

sudo groupadd sftpusers sudo usermod -g sftpusers bob sudo usermod -s /usr/bin/rssh bob sudo usermod -d /home/bob bob

Теперь установите разрешения:

sudo chown root:root /home/bob/ sudo chmod 755 /home/bob/ sudo mkdir /home/bob/uploads sudo chown bob /home/bob/uploads sudo service sshd restart

Все это при входе в систему как пользователь root (ec2-пользователь AMI Amazon Linux)

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

Кроме того, возможно, для разрешения необходимо установить 755 в каталоге chroot и любых родительских каталогах, а владелец – root: root.

Лично я настроил каталог chroot sshd_config как% h, домашний каталог пользователя, а затем установил домашний каталог туда, где я хочу, например /var/www/examplewebsite.com.

Некоторые могут предпочесть настроить домашний каталог chroot со статической частью, за которой следует имя пользователя, например / var / www /% u, однако для этого требуется, чтобы ваш chroot-каталог пользователя соответствовал его имени пользователя, конечно.

Чтобы устранить проблемы с подключением, остановите службу ssh, обязательно откройте сеанс SSH или два первых для тестирования, а затем запустите демон интерактивно в режиме отладки, чтобы просмотреть информацию об отладке соединения, поскольку это может помочь вам выявить любые проблемы и выполнить поиск как их исправить.

Команды: сервис ssh stop; / usr / sbin / sshd -d

Обязательно запустите ssh снова, когда закончите! Команда: сервис ssh start

Источник: http://ubuntu.fliplinux.com/sftp-2.html

home-directory — Как настроить SFTP-сервер с помощью пользователей chrooted в своих домашних каталогах? [Дубликат]

Я пытаюсь настроить SFTP-сервер с несколькими пользователями, chrooting в свои домашние каталоги. Я следовал советам это руководство ( Ссылка Archive.org ), а затем выполнили следующие команды в каталогах пользователя

chown root:root /home/user/
chmod 755 /home/user/

В домашнем каталоге каждого пользователя есть дополнительная папка public, которая принадлежит его пользователю, чтобы позволить им создавать каталоги и загружать и удалять файлы по мере необходимости. (Это было рекомендовано в руководстве, о котором я упоминал ранее)

Теперь, когда я выполняю sftp -P 435 [email protected], я получаю эту ошибку:

Как мне исходить? Конечная идея состоит в том, чтобы каждый пользователь на какой-либо другой машине использовал FileZilla для входа в свои chrooted домашние каталоги, а затем мог загружать каталоги и файлы. Все это в SFTP (более безопасно)

24

В этой статье также описывается, как получить доступ к chrooted shell, но поскольку вам просто нужна учетная запись sftp, просто следуйте этим инструкциям:

Изменить /etc/ssh/sshd_config и добавить строки:

SubSystem sftp internal-sftp
Match Group sftp
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no

Найдите строку UsePAM yes и прокомментируйте ее:

#UsePAM yes

Без отключения этого, мой SSH-сервер потерпит крах при перезагрузке /перезагрузке. Поскольку мне не нужны фантастические функции PAM, это нормально.

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

Поскольку SSH не может комбинировать AllowUsers и AllowGroups ( логин должен выполнять оба правила), вы должны создать дополнительную группу, например ssh-users.

Добавьте пользователей, которым разрешено входить в систему (youruser) через SSH:

sudo groupadd ssh-users
sudo gpasswd -a youruser ssh-users

И добавьте следующую строку в /etc/ssh/sshd_config:

AllowGroups ssh-users sftp

Теперь приступим к модификации разрешений домашнего каталога пользователей, чтобы разрешить chrooting (пример user sftp-user):

sudo chown root:sftp-user /home/sftp-user
sudo chmod 750 /home/sftp-user

Создайте каталог, в котором sftp-user можно разместить любые файлы в нем:

sudo mkdir /home/sftp-user/public
sudo chown sftp-user: /home/sftp-user/public
sudo chmod 750 /home/sftp-user/public

Если у вас возникнут проблемы, проверьте /var/log/syslog и /var/log/auth.log. Запустите ssh или sftp с помощью -vvv для отладки сообщений. Для sftp параметр должен появиться перед хостом, как в sftp -vvv [email protected]

ответил Lekensteyn 17 июня 2011, 20:36:48

8

Я использую Ubuntu LTS 12.04 и после большой боли, это сработало для меня.

Мои настройки для /etc/ssh/sshd_config

Subsystem sftp internal-sftp -f AUTH -l VERBOSE
UsePAM yes
Match group sftp ChrootDirectory %h ForceCommand internal-sftp AllowTcpForwarding no

  1. создать группу sftp:

    groupadd sftp

  2. Создайте пользователя непосредственно с присоединенной новой группой sftp:

    sudo useradd -d /ftpusers/HomeFolder -m UserName -g sftp -s /bin/false

  3. установить разрешения для использования с ssh для sftp:

    chown root:root HomeFolder

    chmod 755 HomeFolder

  4. служба перезагрузки:

    service ssh restart

Примечание. Домашней папке для нового пользователя sftp должен быть предоставлен владелец root.

ответил Aten 16 октября 2012, 17:41:21

7

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

Источник

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

ответил Nathan Jones 30 сентября 2015, 23:08:56

3

Ниже приведено пошаговое руководство, позволяющее:

  1. Доступ SFTP к /home /bob /uploads для пользователя bob
  2. Блокировка bob из SSH
  3. Использовать имя пользователя /пароль, а не ключи:

Сначала отредактируйте файл /etc /ssh /sshd_config:

sudo nano /etc/ssh/sshd

Прокрутите вниз и измените:

PasswordAuthentication yes

и добавьте это внизу:

Match Group sftpusers
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no

Нажмите Ctrl-X, чтобы выйти и сохранить.

Теперь добавьте пользователя:

sudo useradd bob
sudo passwd bob

Теперь добавьте группы и отключите ssh:

sudo groupadd sftpusers
sudo usermod -g sftpusers bob
sudo usermod -s /usr/bin/rssh bob
sudo usermod -d /home/bob bob

Теперь установите разрешения:

sudo chown root:root /home/bob/
sudo chmod 755 /home/bob/
sudo mkdir /home/bob/uploads
sudo chown bob /home/bob/uploads sudo service sshd restart

Все это при входе в систему как пользователь root (ec2-пользователь AMI Amazon Linux)

ответил Rob Mulder 26 июля 2016, 04:28:40

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

Кроме того, возможно, для разрешения необходимо установить 755 в каталоге chroot и любых родительских каталогах, а владелец — root: root.

Лично я настроил каталог chroot sshd_config как% h, домашний каталог пользователя, а затем установил домашний каталог туда, где я хочу, например /var/www/examplewebsite.com.

Некоторые могут предпочесть настроить домашний каталог chroot со статической частью, за которой следует имя пользователя, например /var /www /% u, однако это требует, чтобы ваш chroot-каталог пользователя соответствовал его имени пользователя, конечно.

Чтобы устранить проблемы с подключением, остановите службу ssh, обязательно откройте сеанс SSH или два первых для тестирования, а затем запустите демон интерактивно в режиме отладки, чтобы просмотреть информацию об отладке соединения, поскольку это может помочь вам выявить любые проблемы , и найдите, как их исправить.

Команды: сервис ssh stop; /usr /sbin /sshd -d

Обязательно запустите ssh снова, когда закончите! Команда: сервис ssh start

ответил RedScourge 28 января 2016, 05:09:59

Источник: https://sprosi.pro/questions/112072/kak-nastroit-sftp-server-s-pomoschyu-polzovateley-chrooted-v-svoih-domashnih-katalogah-dublikat

Устанавливаем и настраиваем sftp и chroot в нужную папку для архивации

Сообщение об ошибке

Комментарий, на который вы пытаетесь ответить, больше не существует.

 

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

      Настройка производится на Debian Squeeze, но также подойдет к любой *NIX системе на которую можно поставить OPENSSH.

      Устанавливаем ssh командой:

aptitude install ssh

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

useradd -d /dev/null -M -s /bin/bash back

      Назначаем пароль созданному пользователю командой — запросит ввод пароля 2 раза, отображаться вводимое не будет:

passwd back

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

      Создаем папку в которую пользователь сможет записывать архивы:

mkdir -p /sftp/back/

Даем права на папку :

chown -R back:back /sftp/back/

!!! ChrootDirectory — не должен быть доступен для записи пользователю back

      Далее редактируем конфигурационный файл ssh находящийся по пути /etc/ssh/sshd_config

vi /etc/ssh/sshd_config

было:…

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

# Set this to 'yes' to enable PAM authentication, account processing,# and session processing. If this is enabled, PAM authentication will# be allowed through the ChallengeResponseAuthentication and# PasswordAuthentication.

  Depending on your PAM configuration,# PAM authentication via ChallengeResponseAuthentication may bypass# the setting of «PermitRootLogin without-password».

# If you just want the PAM account and session checks to run without# PAM authentication, then enable this but set PasswordAuthentication# and ChallengeResponseAuthentication to 'no'.UsePAM yes

стало:


#Subsystem sftp /usr/lib/openssh/sftp-server # Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of «PermitRootLogin without-password».
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM yes Subsystem sftp internal-sftp
Match User back X11Forwarding no AllowTcpForwarding no AllowAgentForwarding no ForceCommand internal-sftp ChrootDirectory /sftp/

Перезагружаем ssh командой:

/etc/init.d/ssh restart

Задача выполнена, можно подключатся к серверу по 22 порту (если его не меняли) под логином back и паролем, что Вы записали ранее.

С Вами был Сергей Лазаренко.

Источник: https://softnastroy.com/comment/reply/26/675

Ссылка на основную публикацию