Как настроить SFTP‑сервер на Linux

Кратко

SFTP — безопасный способ передачи файлов по SSH. В статье пошагово описано, как установить OpenSSH, создать пользователей и каталог с chroot, настроить sshd_config, изменить порт при необходимости и безопасно эксплуатировать сервер. В конце — чек‑листы, советы по безопасности и дерево принятия решений.

Содержание

• Что такое SFTP?
• Установка SSH и OpenSSH Server
• Создание пользователей, групп и директорий для SFTP
• Настройка SSH‑сервера
• Изменение порта SFTP (необязательно)
• Вход и работа с сервером
• Команды передачи файлов: примеры
• Безопасность и жёсткая настройка
• Проверка, отладка и логирование
• Модель принятия решения (Mermaid)
• Роли и чек‑листы
• Критерии приёмки
• Часто задаваемые вопросы

Что такое SFTP?

SFTP (Secure File Transfer Protocol) — сетевой протокол для безопасной передачи файлов поверх SSH (Secure Shell). В отличие от старого FTP, SFTP шифрует весь трафик, включая учетные данные. Хотя в названии акцент на «передаче», SFTP по сути предоставляет удалённый файловый интерфейс (операции чтения, записи, листинга, изменения атрибутов).

Определение в одну строку: SFTP — это файловый протокол, работающий поверх SSH для безопасного обмена и удалённого управления файлами.

Важно: современная работа над протоколом ведётся в IETF, а реализация чаще всего — OpenSSH.

Установка SSH и OpenSSH Server

Большинство дистрибутивов Linux уже включают клиент ssh; серверная часть может быть не установлена по умолчанию. Примеры установки:

Для Debian/Ubuntu:

sudo apt update
sudo apt install -y openssh-server

Проверить версию SSH-клиента:

ssh -V

Для Arch Linux:

sudo pacman -Syu openssh

После установки sshd обычно автоматически включается. Если нет, запустите и включите сервис:

sudo systemctl enable --now sshd

Совет: проверьте брандмауэр (ufw, firewalld, iptables) и откройте соответствующий порт (по умолчанию 22), прежде чем запускать сервер в продакшне.

Создание пользователей, групп и директорий для SFTP

Рекомендация: для SFTP выделяйте отдельные системные группы и пользователей, чтобы ограничить доступ.

1. Создайте группу для SFTP‑пользователей:

sudo groupadd sftp_group

2. Создайте пользователя и добавьте его в группу:

sudo useradd -g sftp_group -s /usr/sbin/nologin -m sftp_user

Флаг -s /usr/sbin/nologin запрещает вход в интерактивную оболочку (опция для безопасности). Если дистрибутив использует /bin/false, замените соответственно.

3. Задайте пароль пользователю (если используете парольную аутентификацию):

sudo passwd sftp_user

4. Создайте структуру директорий для chroot (пример):

sudo mkdir -p /data/sftp_user/uploaded_files

5. Настройте владельцев и права: корневой каталог chroot должен принадлежать root и быть недоступен для записи другим пользователям, а подкаталоги — пользователю SFTP:

sudo chown -R root:sftp_group /data/sftp_user
sudo chown -R sftp_user:sftp_group /data/sftp_user/uploaded_files
sudo chmod 755 /data/sftp_user
sudo chmod 750 /data/sftp_user/uploaded_files

Комментарий: строгие права на корень chroot — обязательны; иначе sshd откажется применять chroot.

Настройка SSH‑сервера

Откройте конфигурационный файл sshd:

sudo nano /etc/ssh/sshd_config

Ниже в файле добавьте блок для сопоставления группы и включения internal-sftp:

Match Group sftp_group
    ChrootDirectory /data/%u
    ForceCommand internal-sftp
    X11Forwarding no
    AllowTCPForwarding no

Пояснения:

• ChrootDirectory /data/%u подставляет имя пользователя в путь, например /data/sftp_user.
• ForceCommand internal-sftp принудительно запускает встроенный SFTP‑сервер OpenSSH.
• Отключение X11Forwarding и AllowTCPForwarding уменьшает поверхность атаки.

Сохраните файл и перезапустите sshd:

sudo systemctl restart sshd

Проверьте синтаксис конфигурации перед перезапуском:

sshd -t

Если команда ничего не выводит — синтаксис корректен.

