Когда задача звучит просто — «дать людям SFTP-доступ к файлам» — самый очевидный путь: включить Subsystem sftp в OpenSSH и сделать ChrootDirectory. Но как только появляются десятки пользователей, разные папки, лимиты на место, требования по журналированию (audit) и интеграциям, выясняется, что «просто SFTP» превращается в полноценный file server со своими правилами.
Ниже — сравнение двух подходов:
- OpenSSH SFTP — SFTP-сервер внутри
sshd, где управление завязано на пользователей Linux и настройкиsshd_config. - SFTPGo — отдельный сервис, который использует SFTP по SSH, но добавляет прикладные возможности: управление пользователями, квоты, аудит, storage-бэкенды, API/веб-админку.
Оба варианта могут быть «правильными». Разница в том, на каком уровне вы хотите держать «правду» о доступах и политиках: на уровне ОС (OpenSSH) или на уровне приложения (SFTPGo).
Быстрая матрица выбора
Если нужен ориентир «с ходу», используйте шпаргалку:
- OpenSSH SFTP чаще выигрывает, если пользователей мало (условно 1–10), схема папок простая, а контроль удобнее делать POSIX-правами/ACL и группами.
- SFTPGo чаще выигрывает, если пользователей много, нужны квоты, удобный audit в терминах учёток, разные политики и быстрая автоматизация через API.
Главный вопрос не «что быстрее», а «где проще и надёжнее сопровождать доступы через год»: в системных аккаунтах Linux или в отдельной модели пользователей и политик.
Архитектура и модель пользователей: system users vs app users
OpenSSH SFTP: пользователи — это пользователи ОС
В OpenSSH типовая модель такая: каждый SFTP-пользователь — это пользователь Linux (локальный или через LDAP/PAM/NSS). Доступ к файлам регулируется:
- UID/GID, POSIX-права, ACL, группы;
- правилами в
sshd_config, включаяMatch UserиMatch Group; - изоляцией через
ChrootDirectory.
Плюсы: всё нативно, предсказуемо, легко объяснить любому администратору Linux. Минусы: при росте числа пользователей/политик конфигурация и «обвязка» распухают (шаблоны, генерация пользователей, правила групп, отдельные соглашения по каталогам).
SFTPGo: пользователи — сущности SFTPGo, ОС можно почти не трогать
SFTPGo ведёт пользователей в своей конфигурации или базе и применяет правила на уровне приложения: домашние каталоги, ограничения, ключи, маппинг на storage. В результате вы можете минимизировать работу с системными аккаунтами Linux (в зависимости от выбранного режима и бэкенда хранения).
Плюсы: централизованное управление, проще реализовать «много пользователей с разными правилами», удобнее автоматизация. Минусы: появляется дополнительный сервис, который нужно обновлять, мониторить и бэкапить (конфигурацию и/или БД).
Если вы планируете выделенный SFTP-сервер под клиентов или отделы, чаще удобнее брать отдельную машину/виртуалку: проще изолировать риски, обновляться и масштабировать. Для этого обычно выбирают VDS с нормальным диском и понятными лимитами по CPU.
Chroot и изоляция: что реально важно в продакшене
OpenSSH SFTP: строгие правила ChrootDirectory
В OpenSSH chroot — проверенная конструкция, но у неё есть классическая «админская» особенность: каталог, указанный в ChrootDirectory, должен принадлежать root и не быть доступным на запись пользователю. Из-за этого нельзя просто сделать корень chroot «домашней папкой» пользователя, приходится заводить рабочий подкаталог внутри.
Типовой шаблон:
sudo install -d -o root -g root -m 0755 /sftp/acme
sudo install -d -o acmeuser -g acmeuser -m 0750 /sftp/acme/uploadДальше — правила Match User или Match Group в sshd_config, где вы включаете ChrootDirectory, запрещаете shell и лишние SSH-возможности.
SFTPGo: изоляция как часть модели пользователя
В SFTPGo изоляция обычно описывается как «виртуальная файловая система» пользователя: домашний каталог, доступные пути, иногда дополнительные ограничения. Практически это означает меньше ручной работы с root-владением chroot-корней, особенно если storage не ограничивается локальной ФС.
Но если под капотом у вас локальный диск, базовые требования к правам и владельцам никуда не исчезают: их просто проще описать и сопровождать на уровне сервиса.
Quotas: дисковые лимиты и почему это часто больно в OpenSSH
Квоты — один из самых частых «переломных» требований, из-за которых переходят от OpenSSH SFTP к специализированным решениям.
OpenSSH SFTP: квоты — это квоты файловой системы
OpenSSH сам по себе квоты не считает и не ограничивает. Если нужен лимит «не больше 10 ГБ» — это решается на уровне ФС:
- user/group quotas;
- project quotas в XFS/ext4 (когда квота нужна «на каталог/проект», а не на пользователя);
- иногда — отдельные разделы/LVM для крупных клиентов.
Плюсы: работает прозрачно для любых приложений, не только SFTP. Минусы: настройка может быть нетривиальной (особенно для «квот на каталог»), а ещё нужно продумать мониторинг и поддержку (чётко отвечать «кто сколько занял и почему не грузится»).
Если вы упираетесь именно в дисковую подсистему и хотите выбрать между ext4/XFS, полезно заранее понимать, как квоты и метаданные будут жить на ваших нагрузках. Смотрите разбор в статье про выбор ext4 или XFS и базовую настройку диска на VDS.
SFTPGo: квоты как прикладная функция
У SFTPGo квоты задаются на пользователя и воспринимаются как часть «контракта» file server: сколько места и/или сколько файлов можно держать. Это удобно, когда:
- пользователи не являются системными;
- лимиты нужно часто менять без вмешательства в ФС;
- нужны отчёты «кто сколько занял» в терминах пользователей сервиса.
Важное ограничение: прикладные квоты корректны, когда сервер реально контролирует все операции записи/удаления в рамках своего storage. Если параллельно в те же каталоги пишет что-то ещё (cron, приложения, админы), продумайте правила, иначе возможна рассинхронизация ожиданий.
Audit и журналирование: кто, что, когда и откуда
OpenSSH SFTP: логирование на уровне sshd + системный аудит
OpenSSH пишет события в системные логи (syslog/journald): входы, ошибки аутентификации, отключения. Но удобного «аудита файловых операций» (залил, удалил, переименовал) из коробки обычно нет.
Что делают на практике:
- повышают детализацию логов
sshdи коррелируют события; - подключают файловый аудит (например, через
auditd), либо отдельную обвязку на события ФС; - разводят пользователей по отдельным каталогам, чтобы расследования были проще.
Это рабочий путь, но требует дисциплины и аккуратной настройки. А отчёт «какой SFTP-пользователь удалил файл X» может стать нетривиальным, если у вас общий каталог, маппинг через группы и сложные права.
SFTPGo: аудит как продуктовая возможность
SFTPGo обычно даёт более прикладной audit: события в терминах пользователей SFTPGo и операций (upload/download/delete/rename). Для поддержки и комплаенса это часто решающее отличие: быстрее отвечать на вопросы клиента и команды ИБ.
Не забывайте про хранение аудит-логов: если это критично, продумайте ретеншн, ротацию и вынос в централизованное хранилище логов.
Управление доступом: ключи, пароли, IP-ограничения, политики
OpenSSH SFTP
Сильная сторона OpenSSH — зрелая экосистема SSH:
- ключи в
authorized_keysи ограничения на ключ через опции; - централизованная аутентификация через PAM/LDAP (если это уместно и поддерживается инфраструктурой);
- гибкие политики в
sshd_config(запрет shell, форвардингов, туннелей, прокидывания X11 и т. п.).
Но когда у вас сотни пользователей с разными ключами и правилами, «чисто через ОС» почти всегда требует автоматизации (Ansible, шаблоны, генерация authorized_keys, единые конвенции по группам и каталогам).
SFTPGo
SFTPGo обычно удобнее в сценариях «много пользователей, много ключей, много политик». Часто проще отделить SFTP-учётки от системных, снижая риск случайно выдать лишние права на сервере.
Критичный момент — жизненный цикл доступов: создание, ротация ключей, блокировка, временные доступы, отчётность. Там, где OpenSSH потребует дисциплины на уровне ОС и IaC, SFTPGo нередко позволяет оформить это как процесс внутри сервиса (или через API).
Хранение данных: локальный диск vs бэкенды и «виртуальные» файловые системы
OpenSSH SFTP чаще всего означает «работаем с локальной файловой системой сервера» (или с примонтированными сетевыми ФС). Это надёжно и предсказуемо, но накладывает ограничения на архитектуру: масштабирование, миграции, разделение клиентов, бэкапы, перенос нагрузки.
SFTPGo в типовом использовании может быть «front door» к разным вариантам хранения, что удобно, если file server — это интерфейс к хранилищу, а не просто «папка на диске».
Производительность и масштабирование: где будет узкое место
По скорости передачи оба варианта упираются в одни и те же вещи: CPU на шифрование, I/O диска, лимиты сети, число параллельных сессий и настройки ядра. На малых и средних нагрузках разница между OpenSSH SFTP и SFTPGo обычно не драматическая, а вот разница в эксплуатации — заметная.
На что смотреть в продакшене:
- Одновременные подключения и «бурсты» (например, ночные выгрузки).
- Мелкие файлы: много операций list/stat/rename сильно нагружают метаданные диска.
- Логи и audit: подробное журналирование — это тоже нагрузка (и на диск, и на обработку).
Эксплуатация: обновления, бэкапы, мониторинг, восстановление
OpenSSH SFTP: меньше компонентов, проще «в вакууме»
OpenSSH почти всегда уже установлен. Обновления приходят через пакетный менеджер ОС, конфиг лежит в одном месте, мониторинг стандартный (доступность порта, логи, метрики системы). Бэкапить нужно в основном данные и конфиги.
Сложность появляется в другом: все «фичи file server» вы строите вокруг — квоты, аудит файловых событий, self-service, отчётность. Каждая такая фича становится отдельным кусочком инфраструктуры.
SFTPGo: отдельный сервис со своей жизнью
SFTPGo нужно развернуть и сопровождать: обновления, совместимость с ОС и бэкендом хранения, бэкапы конфигурации/БД, мониторинг здоровья сервиса. Взамен многие вещи, которые в OpenSSH обычно делаются «сбоку», становятся частью продукта: users, quotas, audit.
В эксплуатации чаще побеждает решение, совпадающее с вашим процессом: либо «всё через Linux и IaC», либо «отдельный сервис с понятной админкой/API и моделью пользователей».
Безопасность: типовые риски и как их оценивать
И OpenSSH, и SFTPGo могут быть безопасными при правильной настройке. Практичнее оценивать не «по бренду», а по поверхности атаки и вашим процессам обновлений/контроля изменений:
- OpenSSH: минимум лишнего, но высокая цена ошибки в правах ФС/ACL/группах и правилах
Match/ChrootDirectory. - SFTPGo: добавляется отдельный демон и иногда web/admin-интерфейс, который нужно закрывать сетевыми политиками и регулярно обновлять; зато проще разделять роли и не раздавать системные доступы.
В обоих случаях для SFTP-аккаунтов стоит максимально отключать лишнее: shell, форвардинги, туннели. А если разрешены пароли — отдельно продумать защиту от перебора и политику ротации.
Про практику обнаружения подозрительных SSH-логинов и алерты на базе journald/PAM может пригодиться материал: как настроить уведомления о входах по SSH.
Типовые сценарии и рекомендации
Сценарий 1: «Нужно 3–5 SFTP-пользователей для обмена файлами с подрядчиком»
Обычно достаточно OpenSSH SFTP. Делайте отдельных пользователей, отключайте shell, настраивайте chroot, выдавайте ключи. Квоты — только если реально нужно, и тогда часто проще решить это на уровне ФС или выделенного раздела.
Сценарий 2: «SFTP как услуга для клиентов: десятки/сотни учёток, разные каталоги, лимиты, отчётность»
Здесь SFTPGo чаще удобнее: пользователи управляются централизованно, квоты и аудит доступны «в терминах клиентов», проще автоматизация (создание и блокировка учёток как часть процессов поддержки/биллинга).
Сценарий 3: «Нужно жёсткое соответствие процессам безопасности и расследованиям»
Если ключевое — понятный audit «кто и какой файл трогал», SFTPGo обычно даёт более прямой путь. Если же у вас всё построено вокруг системного аудита и строгих политик ОС, OpenSSH тоже подходит, но потребует грамотной обвязки (аудит ФС, корреляция событий, строгая сегментация каталогов).
Чеклист вопросов перед выбором
- Сколько будет пользователей сейчас и через 6–12 месяцев?
- Нужны ли квоты: по объёму, по количеству файлов, по проектам/клиентам?
- Нужен ли аудит файловых операций в терминах пользователей?
- Где будет хранение: локальный диск, отдельные разделы, сетевые ФС, разные storage?
- Кто будет администрировать: Linux-админы «всё через конфиги» или команда, которой важнее API/панель?
- Как будет выглядеть offboarding: быстро заблокировать доступ, сохранить audit, заархивировать данные?
Вывод
OpenSSH SFTP — рациональный выбор, когда нужен простой, минималистичный и хорошо понятный SFTP-сервис на уровне ОС: chroot, права, ключи, минимум зависимостей.
SFTPGo — сильнее в роли «управляемого file server», где важны масштабирование по пользователям, квоты, удобный audit, единая модель доступа и интеграции.
Если вы строите SFTP как сервис (для клиентов, отделов, партнёров) и хотите меньше ручной работы с системными учётками — обычно выигрывает SFTPGo. Если SFTP — просто транспорт на сервере, а всё остальное уже решено средствами Linux — OpenSSH SFTP будет проще и предсказуемее.
