Як використовувати SFTP для безпечної передачі файлів на віддалений сервер

Робота будь-якої ІТ-інфраструктури пов’язана з необхідністю передачі файлів між вузлами, чи то передача з локального комп’ютера на сервер і назад, чи то між середовищами або серверами. І майже завжди під час передачі файлів мережею існує ризик перехоплення даних або їх витоку, особливо у разі помилок у налаштуваннях. Причому мова може йти не тільки про якісь чутливі дані на кшталт бекапів або конфігурацій із секретами. Навіть передача, здавалося б, звичайних файлів, як-от завантаження сайту або вивантаження логів, може стати точкою входу для атаки на інфраструктуру, якщо ваш канал зв’язку не був захищений. Додайте сюди звичайний людський фактор, і тоді ризик перестає бути гіпотетичним. Варто комусь встановити неправильні права, слабкі паролі або залишити відкритими зайві порти - і можете вважати, що ваш сервер уже скомпрометований.

Довгий час для завдань передачі файлів використовувався звичайний FTP. Це простий і зрозумілий інструмент, який підтримується практично скрізь. Але з точки зору безпеки це рішення з іншої, минулої епохи. Справа в тому, що FTP передає дані у відкритому вигляді, тобто всі ваші логіни, паролі та вміст файлів передаються як є. Передачу файлів по FTP можна уявити собі як відправку секретного листа, але без конверта, коли будь-хто, хто опинився "по дорозі", може прочитати все, що ви написали.

SFTP (SSH File Transfer Protocol) вирішує цю проблему без зайвого ускладнення інфраструктури. Він не вимагає окремого сервісу, не змушує відкривати додаткові порти і не додає зайвих точок відмови. Натомість він використовує вже існуюче SSH-з'єднання та вбудовує в нього передачу файлів, і в результаті весь ваш трафік шифрується за замовчуванням.

Як ви вже, напевно, зрозуміли, SFTP - це передача файлів поверх SSH (Secure Shell), протоколу, спеціально розробленого для захищених з'єднань.

 

 

 

 

Ключові відмінності FTP, SFTP та FTPS

Наразі для передачі файлів найчастіше використовуються три протоколи: FTP, SFTP та FTPS. Але між цими протоколами існує архітектурна різниця, що істотно відрізняє один від іншого в плані безпеки інформації.

Зрозуміло, що всі три вирішують одне й те саме завдання - передачу файлів по мережі, але роблять вони це по-різному. Звичайний FTP - це класичний протокол передачі даних, який працює без шифрування. Він дуже простий, але, на превеликий жаль, досить вразливий. У FTPS спробували додати рівень безпеки, перетворюючи звичайний FTP на захищене SSL/TLS-з'єднання, але при цьому зберігаючи його складну модель з безліччю з'єднань. На відміну від перших двох, SFTP йде іншим шляхом. Він спочатку будується поверх SSH і працює як єдиний захищений канал.

Звідси випливають відмінності не тільки в безпеці, але й у налаштуванні та поведінці, наприклад, які порти використовуються, як відбувається аутентифікація, наскільки складно налаштувати брандмауер, а також як з'єднання поводиться в умовах реальних мереж.

Тому перед тим, як обирати протокол під конкретне завдання, важливо розуміти цю різницю не на рівні термінів, а на рівні принципів роботи. Нижче ми спробували навести стисле порівняння цих трьох протоколів у вигляді простої порівняльної таблиці, яка допомагає швидше побачити відмінності та зрозуміти, в рамках яких завдань буде доречним той чи інший інструмент.

 

Протокол	Шифрування	Порти	Аутентифікація	Складність налаштування	Найкращі сценарії використання
FTP	Ні	21 + динамічні	Логін/пароль	Низька	Внутрішні мережі без вимог до безпеки, тимчасові тестові середовища, застарілі системи
FTPS	Так (SSL/TLS)	21 + динамічні	Логін/пароль	Середня	Інтеграції з корпоративними системами (наприклад, банки, старі ERP), де потрібен TLS, але зберігається сумісність з FTP
SFTP	Так (SSH)	22	Ключі / пароль	Низька	DevOps та production-інфраструктура, резервне копіювання, деплой, обмін файлами між серверами, робота через нестабільні мережі та NAT

 

 

 

Як SFTP працює "під капотом"

Всередині все досить просто, оскільки засновано на стандартному SSH. Клієнт встановлює захищене з'єднання з сервером, проходить аутентифікацію, а далі запускається підсистема SFTP.

Команди на кшталт ls, put, get (докладніше нижче) - це не звичайні команди оболонки, які виконуються в системі сервера. Це операції самого SFTP-протоколу, які передаються та обробляються всередині захищеного з'єднання.