Изменение порта SFTP (необязательно)

Если хотите сменить порт по умолчанию (22) на нестандартный — для уменьшения числа автоматических атак это распространённая практика. В файле /etc/ssh/sshd_config раскомментируйте и измените строку:

Port 1111

После изменения не забудьте:

• обновить правила брандмауэра (открыть новый порт и закрыть старый при необходимости);
• перезапустить sshd:

sudo systemctl restart sshd

Важно: смена порта — лишь одна из мер; она не заменяет аутентификацию по ключам и другие методы защиты.

Вход и работа с сервером

Перед подключением посмотрите справку клиента:

sftp -h

Подключение по имени пользователя и хосту:

sftp user@host

Указание порта (если требуется нестандартный):

sftp -P 1111 user@host

После подключения вы попадаете в sftp‑оболочку, где доступны команды и подсказка help.

Команды: скачивание файлов

Скачать файл с сервера в локальную текущую директорию:

get /path/to/file/on/server

Скачать в конкретную локальную директорию:

get /path/to/file/on/server /path/to/local/folder

Скачать директорию (рекурсивно):

get -r /bin /home/username/Desktop/bin

Замечание: при рекурсивном копировании sftp копирует содержимое каталога; чтобы получить сам каталог в локальную папку, укажите новое имя каталога в пути назначения.

Команды: загрузка файлов

Загрузка локального файла на сервер:

put /path/to/local/file /path/to/remote/location

Загрузка каталога рекурсивно:

put -r /home/username/Desktop/bin bin

Это создаст на сервере каталог bin и скопирует в него файлы.

Возобновление прерванных передач и пути с пробелами

Для возобновления прерванных передач используйте reget и reput:

reget /path/to/file/on/server /path/to/local/file
reput /path/to/local/file /path/to/file/on/server

С рекурсивным режимом:

reput -r /home/username/Desktop/bin bin

Если путь содержит пробелы — берите его в кавычки:

put "/home/username/My Documents/Files"

Прочие команды

• ls — листинг файлов (может поддерживать ключи, например ls -l)
• chmod — изменить права файла (в sftp синтаксис: chmod 644 filename)
• mkdir — создать каталог
• pwd и lpwd — показать текущую директорию на удалённой и локальной стороне

chmod 644 example.txt
mkdir new_folder
ls -l

Безопасность и жёсткая настройка

Рекомендации по повышению безопасности SFTP‑сервера:

1. Используйте аутентификацию по ключам вместо паролей. Отключите PasswordAuthentication в /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes

2. Ограничьте доступ по группам или списку пользователей (AllowGroups / AllowUsers).

3. Убедитесь, что корневой каталог chroot принадлежит root и не доступен для записи другим.

4. Ограничьте возможности перенаправления TCP и X11 (см. ForceCommand выше).

5. Включите ограниченное логирование: LogLevel VERBOSE для отслеживания попыток передачи ключей и команд.

6. Настройте Fail2Ban или аналог для блокировки брутфорс‑атак.

7. Храните файлы конфигурации и права в системе управления конфигурацией (Ansible, Salt), чтобы избежать ручных ошибок при масштабировании.

8. Регулярно обновляйте OpenSSH и пакеты безопасности.

9. Ограничьте размер загружаемых файлов и скорость передачи на уровне сети, если требуется (tc, iptables с лимитом).

10. При работе с персональными данными соблюдайте требования локального регулирования и GDPR (см. раздел Приватность).

Приватность и соответствие требованиям

Если через SFTP передаются персональные данные, обеспечьте:

• шифрование канала (SFTP уже использует SSH);
• шифрование данных в состоянии покоя, если требуется (например, зашифрованные тома);
• аудит и хранение логов с контролем доступа;
• политику хранения и удаления данных в соответствии с локальными требованиями.

Проконсультируйтесь с отделом комплаенса для формализации процесса.

Проверка, отладка и логирование

Полезные шаги для проверки работы и поиска причин отказов:

• Проверить синтаксис конфигурации: sshd -t
• Просмотреть логи sshd (journalctl -u sshd или /var/log/auth.log):

sudo journalctl -u sshd --since "1 hour ago"
sudo tail -n 200 /var/log/auth.log

• Проверить права и владельцев chroot:

namei -l /data/sftp_user

