У меня есть веб сервер без возможности удаленного доступа к нему из вне, обслуживает несколько сайтов. Он стоит за фаерволом, проброшен 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 с помощью сертификатов.

Помогла статья? Подписывайся на telegram канал автора

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