У меня есть веб сервер без возможности удаленного доступа к нему из вне, обслуживает несколько сайтов. Он стоит за фаерволом, проброшен 80-й порт, для работы сайтов этого достаточно. Понадобилось предоставить оперативный доступ сторонних разработчиков к исходным текстам одного из сайтов. У меня неожиданно возникли затруднения с этим, пришлось повозиться.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Содержание:
Введение
Суть проблемы в следующем. Изначально сервер создавался для внутренней работы над всеми сайтами из локальной сети. Разграничения по правам доступа не было, работали с сайтами мало, изредка что-то правили. Со временем разработчиков вообще не осталось, сайты не менялись. Все управление шло через панели администрирования сайтами.
В один прекрасный день решили обновить один из сайтов. Попросили предоставить доступ к исходникам. В принципе, ничего сложного, думал за 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 с помощью сертификатов.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
У как сделать, чтоб по sftp по умолчанию папки создавались с правами 755, а файлы 644
Сейчас если зайти по ftp по так и создается, а если по sftp то 700/600
Можно попробовать вот так сделать:
Subsystem sftp internal-sftp -u 002
То есть добавить -u 002 к предложенному в статье конфигу.
Спасибо за помощь, получилось добавлением всего 1-й команды ForceCommand internal-sftp -u 022
Запоздалый комментарий, но все же.
SFTP, действительно, не особо быстрый, для передачи больших объемов имеет смысл попробовать SCP. Несмотря на то, что оба протокола работают через SSH, у последнего отличается реализация передачи файлов. Работает шустрее, но чрутить пользователя в случае SCP сложнее, это, скорее, вариант для админа. Интересно, cifs или nfs через VPN имеют меньший оверхед?
Чтоб не ебаться с правами, можно воспользоваться 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 --- одно и то же, должно быть, конечно
При настройке доступа к определенной папке для определенного пользователя по SFTP возникли проблемы:
1. Почему-то доступ работает только на чтение. При загрузке файлов получаю ошибку "Upload failed: Permission denied (3/-31)". Если изменить владельца этой папки на нового пользователя или изменить разрешения папки на 775 или 777, то соединение по SFTP уже не устанавливается - получаю ошибку "Failure initializing sftp session: Unable to startup channel".
2. В SFTP клиенте были сохранены избранные на сервере папки. Почему-то доступ работает и к ним тоже! То есть ограничение доступа к конкретной директории не работает.
У меня CentOS 7. В чем могут быть причины ошибки и как можно исправить?
1. Повторял настройку так же как у меня? Я уже не помню нюансов, но то, что написано, работает на 100%, так как я статью по реальному примеру писал.
2. Сохраненные папки на клиенте никак не могут влиять на доступ. Нужно смотреть настройки сервера. Такого быть не должно.