namei показывает владельцев и разрешения для каждого сегмента пути — это пригодится при отладке chroot.

• Если клиент не подключается, попытайте явный отладочный режим ssh:

sftp -vvv -P 1111 user@host

-vvv покажет подробный отладочный вывод.

Модель принятия решения (Mermaid)

Ниже — простое дерево принятия решения, которое поможет выбрать стратегию развертывания SFTP.

flowchart TD
    A[Начало: нужен обмен файлами?] --> B{Требуется шифрование?}
    B -- Нет --> C[Использовать FTP 'не рекомендовано']
    B -- Да --> D{Нужны ли удалённые команды/оболочка?}
    D -- Да --> E[Рассмотреть SSH/SCP с контролем доступа]
    D -- Нет --> F[Использовать SFTP 'chroot при необходимости']
    F --> G{Нужна ли аутентификация по ключам?}
    G -- Да --> H[Включить pubkey и отключить пароли]
    G -- Нет --> I[Оставить пароли, усилить мониторинг]
    H --> J[Внедрить Fail2Ban и бэкап логов]
    I --> J

Роли и чек‑листы

Чек‑лист администратора:

• Установить openssh-server и проверить работу sshd
• Создать группу sftp_group и пользователей
• Настроить chroot и права (root для корня)
• Настроить sshd_config (ForceCommand internal-sftp, Match Group)
• Включить ключи, отключить пароли (по возможности)
• Настроить брандмауэр и Fail2Ban
• Настроить логирование и ротацию логов
• Провести тестовые подключения и проверки прав

Чек‑лист разработчика/интегратора:

• Протестировать сценарии загрузки/выгрузки
• Проверить работу reget/reput при прерывании
• Обработать пути с пробелами и кодировки имён файлов
• Убедиться в корректности прав доступа на файловом уровне

Чек‑лист конечного пользователя:

• Получил инструкции по подключению (хост, порт, логин, ключ)
• Проверил загрузку/скачивание небольших файлов
• Знает, как возобновлять передачи и где смотреть ошибки

Критерии приёмки

1. Пользователь из группы sftp_group при подключении не получает оболочку SSH и попадает в chroot /data/%u.
2. Пользователь может загружать и скачивать файлы в выделенный подкаталог, но не может записывать в корень chroot.
3. Сервис sshd стартует без ошибок после конфигурации (sshd -t возвращает пустую строку).
4. Аутентификация по ключам работает, если она включена; парольная аутентификация отключена при требовании.
5. Логи фиксируют успешные и неудачные попытки подключения для последующего аудита.

Когда SFTP не подходит (ограничения и альтернативы)

• Большие потоки мелких файлов и высокая латентность: рассмотрите rsync поверх SSH или специализированные решения для репликации.
• Необходимость сложной синхронизации и конфликтов версий: используйте систем для синхронизации/репликации (например, Syncthing, Unison) или Git для версионного контроля.
• Требуется веб‑доступ к файлам через браузер: рассмотрите WebDAV над HTTPS.

Часто задаваемые вопросы

Нужно ли устанавливать SFTP‑клиент?

Большинство Linux систем поставляются с терминальным клиентом sftp по умолчанию. Для Windows можно использовать WinSCP или FileZilla. Для автоматизации — native sftp в скриптах или scp/rsync.

Можно ли использовать публичные ключи вместо паролей?

Да. Аутентификация по ключам (public key) безопаснее паролей и рекомендуется для продакшн‑систем. Ключи размещаются в ~/.ssh/authorized_keys и их права должны быть корректными.

Можно ли одновременно хостить SSH и SFTP?

Да. SFTP работает поверх SSH; если вы используете конфигурацию с ForceCommand internal-sftp только для группы sftp_group, то обычные SSH‑пользователи продолжат получать оболочку и полный доступ в соответствии с их правами.

Краткое резюме

SFTP — безопасный и простой в развёртывании способ передачи файлов в Linux. Главные шаги: установить openssh-server, создать изолированные группы/пользователей, правильно настроить chroot и sshd_config, включить ключевую аутентификацию и обеспечить мониторинг. Для продакшна обязательно дополнить настройку брандмауэром, Fail2Ban и политиками хранения логов.

Важно: тестируйте каждый шаг в безопасной тестовой среде перед переносом настроек в продакшн.