В 2026 году «поднять SFTP» часто всё ещё означает «включить SSH и ограничить пользователя». Но как только появляются корпоративные требования (аудит, изоляция клиентов, разные политики доступа, SLA, разделение контуров), реализация начинает заметно влиять и на безопасность, и на стоимость эксплуатации.
Ниже — практичный разбор трёх вариантов, которые чаще всего всплывают в поиске: OpenSSH internal-sftp, ProFTPD SFTP и «можно ли vsftpd SFTP». Спойлер: vsftpd — отличный FTP/FTPS-сервер, но к SFTP он не относится, и запрос «vsftpd sftp» почти всегда про путаницу терминов.
Термины, чтобы не путаться: SFTP, FTP, FTPS
Половина проблем в проде начинается не с конфигов, а с неверно понятых требований.
- SFTP — протокол передачи файлов поверх SSH. Обычно работает на 22/TCP (или вашем порту SSH), легко проходит через периметр «одним портом».
- FTP — отдельный протокол, который исторически сложнее на сетевом уровне (активный/пассивный режимы, много портов).
- FTPS — FTP поверх TLS. Это не SFTP и не имеет отношения к SSH.
Если в ТЗ написано «нужен SFTP-сервер», а заказчик подразумевает «FTP с шифрованием», уточните: им нужен SFTP (SSH) или FTPS (TLS). Ошибка на этом шаге дорого стоит: разные клиенты, порты, прокси и процессы управления ключами/сертификатами.
Краткий вывод по выбору
Если нужно «быстро, безопасно, без лишних сущностей» — чаще всего выигрывает OpenSSH. Если SFTP — отдельный сервис с «витриной» для множества клиентов и удобной административной моделью — тогда смотрят на ProFTPD. Если всплыл vsftpd — вероятно, речь вообще про FTPS.
- OpenSSH internal-sftp — лучший дефолт для большинства задач: минимум компонентов, понятная модель безопасности, chroot штатно, легко вписывается в SSH-инфраструктуру.
- ProFTPD SFTP — выбирают, когда нужен SSH-совместимый протокол, но при этом хочется «модель как у FTP-сервера» (виртуальные пользователи, квоты, удобные логи, отдельный контур).
- vsftpd — про FTP/FTPS, а не про SFTP. Для «SFTP по SSH» он не подходит.
Если вы планируете размещать файловый сервис для внешних клиентов, часто удобнее запускать его на отдельной машине/контуре (хотя бы для разграничения рисков и логов). Для таких задач обычно выбирают VDS: проще управлять правилами доступа, обновлениями и журналированием без влияния на веб-приложения.
OpenSSH internal-sftp (встроенный SFTP в sshd)
OpenSSH internal-sftp — SFTP-подсистема, встроенная в sshd. То есть вы не поднимаете отдельный «file transfer server», а расширяете роль SSH: SFTP становится одной из подсистем, управляемых через sshd_config.
Плюсы internal-sftp
- Меньше компонентов: один демон, меньше точек отказа, меньше обновлений и зависимостей.
- Единые политики SSH: ключи, алгоритмы, ограничения по IP, баннеры, 2FA (если применяете) — всё в одном месте.
- Chroot и запрет shell делаются штатно через
Match,ChrootDirectoryиForceCommand internal-sftp. - Понятный security baseline: OpenSSH регулярно аудируется, а модель угроз и типовые ошибки хорошо известны командам эксплуатации.
Минусы/ограничения internal-sftp
- Аудит «из коробки» ограничен логами sshd: вход/выход, IP, метод аутентификации. Для детального «кто сделал rename/unlink» обычно нужна дополнительная настройка.
- Сложнее «виртуализировать» пользователей: типовой путь — системные аккаунты (или внешняя IAM/LDAP), что не всегда удобно при сотнях клиентов.
Базовый паттерн: SFTP-only пользователи с chroot
Самая частая задача: пользователь может только SFTP, без интерактивной оболочки, и только в своём каталоге.
sudo groupadd sftpusers
sudo useradd -m -s /usr/sbin/nologin -G sftpusers client1
sudo passwd client1
sudo mkdir -p /sftp/client1/upload
sudo chown root:root /sftp/client1
sudo chmod 755 /sftp/client1
sudo chown client1:sftpusers /sftp/client1/upload
sudo chmod 750 /sftp/client1/uploadФрагмент sshd_config с ключевыми параметрами:
Subsystem sftp internal-sftp
Match Group sftpusers
ChrootDirectory /sftp/%u
ForceCommand internal-sftp
X11Forwarding no
AllowTcpForwarding no
PermitTunnel no
PasswordAuthentication yesПочему права именно такие: ChrootDirectory требует, чтобы корень chroot принадлежал root и не был доступен на запись пользователю. Поэтому каталог для загрузки делают вложенным (например, upload) и дают права на запись уже на него.
SFTP security hardening для OpenSSH: что реально важно
Список «затянуть гайки» зависит от модели доступа, но есть набор, который почти всегда окупается.
- Разделяйте роли: отдельная группа, отдельный корень chroot, отдельные политики через
Match. - Отключайте лишнее:
AllowTcpForwarding no,X11Forwarding no, при необходимостиPermitTTY no. - Ключи вместо паролей (если возможно): меньше рисков перебора и повторного использования паролей.
- Принцип наименьших привилегий: отдельный пользователь без доступа к системным каталогам и чужим данным.
- Актуальные настройки криптографии: держите профиль OpenSSH в сильном состоянии и документируйте исключения. Практичный ориентир — материал про сильные Cipher/KEX/MAC в OpenSSH.
SFTP audit logging в OpenSSH: три уровня ожиданий
Требование «кто, какой файл, когда загрузил/удалил» нужно декомпозировать на уровни — иначе вы либо не добьётесь нужной детализации, либо утонете в логах.
- Уровень 1: логи sshd. Дают «кто подключался» (пользователь, IP, время, метод аутентификации).
- Уровень 2: детализация SFTP-событий. Больше информации по действиям внутри сессии, но объём журналов растёт существенно.
- Уровень 3: системный аудит файловой системы. Если нужен юридически значимый учёт операций (create/write/unlink/rename), обычно это делается на уровне ОС с продуманной ротацией и хранением.
ProFTPD SFTP: когда нужен SSH-совместимый протокол, но модель «как у FTP»
ProFTPD SFTP обычно означает модуль mod_sftp, который реализует SFTP поверх SSH внутри ProFTPD. Логика выбора часто такая: «хотим SFTP-протокол для клиентов, но административно управлять сервисом как классическим FTP-демоном».
Плюсы ProFTPD SFTP
- Отдельный демон передачи файлов: можно развести по портам/адресам, изолировать от админского SSH, по-другому мониторить и обслуживать.
- Гибкое управление пользователями: в зависимости от схемы авторизации проще обслуживать много клиентов без необходимости заводить «системного пользователя на каждого».
- Более «операционные» логи: часто проще получить события в стиле «операция — строка лога» без дополнительной обвязки.
Минусы ProFTPD SFTP
- Сложнее эксплуатация: отдельные конфиги, обновления, свой контур hardening и диагностики.
- Дублирование SSH-поверхности атаки: появляется ещё один SSH-подобный сервис со своими ключами хоста, настройками протокола и типовыми ошибками конфигурации.
- Риск расхождения политик: SSH для админов живёт отдельно, SFTP для клиентов отдельно — и со временем настройки начинают «дрейфовать».
Кому ProFTPD SFTP подходит лучше всего
- Командам, где SFTP — отдельный продуктовый сервис, который нужно изолировать от административного доступа.
- Сценариям с десятками/сотнями клиентов, где важны квоты, шаблоны политик и удобная модель учётных записей.
- Проектам, где нужны подробные, удобночитаемые логи под дальнейшую корреляцию.
vsftpd и SFTP: почему запрос «vsftpd sftp» — это почти всегда ошибка
vsftpd — один из самых популярных FTP-серверов в Linux, но он про FTP/FTPS, а не про SFTP. Поэтому запрос «vsftpd sftp» обычно означает одно из двух:
- вам на самом деле нужен FTPS (FTP over TLS), и вы используете «SFTP» как синоним «шифрованной передачи файлов»;
- вам нужен SFTP, но вы привыкли к vsftpd и хотите «то же самое, только по SSH» — тогда выбирайте OpenSSH internal-sftp или ProFTPD SFTP.
SFTP vs FTPS: практические отличия для админа
- Клиенты и автоматизация: SFTP широко поддержан инструментами администрирования и CI/CD благодаря SSH-экосистеме.
- Сетевой периметр: SFTP чаще всего «один порт». FTPS требует аккуратной настройки пассивного диапазона и NAT.
- Ключи и доверие: FTPS — это управление TLS-сертификатами, SFTP — управление SSH host keys. Это разные процессы, и оба требуют дисциплины.
Если вы всё-таки идёте в сторону FTPS и выпускаете сертификат под файловый сервис (например, для корпоративных клиентов с жёсткими требованиями к PKI), удобнее заранее заложить нормальный жизненный цикл сертификата. Для этого подойдут SSL-сертификаты под ваш домен и процессы обновления/ротации.
Безопасность в 2026: типовые угрозы и как закрывать их без фанатизма
В реальных инцидентах вокруг файловых сервисов чаще ломается не криптография, а процессы доступа и наблюдаемость.
1) Слишком широкие права на каталоги
Классика: пользователь видит чужие директории, может перезаписывать чужие файлы или «случайно» удаляет не своё. Лечится изоляцией (chroot), аккуратными UID/GID и отказом от «общей папки на всех», если нет железного процесса с ответственностью и логами.
2) Пароли и перебор
Парольный доступ для внешних клиентов почти всегда означает шум сканеров. Минимизируйте поверхность:
- ограничивайте доступ по IP, если это возможно по бизнесу;
- включайте защитные механизмы на уровне SSH (rate-limit/ban по политике);
- по возможности переходите на ключи и делайте короткий жизненный цикл доступов.
3) Отсутствие прозрачного аудита
Когда «пропал файл», без нормального audit trail начинается гадание. Заранее определите, какой уровень аудита вам нужен: сессии, операции в SFTP, или события файловой системы. И сразу заложите ротацию, хранение и поиск по логам (иначе аудит превратится в DoS по диску).
4) Смешение админского SSH и клиентского SFTP
Опасная архитектурная ошибка — использовать один и тот же SSH-контур для администрирования и для внешних SFTP-клиентов без разделения политик. Даже если вы выбираете internal-sftp, разделяйте пользователей/группы, правила Match и, по возможности, порты или отдельные интерфейсы, а также алерты и журналы.
Производительность и эксплуатация: что важнее «скорости протокола»
В споре «что быстрее: internal-sftp или ProFTPD» легко потерять главное: обычно вы упираетесь в диск, задержки сети, число параллельных сессий и модель хранения, а не в реализацию SFTP.
- Много мелких файлов страдают на любом протоколе; помогают упаковка, батчинг и быстрый storage.
- Один большой файл чаще упирается в канал и диск; протокол вторичен при адекватных настройках.
- Эксплуатация важнее «пиковых мегабайт»: обновления, мониторинг, ротация логов, выдача/отзыв доступов, регулярные проверки прав.
Рекомендации по сценариям
Сценарий A: 1–20 клиентов, нужен простой и безопасный SFTP
Берите OpenSSH internal-sftp. Делайте отдельную группу, chroot, SFTP-only, ключи (если возможно). Это даёт минимальную сложность и хороший baseline по безопасности.
Сценарий B: десятки/сотни клиентов, нужен отдельный файловый сервис
Смотрите в сторону ProFTPD SFTP, если вам важны гибкие политики и удобное управление большим числом пользователей. Но закладывайте время на hardening и поддержку отдельного демона (и дисциплину обновлений).
Сценарий C: заказчик просит «SFTP», но у него legacy FTP-клиенты
Это почти всегда история про SFTP vs FTPS. Если их клиенты умеют только FTPS — тогда да, vsftpd может быть уместен, но это уже не SFTP. Не пытайтесь «прикрутить SFTP к vsftpd»: корректнее выбрать протокол под реальную совместимость.
Мини-чеклист перед запуском в прод
- Определён протокол (SFTP или FTPS) и список клиентских приложений/библиотек.
- Есть модель изоляции: отдельные пользователи/группы, каталоги, chroot (если нужен).
- Продумана аутентификация: ключи/пароли, ротация, отзыв доступа, хранение секретов.
- Настроен аудит: минимум — входы/выходы и IP; максимум — операции с файлами и хранение логов.
- Отключены лишние возможности (форвардинг, shell, лишние подсистемы).
- Есть план обновлений и быстрая проверка конфигурации после апдейтов.
Итог
Если вам нужен надёжный SFTP-сервер для Linux в 2026, в большинстве случаев рациональнее стартовать с OpenSSH internal-sftp: он проще, безопаснее по умолчанию и лучше вписывается в операционную модель Linux. ProFTPD SFTP имеет смысл, когда SFTP становится отдельным сервисом с богатой административной моделью и расширенными требованиями к учёту пользователей и логам. А vsftpd держите в голове как сильный FTP/FTPS-сервер — но не как SFTP-решение.
