Протоколы передачи файлов: Часть 2 — FTPS или SFTP

Названия FTPS и SFTP отличаются одной буквой, и их часто путают. На деле это два разных протокола с разным устройством. FTPS — это обычный FTP, к которому добавили шифрование TLS. SFTP — самостоятельный протокол, который работает внутри SSH-соединения и к FTP отношения не имеет.

FTPS: FTP с шифрованием TLS

FTPS сохраняет всю логику FTP — два соединения, команды, активный и пассивный режим, — но оборачивает их в TLS, тот же протокол, что защищает HTTPS. Существует два варианта.

Явный FTPS (explicit, AUTH TLS). Описан в RFC 4217. Клиент подключается к обычному порту 21 и командой AUTH TLS просит перейти на защищённый канал. Сервер может разрешать и незашифрованные сессии, поэтому важно требовать TLS принудительно (в vsftpd — параметры force_local_logins_ssl и force_local_data_ssl).

Неявный FTPS (implicit). TLS начинается сразу при подключении, без команд. Для него выделены отдельные порты: 990 для управляющего соединения и 989 для данных. Это более старый вариант, стандартом он так и не стал, но многие клиенты и серверы его поддерживают.

Сильные стороны FTPS:

• используются обычные сертификаты — те же, что для сайта, например от Let’s Encrypt;
• совместим с системами, которые «понимают» только FTP и умеют включать TLS.

Слабые стороны достались ему от FTP:

• соединений по-прежнему два, и для пассивного режима нужен диапазон портов;
• NAT и межсетевые экраны не видят содержимое зашифрованного управляющего канала и не могут «подсмотреть», какой порт открыть для данных, поэтому правила приходится задавать жёстко;
• настроек больше: сертификат, режим, диапазон портов, принудительное шифрование.

SFTP: передача файлов через SSH

SFTP (SSH File Transfer Protocol) — подсистема SSH. Клиент подключается к тому же серверу SSH на порт 22, проходит обычную аутентификацию SSH — по паролю или, лучше, по ключу — и внутри этого единственного соединения передаёт файлы, получает списки каталогов, переименовывает и удаляет файлы.

Преимущества SFTP:

• одно соединение и один порт — нет проблем с пассивным режимом и NAT;
• сервер уже есть — OpenSSH установлен почти на каждом Linux-сервере и включает SFTP-сервер;
• ключи вместо паролей — можно полностью отказаться от паролей;
• широкая поддержка клиентов — FileZilla, WinSCP, Cyberduck, sftp в командной строке, файловые менеджеры Linux и macOS.

Изоляция SFTP-пользователей: chroot

Частая задача — дать подрядчику или контрагенту доступ к одному каталогу для обмена файлами, без командной строки и без доступа к остальной системе. В OpenSSH это делается блоком Match в /etc/ssh/sshd_config:

# /etc/ssh/sshd_config
Subsystem sftp internal-sftp

Match Group sftponly
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

• ForceCommand internal-sftp запускает встроенный SFTP-сервер и не даёт выполнить никакие другие команды. По документации ему не нужны вспомогательные файлы внутри chroot.
• ChrootDirectory запирает пользователя в его каталоге; %u подставляет имя пользователя.
• AllowTcpForwarding no и X11Forwarding no нужны явно: документация sshd предупреждает, что ForceCommand сам по себе не запрещает проброс портов через соединение.

Главное требование к chroot: по документации sshd проверяет, что все компоненты пути принадлежат root и недоступны на запись группе и остальным. Поэтому сам каталог пользователя делают «только для чтения», а для загрузки создают подкаталог:

sudo groupadd sftponly
sudo useradd -m -d /srv/sftp/partner -G sftponly -s /usr/sbin/nologin partner
sudo chown root:root /srv/sftp /srv/sftp/partner
sudo chmod 755 /srv/sftp /srv/sftp/partner
sudo mkdir /srv/sftp/partner/upload
sudo chown partner:partner /srv/sftp/partner/upload
sudo sshd -t && sudo systemctl reload ssh

Команда sshd -t проверяет конфигурацию до перезагрузки службы: ошибка в sshd_config на удалённом сервере может закрыть доступ по SSH и вам самим.

Сравнение

Что выбрать

• Новый обмен файлами, свой сервер — SFTP. Проще в настройке, один порт, ключи вместо паролей.
• Контрагент или оборудование поддерживает только FTP — FTPS с принудительным шифрованием, отдельной учётной записью и узким диапазоном портов.
• Нужен веб-доступ для людей без клиентов — ни то ни другое: лучше собственное облачное хранилище, например Nextcloud, или WebDAV.

Типичные ошибки

• FTPS без принудительного TLS. Сервер принимает и незашифрованные сессии, и часть клиентов подключается без шифрования, не замечая этого.
• Chroot-каталог, принадлежащий пользователю. sshd отклоняет подключение, в журнале появляется сообщение о неправильном владельце или правах каталога.
• SFTP-пользователь с обычной оболочкой. Без ForceCommand internal-sftp и nologin пользователь сможет войти по SSH и выполнять команды.
• Пароли вместо ключей для постоянного обмена. Для автоматических выгрузок используйте отдельный ключ без доступа к оболочке.