Коротко: SSH працює по TCP, а не по UDP, і це не випадковий вибір розробників, а пряме наслідок того, яке завдання вирішує протокол віддаленого керування сервером. Різниця між TCP і UDP визначає, чому SSH поводиться передбачувано навіть на нестабільному каналі.
SSH працює по TCP
Протокол SSH від самого початку спроєктовано поверх TCP, і він використовує порт 22 саме як TCP-порт. Будь-яке SSH-зʼєднання — це спершу встановлення TCP-сесії з обміном пакетами для синхронізації, і лише потім поверх неї розгортається шифрування і автентифікація самого SSH.
Чому саме TCP, а не UDP
Вибір протоколу визначає те, які гарантії він дає на транспортному рівні.
| Властивість | TCP | UDP |
|---|---|---|
| Доставка пакетів | Гарантована, з повтором за втрати | Негарантована |
| Порядок пакетів | Зберігається завжди | Не гарантується |
| Встановлення зʼєднання | Так, через трибічне рукостискання | Ні, пакети відправляються одразу |
| Типове застосування | SSH, HTTP, передавання файлів | DNS, відеопотоки, ігри |
Сесія SSH — це безперервний потік команд і їхніх результатів, де втрата чи перестановка пакетів неприпустима: якби частина команди загубилась мовчки, це могло б призвести до виконання спотвореної команди на сервері. TCP бере цю гарантію на себе, і протоколу SSH не потрібно реалізовувати її самостійно.
Порт SSH і як це перевірити
Стандартний порт SSH — 22, і переконатися, що служба слухає саме TCP, можна прямо на сервері.
ss -tlnp | grep ssh
# Приклад виводу:
# LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=842,fd=3))Літера t у прапорці -tlnp якраз означає TCP — для UDP-служб використовують прапорець -u, і у виводі для sshd він нічого не покаже, бо служба на UDP не слухає.
Чи бувають альтернативи SSH поверх UDP
Прямої альтернативи SSH на UDP не існує, та є суміжні інструменти, які використовують UDP заради стійкості до втрати пакетів на мобільних і нестабільних мережах — наприклад, mosh, який поверх UDP синхронізує стан термінала, а не передає потік команд як є. Це окремий протокол, а не версія SSH, і для первинної автентифікації він все одно звертається до звичайного SSH по TCP, що докладно описано в статті про підключення до VDS по SSH.
Що це означає для налаштування файрвола
Оскільки SSH працює по TCP, правило файрвола для порту 22 потрібно писати саме для TCP-трафіку — відкриття того самого номера порту для UDP нічого не дасть і не потрібне. Це варто врахувати під час посилення налаштувань сервера, докладно розібраного в статті про hardening sshd_config, і під час роботи з ключами доступу, описаної в матеріалі про SSH-ключі для VDS.
Що робити: як перевірити і захистити порт SSH
Аби переконатися, що SSH налаштовано правильно і доступно лише тим, кому потрібно, достатньо кількох перевірок.
- Перевірте командою ss -tlnp, що sshd слухає порт 22 саме по TCP, а не завис чи не запущений узагалі.
- Переконайтесь, що правило файрвола для порту 22 дозволяє TCP-трафік з потрібних адрес, а не блокує його помилково.
- Вимкніть вхід за паролем на користь SSH-ключів, якщо це ще не зроблено.
- Перевірте журнал підключень на предмет підозрілих спроб входу з незнайомих адрес.
Часті питання
Чи можна змусити SSH працювати по UDP?
Ні, сам протокол SSH визначено поверх TCP, і стандартний sshd не вміє слухати UDP-порт для звичайних сесій. Інструменти на кшталт mosh, які використовують UDP, реалізують власний протокол поверх нього, а не перемикають SSH на інший транспорт.
Чому SSH інколи зависає на нестабільному Wi-Fi?
TCP-зʼєднання SSH тримає стан сесії, і за тривалого розриву мережі воно не відновлюється автоматично — доводиться підключатись наново. Саме для таких умов і зʼявились інструменти поверх UDP, які переживають розрив звʼязку без втрати сесії.
Чи потрібно відкривати UDP-порт 22 у файрволі для SSH?
Ні, це не потрібно і не дасть ефекту: sshd не слухає UDP на жодному порту, тому правило для UDP/22 лишиться мертвим і не вплине на роботу SSH. Достатньо коректного правила для TCP/22.