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

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

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

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

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

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

Почему я говорю тюниговать?

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

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 будут иметь пользователи которые имеют системные² учётные записи. Поэтому необходимо создать учётную запись, под которой будут осуществляться манипуляции с файлами. Поскольку выше было написано 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.


Mission Complete & Game Over