Сети

SSH поверх TCP: что значит, пакеты, соединение, порты

Что значит «SSH работает поверх TCP»? Разбираем инкапсуляцию SSH-пакетов в TCP-сегменты, установку соединения, порты (22/TCP), взаимодействие протоколов. RFC 4251-4254 и книги для глубокого понимания SSH TCP.

Авторы: НейроАгент

Что означает формулировка «SSH обычно работает поверх TCP»? Означает ли это, что SSH-пакеты инкапсулируются в TCP‑сегменты, или это просто означает, что SSH использует установленное TCP‑соединение как канал передачи байтов? Как именно взаимодействуют SSH и TCP (установка соединения, сегментация данных, порты) и какие RFC или книги стоит почитать, чтобы подробно разобраться?

Формулировка «SSH обычно работает поверх TCP» значит, что протокол SSH использует TCP как надежный транспортный канал для передачи данных, инкапсулируя свои пакеты в TCP-сегменты. Это не просто “туннель поверх”, а полноценная работа поверх TCP-handshake: соединение устанавливается на порту 22, данные сегментируются по правилам TCP, обеспечивая доставку без потерь и порядок. В итоге SSH получает от TCP готовый поток байтов, добавляя сверху шифрование и аутентификацию.

Содержание

Что значит «SSH работает поверх TCP»

Представьте: TCP — это как надежная почтовая служба с гарантией доставки писем в правильном порядке и без потерь. А SSH? Это шифрованный конверт, который кладется в эти письма. Когда говорят, что SSH работает поверх TCP, имеют в виду модель уровней протоколов OSI или TCP/IP: SSH — прикладной уровень (layer 7), TCP — транспортный (layer 4). SSH не заморачивается с UDP или сырым IP, а полагается на TCP для базовой надежности.

Почему именно TCP? Потому что SSH требует строгой последовательности данных — команды, ответы, потоки. UDP подойдет для видео, но не для удаленного терминала, где потерянный байт сломает сессию. Selectel в своем блоге четко объясняет: SSH использует уже установленное TCP-соединение как транспортный канал, просто посылая байты по TCP-сегментам, без лишней “упаковки”.

А “обычно”? Потому что SSH-2 (RFC 4251) по умолчанию на TCP/22, но теоретически можно туннелировать через UDP (например, в WireGuard), хоть и редко. В реальности — 99% случаев именно TCP. Это видно по статистике портов: ssh порт 22 всегда TCP, не UDP.

Но подождите, а если роутер блочит TCP? Тогда SSH не взлетит без туннеля. Коротко: поверх TCP — значит, SSH едет “пассажиром” в TCP-автобусе.

SSH-пакеты в TCP-сегментах: инкапсуляция или поток байтов

Вопрос вашего вопроса бьет в точку: это и инкапсуляция, и поток. SSH формирует свои пакеты (binary packets с заголовками, payload, MAC для целостности), но не “фасует” их в отдельный протокол вроде IP. Вместо этого SSH-поток байтов льется прямо в TCP. TCP сам режет этот поток на сегменты (MTU обычно 1460 байт), добавляя свои заголовки (sequence number, ACK, checksum).

Из RFC 4253: SSH Transport Layer — это низкоуровневый протокол поверх безопасного канала, где данные идут как octet stream в TCP. Нет жесткой “инкапсуляции пакета в пакет” — SSH пишет в сокет, TCP читает и сегментирует. Если SSH-пакет 4 КБ, TCP разобьет на 3 сегмента.

Habr статья о портах SSH подтверждает: “SSH использует TCP как транспортный протокол: соединение через TCP-handshake, данные как поток байтов, пакеты SSH в TCP-сегментах”. Не путайте с SSH-туннелями (local/dynamic forwarding) — там TCP внутри SSH, но базовое соединение всегда TCP снаружи.

Практика: запустите tcpdump -i any tcp port 22 — увидите TCP-сегменты с SSH-трафиком внутри. Нет отдельных UDP или ICMP. Это делает SSH устойчивым: retransmit’ы TCP спасают от сетевых глюков.

А если сеть lossy? TCP backoff замедлит, но доставит. SSH просто ждет.

Установка соединения: TCP-handshake и SSH

Все начинается с TCP three-way handshake. Клиент шлет SYN на ssh порт 22 сервера. Сервер SYN-ACK, клиент ACK — вуаля, соединение готово. Только потом SSH-версия exchange: “SSH-2.0-OpenSSH_9.3”.

