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

Доступ к сайту по 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 с помощью сертификатов.

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

5 комментариев

  1. Алексей
    Алексей

    При настройке доступа к определенной папке для определенного пользователя по SFTP возникли проблемы:
    1. Почему-то доступ работает только на чтение. При загрузке файлов получаю ошибку «Upload failed: Permission denied (3/-31)». Если изменить владельца этой папки на нового пользователя или изменить разрешения папки на 775 или 777, то соединение по SFTP уже не устанавливается — получаю ошибку «Failure initializing sftp session: Unable to startup channel».
    2. В SFTP клиенте были сохранены избранные на сервере папки. Почему-то доступ работает и к ним тоже! То есть ограничение доступа к конкретной директории не работает.
    У меня CentOS 7. В чем могут быть причины ошибки и как можно исправить?

    • Zerox

      1. Повторял настройку так же как у меня? Я уже не помню нюансов, но то, что написано, работает на 100%, так как я статью по реальному примеру писал.
      2. Сохраненные папки на клиенте никак не могут влиять на доступ. Нужно смотреть настройки сервера. Такого быть не должно.

  2. Василий
    Василий

    Чтоб не ебаться с правами, можно воспользоваться mount —bind
    https://wiki.archlinux.org/index.php/SFTP_chroot#Write_access_to_chroot_dir
    Ещё можно наткнуться на такую проблему, если сервер недостаточно новый
    https://serverfault.com/a/816671

    Втыкаю краткое полное описание для битрикс вм, вдруг кому-то тоже приходится с этим говном трахаться, ситуация такая же, как и у OP с проксей, и будет полезно:

    Для настройки сесурного посайтового доступа по SFTP на Bitrix VM appliance 7 (CentOS 7), создаём группу `sftponly` с пользователями для каждого сайта с логин-шеллом `/sbin/nologin`, меняем группу у директорий нужных сайтов в `/home/bitrix/ext_www` c `bitrix` на `sftponly`, для домашней директории пользователя ставим `root:sftpusers` с правами `750`, создаём внутри директорию `htdocs` и делаем `mount —bind /home/bitrix/ext_www/example.com /home/example.com/htdocs/`, не забывая вписать в `/etc/fstab`. Конфигурация `/etc/ssh/sshd_config`:
    «`
    Subsystem sftp internal-sftp

    Match Group sftpusers
    ForceCommand internal-sftp
    ChrootDirectory %h
    PermitTunnel no
    AllowAgentForwarding no
    AllowTCPForwarding no
    X11Forwarding no
    «`

    • Василий
      Василий

      мод, поправь, пожалуйста: напутал имена групп sftponlysftpusers — одно и то же, должно быть, конечно

  3. Евлампий
    Евлампий

    Запоздалый комментарий, но все же.
    SFTP, действительно, не особо быстрый, для передачи больших объемов имеет смысл попробовать SCP. Несмотря на то, что оба протокола работают через SSH, у последнего отличается реализация передачи файлов. Работает шустрее, но чрутить пользователя в случае SCP сложнее, это, скорее, вариант для админа. Интересно, cifs или nfs через VPN имеют меньший оверхед?

Добавить комментарий

Ваш e-mail не будет опубликован.