Простіше кажучи, під час роботи через SFTP ви не отримуєте доступ до командного рядка самого віддаленого сервера. Ви працюєте з файловою системою за допомогою набору заздалегідь визначених дій, таких як перегляд списку файлів, завантаження, скачування або видалення.

Зате безпека вирішує більшість можливих питань. Шифрування - симетричне, ключі - асиметричні, обмін відбувається через перевірені алгоритми, тому якщо сервер налаштований нормально, перехопити дані майже неможливо.

Важливо також розуміти, що SFTP не є надбудовою у звичному розумінні, а є окремою підсистемою всередині стандартного SSH-сервера. В OpenSSH ця підсистема називається internal-sftp. І коли клієнт підключається, сервер може або надати йому повноцінний shell, або відразу "замкнути" його в рамках SFTP-середовища без можливості виконання команд. Ця особливість активно використовується для обмеження доступу до сервера, наприклад для клієнтів або підрядників, яким потрібен лише доступ до файлів, але у яких не повинно бути можливості виконання команд на сервері.

З точки зору мережевої взаємодії все теж виглядає досить акуратно, оскільки на відміну від FTP і FTPS, де використовується кілька з'єднань (control + data), SFTP працює через одне TCP-з'єднання. Це значно спрощує роботу за NAT, через брандмауер або в хмарних інфраструктурах.

Але, звичайно, як і скрізь, у SFTP теж є свої мінуси. Таким мінусом є буферизація під час роботи з файлами, коли SFTP розбиває передачу на пакети та обробляє їх послідовно. Це, звичайно, робить його більш надійним, але іноді менш швидким у порівнянні з більш прямолінійними інструментами на кшталт SCP. Зате при нестабільних з'єднаннях SFTP поводиться набагато більш передбачувано і рідше обриває передачу.

 

Які алгоритми шифрування використовуються

Як ми вже сказали вище - SFTP успадковує все від SSH. Тому в типовій конфігурації використовуються такі протоколи:

• AES-256 - який де-факто зараз є стандартом для шифрування;
• ChaCha20 - цей протокол працює швидше на системах із застарілими та слабкими процесорами;
• ED25519 - сучасний алгоритм для ключів.

 

Додатково в процесі з'єднання використовуються ще два протоколи:

• ECDH (Elliptic Curve Diffie-Hellman) - використовується для безпечного обміну ключами;
• HMAC (наприклад, hmac-sha2-256) - використовується для перевірки цілісності даних.

 

Тобто ми бачимо, що це не просто якесь шифрування, а цілком зрілий стек, перевірений роками, безліччю аудитів і реальними атаками. І в більшості випадків він набагато безпечніший, ніж будь-який саморобний захист поверх небезпечного протоколу. Та й навіщо винаходити велосипед вдруге.

 

 

 

 

Підготовка та налаштування SFTP на сервері

Для того, щоб почати роботу з SFTP на Linux-сервері, у більшості випадків нічого додатково встановлювати не потрібно, оскільки якщо на сервері вже є SSH, значить SFTP теж працює. За замовчуванням увімкнено доступ без будь-яких обмежень, але щоб SFTP дійсно став безпечним і зручним, нам потрібно його трохи доналаштувати.

Наше завдання полягає у створенні окремого користувача для роботи з файлами та виділенні йому окремої директорії, якою й обмежуватиметься його доступ, без можливості зайти в систему через shell.

Почнемо зі створення користувача:

sudo adduser sftpuser

 

Далі нам потрібно підготувати директорію, і тут виникає одна з найпоширеніших помилок, коли цій директорії прописуються неправильні права, через які SFTP або не запускається взагалі, або працює небезпечно. Каталог, в якому буде "замкнений" користувач, повинен належати root:

sudo mkdir -p /home/sftpuser/uploads

sudo chown root:root /home/sftpuser

sudo chmod 755 /home/sftpuser

 

А вже внутрішня папка, куди користувач буде завантажувати файли, призначається йому:

sudo chown sftpuser:sftpuser /home/sftpuser/uploads

 

Після цього нам потрібно налаштувати сам SSH. Відкрийте файл /etc/ssh/sshd_configі в кінці додайте такий блок:

Match User sftpuser

    ChrootDirectory /home/sftpuser

    ForceCommand internal-sftp

    X11Forwarding no

    AllowTcpForwarding no

 

За допомогою цих інструкцій користувач обмежується однією директорією, не отримує доступ до командного рядка і може використовувати тільки SFTP.

Після зміни конфігурації залишається тільки перезапустити SSH-сервер:

sudo systemctl restart ssh

Тепер можна перевірити підключення з віддаленого комп'ютера:

sftp sftpuser@server_ip

 

Якщо все налаштовано правильно, то користувач опиниться всередині своєї директорії і не зможе вийти за її межі. При цьому у нього не буде доступу до shell, а буде доступ виключно до файлів всередині цієї директорії.

