В статье разберём, чем SFTP отличается от FTP и FTPS, как подготовить сервер, подключиться из терминала и графических клиентов, автоматизировать обмен и устранить частые ошибки.
Что такое SFTP
В неформальных материалах SFTP часто расшифровывается как Secure File Transfer Protocol, но более корректная расшифровка — SSH File Transfer Protocol, то есть отдельный протокол работы с файлами поверх SSH.
Главное преимущество SFTP — безопасность, поэтому его часто используют для обмена данными с удалёнными серверами. Для работы SFTP использует только один порт (по умолчанию 22). Весь трафик — команды и содержимое файлов — проходит по шифрованному каналу, а доступ защищается паролем или ключом. Использовать пароль не всегда безопасно — злоумышленник может его подобрать. Поэтому лучшей практикой считается ключ.
Дополнительно сервер может ограничить пользователя рабочим каталогом, чтобы он не видел остальную файловую систему.
Как устанавливается SFTP-подключение
Подключение начинается с TCP-сессии на адрес и порт сервера. Затем SSH-сервер предъявляет свой ключ. При первом соединении клиент показывает отпечаток ключа и предлагает сохранить его в known_hosts. При повторном подключении отпечаток сверяется автоматически. Если ключ неожиданно изменился, это повод остановиться и проверить причину: сервер мог быть переустановлен, но возможна и подмена узла.
Следующий этап — аутентификация пользователя. Сервер может принять пароль, SSH-ключ или несколько методов в зависимости от политики. При входе по ключу закрытая часть ключа остаётся у пользователя; сервер получает только открытый ключ из файла authorized_keys. После успешной проверки запускается подсистема SFTP, и клиент получает доступ только к тем каталогам и операциям, которые разрешены его учётной записи.
Шифрование защищает не только сам файл. В защищённом канале передаются также имена файлов, пути, команды, пароли при парольной аутентификации и метаданные. Это важное отличие от обычного FTP.
Чем SFTP отличается от FTP и FTPS
SFTP часто путают с другими протоколами — FTP и FTPS. На деле это три разных протокола, которые отличаются архитектурой и уровнем безопасности.
FTP — устаревший протокол. Он работает через два канала: управляющий и канал данных. Сначала клиент подключается к серверу по управляющему каналу: передаёт логин и пароль, запрашивает список каталогов, отправляет команды на загрузку, скачивание, переименование или удаление файлов. А для самой передачи данных открывается отдельное соединение — причём заново для каждого файла и даже для получения списка содержимого каталога.
Передача данных работает в двух режимах. В активном режиме сервер сам подключается к клиенту для передачи данных — это неудобно, если клиент находится за файрволом или NAT. В пассивном режиме клиент подключается к одному из дополнительных портов, которые открывает сервер; такой вариант обычно проще для клиента, но требует настроить диапазон портов на сервере и в файрволе. В классическом FTP оба канала не шифруются: логин, пароль и содержимое файлов передаются открыто. В публичной сети это риск: данные может перехватить тот, кто получит доступ к трафику, поэтому сейчас протокол практически не используют.
FTPS — это FTP с TLS-шифрованием. Он защищает канал, однако сохраняет особенности FTP: использование двух соединений, активный и пассивный режимы, диапазон портов для пассивного режима. Из-за этого администратору иногда приходится отдельно настраивать firewall и NAT. FTPS полезен, когда нужно сохранить совместимость с FTP-клиентами и инфраструктурой TLS.
SFTP — это отдельный протокол, который использует транспорт SSH. Клиент сначала устанавливает SSH-соединение, а затем запрашивает подсистему SFTP внутри уже защищённого канала. Как правило, достаточно открыть один TCP-порт. Клиент проверяет ключ сервера, пользователь проходит аутентификацию, после чего все команды и передаваемые файлы шифруются. SFTP — практичный выбор для Linux-серверов и большинства задач, где уже есть SSH.
Перед настройкой: поддерживаемые системы и проверка OpenSSH
Инструкция рассчитана на современные серверные версии Debian, Ubuntu и RHEL-подобных дистрибутивов: RHEL, AlmaLinux и Rocky Linux. Команды подходят для актуальных выпусков этих систем с systemd; в старых или сильно модифицированных дистрибутивах пути к конфигурации, менеджер пакетов и имя службы могут отличаться. На большинстве таких дистрибутивов Linux сервер SFTP входит в пакет OpenSSH.
На сервере должен быть установлен компонент openssh-server, а на компьютере администратора — клиент ssh или sftp.
Проверьте наличие клиента на своём компьютере:
ssh -VПроверьте наличие сервера на удалённой машине:
sshd -VКоманда может вывести версию в поток ошибок — это нормальное поведение.
Также можно проверить саму службу. В Debian и Ubuntu служба обычно называется ssh. В RHEL, AlmaLinux и Rocky Linux — sshd:
systemctl status ssh
systemctl status sshdЕсли служба не установлена, установите и запустите OpenSSH-сервер.
Для Debian и Ubuntu:
sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now sshДля RHEL, AlmaLinux и Rocky Linux:
sudo dnf install openssh-server
sudo systemctl enable --now sshdНастройка SFTP-сервера
Важно: перед изменением настроек подключитесь к серверу по SSH и не закрывайте текущую сессию. Ошибка в файле sshd_config может заблокировать новые подключения: например, из-за опечатки, неверного правила доступа или отключённого способа аутентификации. Если закрыть рабочую сессию до проверки, восстановить доступ можно будет только через консоль хостинга, панель виртуальной машины или техническую поддержку.
Убедитесь, что файрвол разрешает входящие подключения к SSH-порту. Обычно это TCP-порт 22; если SSH настроен на другой порт, укажите его вместо 22.
В Ubuntu с UFW:
sudo ufw allow OpenSSHВ RHEL-подобных системах с firewalld:
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reloadЕсли сервер находится в облаке, проверьте также правила Security Group или сетевого файрвола в панели провайдера.
Базовая конфигурация находится в файле /etc/ssh/sshd_config. В современных сборках SFTP нередко уже включён.
Для изолированных пользователей удобно использовать встроенный сервер internal-sftp. Он работает внутри процесса sshd, поэтому в chroot-каталог не нужно копировать отдельнуюпрограмму sftp-server, библиотеки и системные файлы. Это делает настройку короче и снижает вероятность ошибки с правами или недостающими файлами. Откройте конфигурацию:
sudo nano /etc/ssh/sshd_configНайдите существующую директиву Subsystem sftp. Найдите строку, начинающуюся с Subsystem sftp, и замените её на:
Subsystem sftp internal-sftpНе добавляйте вторую строку Subsystem sftp: в конфигурации должна остаться только одна такая директива.
Subsystem sftp internal-sftpНе перезапускайте службу вслепую. После каждого изменения проверяйте синтаксис, выполните:
sudo sshd -tЕсли команда не вывела ошибок, примените конфигурацию:
sudo systemctl reload sshНа некоторых системах вместо reload используйте sudo systemctl reload sshd. После этого в отдельном окне выполните пробное SFTP-подключение. Только когда оно успешно, можно завершать старую SSH-сессию.
Настройка пользователей, их прав доступа и каталогов
Не выдавайте SFTP-доступ под root. Если пароль или ключ root-пользователя попадёт третьему лицу, он получит не только доступ к файлам, но и полный контроль над сервером: сможет менять конфигурацию, устанавливать программы и удалять данные, изменить пароль, удалить ваш ключ доступа — вы не попадете на свой же сервер.
Для обмена файлами лучше создать отдельную техническую учётную запись. Её можно ограничить одной рабочей папкой, отключить интерактивную оболочку и при необходимости быстро удалить без риска для остальных пользователей сервера. Ниже создадим такого отдельного пользователя sftpuser. Он не будет иметь полноценного доступа к серверу: после входа увидит только свой рабочий каталог и сможет передавать файлы через SFTP. Ниже пошагово настроим такую учетную запись.
Шаг 1. Создание группы и SFTP-пользователя
Укажите для пользователя оболочку nologin, чтобы запретить интерактивный вход по SSH. Её расположение зависит от дистрибутива. В примере ниже используется команда с автоматической подстановкой пути оболочки. Команды выполняются с правами root или через sudo:
sudo groupadd --force sftpusers
sudo useradd -M -d /home/sftpuser -g sftpusers -s "$(command -v nologin)" sftpuser-g sftpusers назначает пользователю основную группу, а -M не создаёт домашний каталог автоматически: далее мы создадим его сами с безопасными правами. Конструкция $(command -v nologin) подставляет фактический путь к программе nologin в текущем дистрибутиве. Оболочка nologin запрещает интерактивный SSH-сеанс; пользователь будет работать только через SFTP.
При необходимости проверьте пользователя:
id sftpuserЕсли планируется парольный вход, задайте пароль. Для доступа по ключу этот шаг не нужен:
sudo passwd sftpuserШаг 2. Подготовка изолированного каталога и папки для файлов
Создаём изолированный каталог и рабочую папку.
# Корень изолированной области: доступен для изменения только root
sudo install -d -o root -g root -m 0755 /home/sftpuser
# Рабочая папка, куда пользователь сможет загружать файлы
sudo install -d -o sftpuser -g sftpusers -m 0750 /home/sftpuser/uploadПосле настройки ChrootDirectory %h каталог /home/sftpuser станет корнем SFTP-сессии. OpenSSH требует, чтобы все каталоги на пути к нему принадлежали root и не были доступны для записи другим пользователям. Иначе пользователь мог бы изменить границы своей изоляции.
Поэтому запись разрешена не в самом /home/sftpuser, а только во внутренней папке upload (/home/sftpuser/upload). В SFTP-клиенте она будет видна как upload.
Шаг 3. Добавление пользовательского SSH ключа
Для технического SFTP-пользователя удобно хранить открытый ключ вне его домашнего каталога — в каталоге, которым управляет root. Это упрощает управление ключами и не смешивает файл авторизации с каталогом, который используется как корень изолированной SFTP-сессии.
Создайте каталог для ключей и скопируйте в него открытый ключ пользователя:
sudo install -d -o root -g root -m 0755 /etc/ssh/authorized_keys
sudo install -o root -g root -m 0600 /path/to/public-key.pub /etc/ssh/authorized_keys/sftpuserЗдесь /path/to/public-key.pub — путь к открытому ключу, который нужно загрузить на сервер. Файл ключа должен называться так же, как пользователь: в этом примере — sftpuser.
Хранение ключа вне домашнего каталога упрощает управление доступом: пользователь не может сам заменить разрешённый ключ, а администратор может централизованно добавлять и отзывать ключи.
Шаг 4. Добавление правил SFTP в конфигурацию OpenSSH
Теперь настройте OpenSSH. Откройте конфигурационный файл:
sudo nano /etc/ssh/sshd_configНайдите существующую строку, начинающуюся с Subsystem sftp, и замените её.
Subsystem sftp internal-sftpЗатем в конец файла, после общих настроек, добавьте блок для SFTP-пользователей. В результате фрагмент конфигурации должен выглядеть так:
# Общая настройка встроенного SFTP-сервера
Subsystem sftp internal-sftp
# Ограничения для пользователей группы sftpusers
Match Group sftpusers
ChrootDirectory %h
ForceCommand internal-sftp
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitTTY no
X11Forwarding no
AllowTcpForwarding no
PermitTunnel noВ конфигурации должна остаться только одна директива Subsystem sftp. Она находится вне Match, потому что задаёт встроенный SFTP-сервер для OpenSSH в целом. Блок Match действует только для группы sftpusers и должен располагаться в конце файла.
ChrootDirectory %h изолирует пользователя в его домашнем каталоге. ForceCommand internal-sftp запрещает интерактивную оболочку и выполнение произвольных команд: после входа пользователь может работать только с файлами по SFTP.
Директива AuthorizedKeysFile /etc/ssh/authorized_keys/%u задаёт путь к открытому ключу. Переменная %u заменяется именем подключающегося пользователя: для sftpuser сервер прочитает файл /etc/ssh/authorized_keys/sftpuser.
Параметры PasswordAuthentication no и KbdInteractiveAuthentication no отключают вход по паролю и интерактивные запросы. PermitTTY no запрещает терминальную сессию, а X11Forwarding, AllowTcpForwarding и PermitTunnel отключают не нужные для передачи файлов возможности.
Match действует до конца файла, поэтому этот блок должен быть последним. Если для SFTP-пользователей требуется вход по паролю, не добавляйте PasswordAuthentication no и KbdInteractiveAuthentication no; для технических учётных записей предпочтительнее ключи.
Шаг 5. Проверка конфигурации и подключения
Не закрывайте текущую SSH-сессию. Сначала проверьте синтаксис конфигурации:
sudo sshd -tЗатем проверьте итоговые параметры именно для sftpuser:
sudo sshd -T -C user=sftpuser,host=localhost,addr=127.0.0.1 \
| grep -E '^(chrootdirectory|forcecommand|authorizedkeysfile|pubkeyauthentication|passwordauthentication|kbdinteractiveauthentication|permittty|x11forwarding|allowtcpforwarding|permittunnel) 'В выводе должны быть:
forcecommand internal-sftp, authorizedkeysfile /etc/ssh/authorized_keys/%u, passwordauthentication no и permittty no.Если ошибок нет, примените конфигурацию:
sudo systemctl reload sshВ RHEL, AlmaLinux и Rocky Linux используйте:
sudo systemctl reload sshdОткройте второй терминал и проверьте вход по ключу:
sftp -i ~/.ssh/sftp_ed25519 sftpuser@адрес_сервераПосле подключения передайте тестовый файл:
put ./test.txt upload/test.txt
ls uploadВ SFTP /home/sftpuser отображается как /, поэтому рабочая папка доступна по пути upload. Если файл появился в upload/test.txt, настройка завершена. Только после этого можно закрыть старую SSH-сессию.
Права новых файлов зависят от клиента и umask на сервере. Не выставляйте разрешения 777 «на всякий случай». Обычно для приватных загрузок достаточно 640 или 600 для файла и 750 для каталога. Если загруженные файлы должен читать веб-сервер, добавьте его пользователя в нужную группу или используйте отдельный каталог с понятной групповой политикой.
Подключение через терминал: sftp и scp
К SFTP-серверу можно подключиться прямо из терминала с помощью клиента sftp. Он входит в OpenSSH и обычно уже доступен в Linux и macOS, а в современных версиях Windows — после установки OpenSSH Client. Общий синтаксис команды для подключения:
sftp пользователь@адрес_сервераЕсли SSH использует нестандартный порт, укажите его с заглавной P:
sftp -P 2222 sftpuser@example.comПосле соединения откроется приглашение sftp>. В нём доступны команды pwd, lpwd, ls, lls, cd, lcd, mkdir, rm, rename, get и put. Первые две показывают удалённый и локальный текущий каталог. Передайте один файл на сервер так:
put ./test.txt upload/test.txtСкачайте файл обратно:
get upload/report.zip ./report.zipДля каталога используйте рекурсивный ключ:
put -r ./site upload/site
get -r upload/archive ./archiveКоманда scp тоже передаёт данные через SSH и полезна для разовой операции без интерактивного режима. Начиная с OpenSSH 9.0 клиент scp по умолчанию использует SFTP-протокол. В более старых версиях используется устаревший SCP-протокол; при совместимости со старыми серверами поведение следует проверить отдельно. Например:
scp -P 2222 ./report.zip sftpuser@example.com:upload/report.zipДля регулярных сценариев sftp удобнее, потому что поддерживает список команд и позволяет явно обработать ошибки. Независимо от клиента, при первом подключении проверяйте отпечаток ключа сервера, а не подтверждайте его автоматически.
Подключение через FileZilla и WinSCP
FileZilla и WinSCP — графические SFTP-клиенты, которые устанавливаются на компьютер пользователя. Они показывают файлы на компьютере и на сервере в двух панелях и позволяют передавать их мышью. Это удобно, если не хочется работать с командами в терминале, нужно сравнить каталоги или передать сразу несколько файлов.
FileZilla доступна для Windows, macOS и Linux, WinSCP — только для Windows. Программы устанавливаются отдельно, но на сервере достаточно уже настроенного SFTP через OpenSSH. Данные для подключения те же: адрес или домен, SSH-порт (обычно 22), имя пользователя и пароль либо закрытый ключ.
В FileZilla откройте Менеджер сайтов, создайте новое подключение и выберите протокол SFTP. В поле Хост укажите домен или IP-адрес, в поле Порт — 22 или выбранный для SSH порт, затем введите имя пользователя. Для ключевой аутентификации выберите файл закрытого ключа; для парольной — введите пароль, если это разрешено политикой сервера. Если клиент не принимает формат ключа, обновите его или используйте поддерживаемый формат.
После первого соединения FileZilla покажет отпечаток ключа сервера. Сверьте его с отпечатком, который сообщает администратор, и только затем сохраните. В левой части окна находится файловая система вашего компьютера, в правой — удалённый каталог. Перетаскивание файла запускает копирование; очередь внизу показывает прогресс и ошибки.
В WinSCP при создании нового подключения выберите File protocol: SFTP. Укажите Host name, Port number, User name и способ входа.
Если используется ключ, откройте Advanced — SSH — Authentication и выберите приватный ключ. В интерфейсе Commander слева отображаются локальные файлы, справа — удалённые. Такой режим удобен для сравнения каталогов и переноса нескольких объектов.
На общем компьютере не сохраняйте пароль в клиенте. Даже если используете быстрое подключение, не соглашайтесь на сохранение пароля. Лучше создать профиль без пароля и подключиться по ключу с кодовой фразой.
FileZilla и WinSCP также умеют ограничивать число одновременных передач; уменьшите его при медленном канале или высокой нагрузке на сервер.
Безопасность SFTP
SFTP защищает данные в пути, но не заменяет администрирование доступа. Основная практика — вход по SSH-ключам. На рабочем компьютере создайте современный ключ:
ssh-keygen -t ed25519 -a 64 -C "sftp access"Открытый ключ из файла с расширением .pub добавьте на сервер в файл /etc/ssh/authorized_keys/sftpuser, где sftpuser — имя SFTP-пользователя. Этот путь задан директивой AuthorizedKeysFile в конфигурации OpenSSH. Закрытый ключ остаётся только на компьютере пользователя: не отправляйте его по почте, не добавляйте в репозиторий и не размещайте на сервере. Защитите ключ кодовой фразой и, если возможно, храните его в менеджере ключей или на аппаратном токене.
Когда вы убедились, что ключевой вход работает, можно отключить парольную аутентификацию для группы SFTP. Добавьте внутрь блока Match:
PasswordAuthentication no
PubkeyAuthentication yesНе отключайте парольный вход глобально, пока не проверите, что у администратора есть рабочий ключ и аварийный способ доступа через консоль провайдера. Если используете AllowUsers, перечислите в ней всех пользователей, которым нужен SSH-доступ, включая администратора. Для ограничения по IP-адресам или сетям используйте правила файрвола или Match Address.
Не используйте root для передачи файлов. Если для администрирования есть отдельный пользователь с sudo и рабочим SSH-ключом, запретите прямой вход под root. Добавьте в общую часть /etc/ssh/sshd_config, до блока Match:
PermitRootLogin noПеред применением настройки убедитесь, что можете войти под обычной административной учётной записью и выполнить команды через sudo.
Если к серверу подключаются только сотрудники и служебные сценарии (например, задания резервного копирования, развёртывания или CI/CD) ограничьте SSH-доступ доверенными IP-адресами через firewall либо разрешите его только из корпоративной сети или VPN. Это уменьшает число нежелательных подключений и попыток подбора.
Регулярно проверяйте журнал SSH: в нём видны успешные и неудачные попытки входа, адреса клиентов и ошибки аутентификации.
В Debian и Ubuntu:
sudo journalctl -u ssh --since "24 hours ago"
sudo journalctl -u ssh -fВ RHEL, AlmaLinux и Rocky Linux:
sudo journalctl -u sshd --since "24 hours ago"
sudo journalctl -u sshd -fПри использовании rsyslog записи также могут находиться в /var/log/auth.log на Debian и Ubuntu и в /var/log/secure на RHEL-подобных системах. Многочисленные неудачные попытки входа с одного адреса могут означать подбор пароля. Если SSH-порт доступен из интернета, настройте временную блокировку таких адресов с помощью Fail2ban или ограничение частоты подключений средствами firewall. При отключённой парольной аутентификации подбор пароля не даст доступ к серверу, но защита от лишних подключений и перегрузки всё равно полезна.
Регулярно удаляйте ключи уволенных сотрудников, просматривайте логи SSH и разделяйте учётные записи. Одна общая учётная запись усложняет аудит: по логам нельзя понять, кто именно изменил файл. Для резервных копий и автоматизации создавайте отдельный ключ и отдельного пользователя с минимальными правами.
Автоматическая передача файлов
Для автоматизации используйте отдельный ключ с минимально необходимыми правами. Если задача запускается без участия человека, применяйте защищённое хранилище секрета, ssh-agent или системный агент. Ключ без passphrase допустим только для отдельной технической учётной записи с минимальными правами и дополнительными ограничениями доступа, например firewall-правилами. Пароль в скрипте — плохая практика: он попадёт в историю команд, файлы конфигурации или журналы процесса. Если имя файла содержит дату, передайте команды через heredoc: тогда $(date) развернёт именно shell, а не клиент sftp.
sftp -b - sftpuser@example.com <<EOF
cd upload
put /srv/backup/site-$(date +%F).tar.gz
bye
EOFКлюч -b переводит sftp в batch-режим: клиент читает команды из стандартного ввода или файла вместо интерактивного режима. Сам sftp не выполняет shell-подстановки, поэтому строка с $(date) внутри готового batch-файла будет передана буквально. Если список команд нужно хранить в файле, генерируйте его shell-скриптом до запуска sftp. При критичных операциях полезно завершать скрипт при ошибке и записывать вывод в лог. Если определённая команда может завершиться ошибкой без остановки всего задания, перед ней можно поставить дефис, например -rm upload/old-file.tar.gz.
Для запуска по расписанию подойдёт cron или systemd timer. Сначала выполните скрипт вручную под тем же пользователем, от которого будет запускаться задача. В окружении cron часто нет привычного PATH и SSH-агента, поэтому указывайте абсолютные пути и при необходимости используйте ключ через параметр -i.
Типичные ошибки
Permission denied. Ошибка означает, что сервер отказал в аутентификации или в операции с каталогом. Проверьте имя пользователя, открытый ключ, права на authorized_keys и разрешения папки upload. При chroot особенно важно, чтобы домашний каталог принадлежал root, а доступная для записи папка — пользователю. Для диагностики клиент можно запустить с подробным выводом: sftp -vvv пользователь@сервер.
Также на RHEL-подобных системах SELinux иногда блокирует запись в каталог SFTP, даже если права Linux настроены правильно. Если вход проходит, но при загрузке появляется Permission denied, проверьте последние блокировки:
sudo ausearch -m AVC -ts recentСтроки, где упоминается sshd, указывают, что операцию мог заблокировать SELinux. В этом случае не отключайте SELinux целиком: настройте контекст конкретного рабочего каталога по документации своего дистрибутива.
Connection refused. Сервер не принимает соединение на указанном адресе и порту. Проверьте, запущена ли служба ssh или sshd, верный ли порт указан в клиенте и не блокирует ли соединение firewall. Команда sudo ss -tlnp | grep ssh поможет увидеть, слушает ли сервер нужный порт и процесс, который его открыл.
Connection timed out. Клиент не получает ответа от сервера. Обычно причина в маршрутизации, закрытом порте на уровне firewall, сетевой группы облака или неверном IP-адресе.
Сначала проверьте, доступен ли именно SSH-порт по TCP:
nc -vz example.com 22Если SSH работает на нестандартном порту, замените 22 на его номер. Успешный результат означает, что TCP-соединение с портом устанавливается. Тайм-аут указывает на проблему с маршрутизацией, firewall или правилами провайдера. Connection refused обычно означает, что сервер доступен, но служба не слушает указанный порт.
Чтобы увидеть этап, на котором останавливается подключение, запустите SSH-клиент с подробным выводом: ssh -vvv user@example.com
Для проверки именно SFTP можно использовать:
sftp -vvv sftpuser@example.comПосле этого проверьте правила firewall на сервере, Security Group в облаке и правильность IP-адреса и порта.
Could not chdir to home directory или bad ownership or modes for chroot directory. Эти сообщения говорят о неправильной структуре прав для изоляции. Проверьте владельца и режим каждого каталога на пути ChrootDirectory. Верхняя директория должна быть root:root и не должна быть доступна для записи группе или другим пользователям; рабочая папка создаётся внутри неё.
Медленная передача файлов. Сначала убедитесь, что проблема не в сети: измерьте задержку и пропускную способность, проверьте загрузку процессора и диска сервера. Для множества маленьких файлов полезно сначала собрать их в архив.
Заключение
SFTP — отдельный протокол передачи файлов поверх SSH. Он подходит для ручной работы, развёртывания и автоматизации: один защищённый канал объединяет аутентификацию, команды и передачу данных. Начните с отдельного пользователя, ограничьте его рабочим каталогом, настройте ключевой вход и обязательно выполните sudo sshd -t перед применением изменений через systemctl reload. Такой подход снижает риск утечки файлов и делает обмен данными предсказуемым.