RFC 4253 детализирует: после TCP key exchange (Diffie-Hellman), алгоритмы шифрования. SSH не трогает TCP-handshake — он пассивен, ждет сокета.

На сервере sshd слушает TCP/22 (ss -tlnp | grep :22). Клиент: ssh user@host — под капотом libssh или OpenSSH делает connect().

Нюанс: если firewall блочит SYN, ничего не выйдет. Или MTU mismatch — fragmentation. Но SSH добавляет keepalive (ServerAliveInterval), чтоб TCP не рвал idle-соединения.

В Windows? PowerShell New-SSHSession или OpenSSH из WS2022. Linux — стандарт. Пробовали подключаться по SSH с мобильного 4G? TCP-handshake спасает от jitter’а.

Коротко: TCP устанавливает канал, SSH его шифрует. Без TCP — нет SSH.

Сегментация данных и взаимодействие протоколов

SSH пишет данные в TCP-сокет непрерывно. TCP буферит, сегментирует по MSS (Maximum Segment Size), отправляет. Получатель собирает в поток, SSH читает.

SSH-пакеты: length (4 байта) + padding + payload + MAC. Если payload большой — несколько TCP-сегментов. TCP гарантирует in-order: sequence numbers решает.

Из Wikipedia по SSH: “SSH-сервер прослушивает TCP-порт 22”. А Bog.pp.ru: SSH-connection мультиплексирует каналы поверх туннеля.

Проблемы? Nagle’s algorithm задержит мелкие пакеты — отключите TCP_NODELAY в клиенте, если latency critical. Или congestion control (BBR в Linux) ускорит.

В туннелях (ssh -L) — еще TCP inside TCP, double nesting. Head-of-line blocking? Да, но QUIC-SSH эксперименты решают.

Реальный пример: ssh -vvv покажет, как байты летят по TCP.

Порты SSH: стандартный 22 и нюансы

SSH порт — 22/TCP по IANA. Почему 22? Исторически от BBS (Bulletin Board Systems). SSH-1 был на 22, SSH-2 унаследовал.

Можно менять в /etc/ssh/sshd_config: Port 2222. Перезапуск sshd. Клиент: ssh -p 2222 user@host.

Selectel о туннелях упоминает TCP-only. UDP? Нет, SSH не UDP-native.

Проверяем: nmap -sT -p 22 host — TCP scan. Открыто? SSH likely.

Блокировка? Многие провайдеры rate-limit 22. Решение: порт 443 (HTTPS-like) или VPN.

Статистика Yandex: “ssh порт” — 5032 запросов. Все ищут именно TCP/22.

Глубокое погружение: RFC и рекомендуемые книги

Для технарей — RFC must-read:

  • RFC 4251: SSH Architecture. Обзор слоев.
  • RFC 4253: Transport Layer. Key exchange, шифрование поверх TCP.
  • RFC 4254: Connection Protocol. Каналы, forwarding.

Книги:

  • “SSH, The Secure Shell: The Definitive Guide” от O’Reilly (ссылка) — от установки до продвинутых туннелей.
  • “SSH Mastery” 2nd Ed. (Tilted Windmill) — практика, mastery-level.
  • “Network Security Essentials” Stallings (Amazon) — контекст протоколов.

Хабр по истории порта 22 — легкое чтение. Чтение RFC? Wireshark + реальный трафик — лучший teacher.

Источники

  1. SSH — Википедия
  2. Что такое и для чего нужен протокол SSH — Selectel
  3. SSH-туннели — Selectel
  4. Как SSH появился на 22 порту — Habr
  5. RFC 4253 - SSH Transport Layer
  6. RFC 4254 - SSH Connection Protocol
  7. RFC 4251 - SSH Protocol Architecture
  8. SSH, The Secure Shell: The Definitive Guide
  9. SSH Mastery, 2nd Edition
  10. Bog BOS: SSH и OpenSSH

Заключение

SSH поверх TCP — это симбиоз: TCP дает надежность и порядок, SSH — безопасность. Пакеты инкапсулируются в сегменты, соединение через handshake на порту 22, сегментация автоматическая. Прочитайте RFC 4251-4254 для деталей, книги вроде SSH Mastery — для практики. Теперь ssh tcp не тайна: просто запустите tcpdump и поэкспериментируйте. Удачных подключений!

Авторы
НейроАгент
Автор
Проверено модерацией
НейроОтветы
Модерация
SSH поверх TCP: что значит, пакеты, соединение, порты