На практиці цього достатньо для більшості завдань. Ми отримали простий і безпечний файловий доступ без зайвих налаштувань і надмірної складності.

 

Аутентифікація за ключами

Після базового налаштування SFTP логічним і правильним буде відразу вирішити ще один важливий момент, а саме аутентифікацію. Як ви бачили в попередньому прикладі, за замовчуванням використовується аутентифікація за паролем, але це найслабше місце в ланцюжку, оскільки навіть складні паролі дуже вразливі до перебору, витоків та банального людського фактора.

Проблему можна вирішити, використовуючи замість пароля пари ключів.

Для цього генеруємо ключ на вашому робочому місці, з якого ви будете підключатися до сервера:

ssh-keygen -t ed25519

За замовчуванням ключі зберігаються в ~/.ssh/. Зазвичай достатньо просто натиснути Enter на всіх кроках, але за бажанням можна задати passphrase - додатковий захист для приватного ключа.

 

Далі ключ потрібно передати на віддалений сервер за допомогою команди:

ssh-copy-id user@server_ip

 

Ця команда автоматично додасть публічний ключ до файлу ~/.ssh/authorized_keys на сервері та надасть необхідні права. Після цього можна відразу перевірити з'єднання, для якого пароль вже не знадобиться.

 

Якщо ssh-copy-id недоступний, те саме можна зробити вручну, просто скопіювавши вміст файлу ~/.ssh/id_ed25519.pub і додавши його до ~/.ssh/authorized_keys на сервері.

 

Після того як вхід за ключем запрацює, парольну автентифікацію краще вимкнути назавжди. Для цього в /etc/ssh/sshd_config змініть параметр:

PasswordAuthentication no

 

А потім перезапустіть ще раз SSH-сервіс:

sudo systemctl restart ssh

 

ВАЖЛИВО! Перезавантаження SSH-сервісу робіть тільки після перевірки ключів, інакше ви можете втратити доступ до сервера.

Ось, по суті, і все налаштування. Тепер перейдемо до команд самого SFTP.

 

 

 

Базові команди для роботи з SFTP

Після того як ви підключилися через SFTP до віддаленого сервера, ви потрапляєте в інтерактивне середовище для роботи з файлами. Команди тут прості, але важливо розуміти, що частина з них працює з віддаленою системою, а частина - з вашою локальною системою. Нижче ми перелічимо найбільш часто використовувані команди та коротко опишемо, що вони роблять.

• ls - показує список файлів і каталогів на сервері. Можна використовувати з прапорцями (наприклад, ls -l) для більш детального виводу;
• cd - змінює поточний каталог на сервері;
• put - завантажує файл з локальної машини на сервер (наприклад, put file.txt);
• get - завантажує файл із сервера на локальну машину;
• put -r - завантажує каталог цілком разом із вмістом;
• get -r - завантажує каталог із сервера рекурсивно;
• lcd - змінює поточну директорію на локальній машині (local cd);
• mkdir - створює нову директорію на сервері;
• rm - видаляє файл на сервері;

 

Цього набору цілком достатньо для виконання більшості завдань, таких як, наприклад, завантаження файлів сайту на сервер, передача бекапів, робота з логами тощо. Решта команд використовуються набагато рідше і зазвичай залежать від конкретного клієнта. З повним переліком команд ви можете ознайомитися в будь-якому доступному посібнику, наприклад тут.

 

 

 

Графічні клієнти

Очевидно, що далеко не всім зручно працювати через термінал, особливо коли йдеться про передачу великої кількості різних файлів. У таких випадках набагато простіше використовувати графічний клієнт, який по суті є тим самим SFTP, тільки зі звичним віконним інтерфейсом провідника.

SFTP підтримують майже всі популярні клієнти, такі як FileZilla, WinSCP, Cyberduck та інші. З точки зору користувача підключення в таких клієнтах виглядає так само, як і підключення до звичайного FTP-сервера, але з тією різницею, що потрібно вибрати у випадаючому меню SFTP замість FTP-протоколу. А далі при налаштуванні з'єднання вказуються ті самі базові параметри:

• Host - IP-адреса або домен віддаленого сервера;
• Port - стандартний SSH-порт 22 або той, який ви вказали в налаштуваннях SSH на віддаленому сервері;
• User - ім'я користувача, логін;
• Key file - шлях до приватного ключа, якщо ви використовуєте аутентифікацію за ключами.

 

Після підключення відкривається звичний інтерфейс, поділений на два вікна: локальні файли ліворуч, сервер - праворуч. Файли можна просто перетягувати мишкою, копіювати, видаляти та перейменовувати. Тобто доступні всі ті самі можливості, що й у консолі, тільки без необхідності запам'ятовувати команди.

 

 

 

 

Обмеження та підводні камені

