Коротко: 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.