
SSH FTP (SFTP) instead/вместо FTP
Недавно передо мной предстала задача организовать доступ к файлам сервера. Точнее доступ был, но по каким-то причинам FTP сервер перестал работать. Разбираться в причинах было лень, и тем более, давно хотелось заменить протокол FTP чем нибудь по надёжнее.
Вам, Уважаемое хабрасообщество, да будет известно, что FTP передаёт данные в не шифрованном виде. И нам, параноикам мира сего, немногосцыкотно страшно за сервер наш и данные на нём хранящиеся.
По этому решил полностью отказаться от FTP в пользу SFTP. Я использую Ubuntu Server, и по умолчанию установленный в нём OpenSSH, также мне известно, что он поддерживает SFTP из коробки, поэтому задача казалась мне крайне простой и я быстро приступил к воплощению её в жизнь. С той же скоростью, с которой выполнялась задача, я столкнулся с досадным фактом того, что OpenSSH по умолчанию даёт пользователю доступ ко всей файловой системе, то есть к / — корню.
Данный факт меня, и я думаю Вас, устраивать не будет. То есть с одной стороны, вроде бы ничего страшного, ведь есть права доступа которые не дадут ему, пользователю, просто так писать где ни попади. Но в целях безопасности и этого пряника у него быть не должно.
Тут я подробно расскажу как тюнинговать OpenSSH сервер в Ubuntu Linux для того что бы chroot-нуть пользователя в необходимом нам каталоге.
Почему я говорю тюниговать?
— Да просто по тому, что, как я уже сказал, для работы SFTP достаточно всего лишь выполнить:
Что приведёт к установке и запуску сервера, а также откроет, по умолчанию, 22 порт. Осуществив соединение на который, при помощи, например
Filezilla, можно получить доступ к файловой системе удалённого компьютера/сервера по ШИФРОВАННОМУ протоколу.
Но как я уже намекнул, настройки «по умолчанию» нас не устраивают.
Поэтому открываем файл настройки OpenSSH сервера
Находим опцию
Плюс добавляем следующие опции:
Теперь перезапускаем OpenSSH
Game Over?
— NO!
Как Вы наверное уже догадались, право входа в систему по протоколу SFTP будут иметь пользователи которые имеют системные2 учётные записи. Поэтому необходимо создать учётную запись, под которой будут осуществляться манипуляции с файлами. Поскольку выше было написано
Создается пользователь, задаётся пароль, домашний каталог по умолчанию —
Теперь можно попробовать соединиться с сервером, и передать файлы. Предварительно заходим в логи, что бы наблюдать за процессом…
Как видите, в логах написано:
— сессия открыта для пользователя test используя UID=0, то есть идентификатор пользователя root
— неправильные права собственности для того, что бы chroot-нуться в
Всё дело в том, что для каталога
Подключается и наблюдаем в логах:
Mission complete
В настройках OpenSSH мы описывали опцию Match User test, что само собой означает доступ отдельного, конкретного пользователя!
— А если таковых много?
Описание каждого пользователя — как минимум не кошерно… Короче, я хочу рассказать про то, что можно задействовать группы пользователей используя Match Group.
И тогда конфиг может выглядеть приблизительно так:
А учётные записи пользователей в
Как видно из примера, у пользователей относительный домашний каталог, то есть в корне / нет каталогов
Эти каталоги есть в
— Домашний каталог пользователя, из
Не забываем, что владельцем каталога в который будут chroot-иться пользователи должен быть root. Группой владельцев, необходимо поставить sites и разрешить полный доступ.
Также рекомендуется в качестве shell-а пользователя ставить /bin/false, что бы предотвратить доступ пользователя к командной строке.
Mission Complete & Game Over
Вам, Уважаемое хабрасообщество, да будет известно, что FTP передаёт данные в не шифрованном виде. И нам, параноикам мира сего, немного
По этому решил полностью отказаться от FTP в пользу SFTP. Я использую Ubuntu Server, и по умолчанию установленный в нём OpenSSH, также мне известно, что он поддерживает SFTP из коробки, поэтому задача казалась мне крайне простой и я быстро приступил к воплощению её в жизнь. С той же скоростью, с которой выполнялась задача, я столкнулся с досадным фактом того, что OpenSSH по умолчанию даёт пользователю доступ ко всей файловой системе, то есть к / — корню.
Данный факт меня, и я думаю Вас, устраивать не будет. То есть с одной стороны, вроде бы ничего страшного, ведь есть права доступа которые не дадут ему, пользователю, просто так писать где ни попади. Но в целях безопасности и этого пряника у него быть не должно.
Тут я подробно расскажу как тюнинговать OpenSSH сервер в Ubuntu Linux для того что бы chroot-нуть пользователя в необходимом нам каталоге.
Почему я говорю тюниговать?
— Да просто по тому, что, как я уже сказал, для работы SFTP достаточно всего лишь выполнить:
sudo aptitude install openssh-server
Что приведёт к установке и запуску сервера, а также откроет, по умолчанию, 22 порт. Осуществив соединение на который, при помощи, например

Но как я уже намекнул, настройки «по умолчанию» нас не устраивают.
Поэтому открываем файл настройки 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
так:<output omitted>
site1:x:5000:10003::/example.com/:/bin/false
site2:x:5001:1000::/example.org/:/bin/false
site3:x:5002:1000::/example.net/:/bin/false
<output omitted>
Как видно из примера, у пользователей относительный домашний каталог, то есть в корне / нет каталогов
/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.
1 - mcedit - Мой любимый текстовый редактор.
2 - системные учётные записи - читать как: Созданные в системе пользователи.
3 - 1000 - всего лишь пример идентификатора группы sites.
Mission Complete & Game Over
Comments 18
Only users with full accounts can post comments. Log in, please.