Звичайно, SFTP - це зручний і безпечний інструмент, але, на жаль, не універсальний. І в деяких сценаріях він може поступатися іншим рішенням, що варто враховувати заздалегідь при плануванні своїх робіт.

По-перше, як ми вже згадували на початку статті, його слабким місцем є швидкість передачі даних, адже SFTP працює акуратно, з перевіркою та буферизацією даних, через що іноді поступається в продуктивності більш прямолінійним інструментам на кшталт простого SCP. Ця різниця зазвичай не є критичною, але при передачі великих файлів може бути цілком помітною.

По-друге, відсутність паралельності, оскільки на рівні протоколу SFTP не підтримує багатопотокову передачу даних. Щоправда, деякі клієнти обходять це обмеження своїми власними засобами, але це вже їхня внутрішня реалізація, а не можливості самого SFTP.

І, нарешті, необхідність приділяти особливу увагу роботі з правами доступу, оскільки неправильне налаштування прав на директорію може призвести до того, що користувач побачить більше, ніж повинен, а в разі отримання доступу до цієї директорії зловмисником - до можливості підвищення привілеїв аж до root. Правда, це не проблема SFTP як такого, а скоріше питання уважності при налаштуванні та адмініструванні сервера.

Загалом ці нюанси не роблять SFTP поганим вибором - просто важливо розуміти його можливості та межі його застосування.

Якщо спробувати спростити, то вибір між найбільш популярними інструментами може виглядати так:

• SFTP - універсальний варіант для безпечної передачі файлів. Зручний, зрозумілий і підходить для більшості завдань;
• SCP - швидший завдяки простоті, але менш гнучкий, тому останнім часом поступово відходить на другий план;
• rsync - найкращий вибір для інкрементальної синхронізації та бекапів, оскільки передає лише зміни, а не файли цілком, що може суттєво економити трафік.

 

На практиці, як завжди, все залежить від конкретного завдання. Якщо вам потрібно просто передати файли з одного пристрою на інший, то SFTP цілком вирішує це питання. Але якщо вам важлива швидкість або оптимізація трафіку, тоді є сенс розглянути альтернативи.

 

 

 

 

 

FAQ щодо SFTP

 

Чим SFTP відрізняється від FTP?

SFTP шифрує весь трафік - включаючи логіни, команди та вміст файлів. На відміну від нього, FTP передає дані у відкритому вигляді, через що його використання в інтернеті вважається небезпечним.

 

SFTP і FTPS - це одне й те саме?

Ні, це різні протоколи. FTPS - це класичний FTP з доданим поверх нього шифруванням SSL/TLS, а SFTP спочатку побудований поверх протоколу SSH і працює як єдиний захищений канал.

 

Який порт використовує SFTP?

За замовчуванням використовується порт 22 - той самий, що й для SSH. Це спрощує налаштування, оскільки не потрібно відкривати додаткові порти.

 

Чи можна використовувати SFTP без SSH?

Ні, SFTP не існує окремо від SSH. Це підсистема SSH, яка працює всередині захищеного з'єднання.

 

Наскільки безпечний SFTP?

При використанні SSH-ключів і правильному налаштуванні сервера SFTP вважається дуже надійним. Він захищає не тільки дані, але й сам процес передачі від перехоплення.

 

Що вибрати: SFTP, SCP чи rsync?

SFTP підходить для більшості завдань, де потрібна простота та безпека. SCP швидший, але менш гнучкий, а rsync краще використовувати для синхронізації та передачі лише змінених даних.

 

Чому SFTP не дозволяє виконувати команди на сервері?

Тому що SFTP - це протокол для роботи з файлами, а не віддалений доступ до системи в повному розумінні. Він навмисно обмежений, щоб підвищити безпеку та знизити ризик помилок.

 

 

 

 

Висновки

Отже, ми з'ясували, що SFTP є логічним продовженням того, що вже є на будь-якому Linux-сервері, а саме протоколу SSH. Для його використання вам не потрібна установка якихось додаткових сервісів, не потрібно відкривати зайві порти і, в принципі, без будь-якого складного налаштування ви отримуєте якісний захищений канал для передачі файлів.

Звичайно, деяке налаштування все ж варто провести. Так, наприклад, створивши окремого користувача для передачі файлів, обмеживши права доступу до робочої директорії та встановивши її власника (chroot), а також налаштувавши аутентифікацію за ключами - ви перетворюєте SFTP на надійний та ізольований інструмент для роботи з файлами.

При цьому варто розуміти і його обмеження. Він не найшвидший і не найпросунутіший з точки зору синхронізації. Але в більшості практичних завдань, таких як розгортання додатків, створення бекапів і простий обмін файлами, він цілком задовольняє всі потреби.

І саме тому цей інструмент використовується все частіше, оскільки простота налаштування, передбачуваність роботи та безпека - це те, що в реальній інфраструктурі цінується понад усе.