SFTP и FTPS: два способа защищённой передачи файлов

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

Поэтому сообщение «сервер поддерживает SFTP» и «сервер поддерживает FTP по TLS» описывает две технически несовместимые схемы. Клиент, настроенный на одну, не подключится к другой, даже если пользователь видит те же логин и пароль.

SFTP использует единственное TCP-соединение, как правило на порту 22, и внутри него передаёт и команды, и данные. Для администратора файрвола это удобно: достаточно открыть один порт. FTPS унаследовал от FTP разделение каналов. Управление идёт на порту 21 в явном режиме, где сеанс начинается открытым и затем командой AUTH TLS переходит на шифрование, либо на 990 в неявном, где шифрование включено сразу. Для данных нужен ещё и диапазон пассивных портов.

Затруднение в том, что при шифровании управляющего канала промежуточное устройство больше не видит команд и не может подсмотреть, какой порт согласовали для данных. Отсюда типичная жалоба: подключение проходит, а список каталога не загружается. Причина обычно в закрытом диапазоне пассивных портов.

В FTPS проверка сервера основана на сертификатах X.509, как в веб-протоколах. Клиент сверяет цепочку доверия и имя хоста, а у самоподписанного сертификата придётся вручную подтвердить отпечаток. Пользователь входит по логину и паролю, иногда с клиентским сертификатом.

В SFTP подлинность сервера подтверждается ключом хоста, который запоминается при первом подключении, а пользователя можно проверять паролем или парой ключей. Ключевая схема удобна для автоматических задач: скрипт резервного копирования подключается без ввода пароля. Про сами принципы написано на страницах про SSH и про ключи SSH.

Универсального победителя нет. SFTP проще в развёртывании, если на сервере уже есть SSH, и предсказуем для файрвола. FTPS оказывается уместнее там, где инфраструктура уже построена на сертификатах и требуется совместимость со старыми системами обмена, вроде тех, что применяются в отдельных корпоративных и банковских интеграциях. Многие хостинги поддерживают оба варианта, а у сетевых накопителей и роутеров часто включается лишь один из них.

К теме примыкает FTP с шифрованием только управляющего канала. Иногда данные при этом остаются открытыми, поэтому в настройках стоит проверять, что защита данных включена, а не только защита входа.

При автоматических передачах между организациями решающим доводом бывает то, что уже принято у контрагента, а не технические достоинства. Уточняйте у партнёра протокол, порт, способ аутентификации и список разрешённых адресов заранее: чаще всего именно согласование этих пунктов занимает больше времени, чем сама настройка передачи.

Первое заблуждение: SFTP это «FTP с буквой S». Нет, это другой протокол. Второе: если в клиенте установлена галочка «использовать шифрование», данные всегда защищены. В некоторых программах вариант «если доступно» позволяет тихо вернуться к открытому FTP, а безопасной будет опция «требовать явный TLS». Третье: раз SFTP использует порт 22, он подключается к любому серверу с SSH. На самом деле подсистему sftp на сервере нужно включить отдельно.

Откройте параметры подключения в файловом менеджере или клиенте и посмотрите поле «Протокол». Значение SFTP означает SSH и порт 22, значения FTP с TLS или FTPS — сертификат и порты 21 либо 990. Ошибка «не удалось проверить сертификат» говорит о FTPS, а окно с предложением подтвердить отпечаток ключа — о SFTP.