Что значит ssh работает поверх tcp?

Question

[Tipch]

При углублении в принципы работы ssh столкнулся с формулировкой "SSH обычно работает поверх TCP, так что обычно после того, как налажено соединение TCP". Но при попытке понять значит ли это что пакет ssh инкапсулируется в tcp-пакет везде встречаюсь именно с этой формулировкой - SSH работает поверх TCP. Что это значит? Что почитать чтобы прояснить этот вопрос?

Comments

[Everything_is_bad]

что говорит гугл?

[Tipch]

Да, вы правы.
Спасибо!
Нужно было по другому сформулировать вопрос.
Да, пакет SSH инкапсулируется в TCP-пакет, потому что SSH — это протокол прикладного уровня, который работает поверх надежного соединения протокола TCP (Transmission Control Protocol) для обеспечения безопасной передачи данных. SSH-клиент отправляет данные, которые сначала помещаются в SSH-пакет, затем этот SSH-пакет инкапсулируется в TCP-сегмент, а уже TCP-сегмент инкапсулируется в IP-пакет и отправляется по сети через порт 22 (по умолчанию).

[Сергей Сахаров]

Стек протоколов TCP/IP состоит из соединений TCP, UDP, GRE, ICMP и многих других.
Но только TCP и UDP позволяют использовать для соединений понятие порта.

Соответственно поверх TCP и UDP работают многие службы.
Если заглянуть в /etc/services то внезапно выяснится, что на следующих портах висят такие службы:
TCP/20 TCP/21 - ftpd
TCP/22 - sshd
TCP/25 - SMTP
UDP/53 - DNS
TCP/80 - HTTP
TCP/110 - pop3d
TCP/137 TCP/138 TCP/139 - NETBIOS
TCP/143 - IMAP
TCP/389 - LDAP

Сессия определяется парой: входящие / исходящие адрес и порт
Посмотреть текущие сессии можно командой
netstat -a


Пример открытых портов на моей файлопомойке.

Управлять доступом к портам можно с помощью межсетевого экрана - он же файрволл, он же брандмауэр

[Дмитрий]

просто запусти какой-нибудь WireShark и сам посмотри как всё происходит.

Answer 1

[Кот Абсолютный]

Но при попытке понять значит ли это что пакет ssh инкапсулируется в tcp-пакет

Разумеется значит. А пакет TCP инкапсулируется в пакет IP. А пакет IP инкапсулируется в пакет Ethernet (или другой среды передачи) И уже этот пакет передается по сети.

Все в полном соответствии с моделью ISO/OSI. В случае ssh даже ISO6 задействуется, который обычно пропускают.

Answer 2

[rPman]

Так как я сам пользуюсь такой формулировкой, поясню что именно я вкладываю в нее.

ssh позволяет внутри открытого соединения (оно одно на сессию и двунаправленное, если это важно), поднимать несколько каналов обмена информации, например собственно терминал (т.е. stdin/stdout удаленной сессии), перенаправления портов (ключи -R или -L), socks прокси (ключ -Dip:port ) и даже полноценный vpn туннель (ключ -w 0:0 ) причем как point-to-point так и ethernet (т.е. симуляция физического интерфейса) - tun и tap в терминологии linux, и все это одновременно.

Но все это великолепие будет упаковано в одно единственное соединение tcp. А у tcp есть одно достоинство/недостаток/фича - оно гарантирует порядок доставки отправленных пакетов, т.е. пока N-ый пакет не дойдет до адресата, N+1-ый пакет будет ждать и не дойдет до приложения, хотя физически он в принципе может уже быть на удаленной машине. Т.е. если у вас открыто (инкапсулировано) несколько соединений внутри одной ssh сессии, и у вашего провайдера (или точнее у провайдера на пути до ssh сервера) возникнет проблема/потеря пакета, то все ваши инкапсулированные соединения приостановятся и будут ждать, даже если задержанный пакет принадлежал конкретному соединению, ждать будут все.

Т.е. поднимать vpn с помощью ssh может быть удобно и просто, но отзывчивость результата будет не на высоте, особенно если у вас не очень качественная связь.

p.s. гуглятся форки ssh, поддерживающие udp (который не гарантирует порядок и в принципе доставку пакетов), но на сколько они 'правильно' реализованы я хз.