Что такое SSH туннелирование? В чем разница между терминами: туннелирование SSH и переадресация портов? Какова точная разница между различными типами SSH-туннелирования?
Переадресация локального порта против переадресации обратного порта против динамического туннелирования
Каковы идеальные сценарии, где каждый тип может быть использован?
С точки зрения непрофессионала, Secure Shell или SSH устанавливается между двумя компьютерными программами:
Соединение между клиентом и сервером использует шифрование, поэтому фактически создается безопасный канал в незащищенной сети. Термин "Безопасная оболочка" происходит от способности сервера запускать локальную оболочку на сервере, что позволяет клиенту выполнять команды и видеть их результат. Но SSH также может быть использован для многих других целей.
И сервер, и клиент используют для связи известный протокол, что означает известный формат их сообщений. Однако SSH также может выполнять туннелирование, что означает передачу сообщений внутри сообщений или протокола внутри протокола. Сервер в этом случае действует как коммутатор или агент, передавая сообщения назад и вперед между клиентом и его целью, например, уклоняясь от локального межсетевого экрана:
Таким образом, сообщения из внутреннего протокола шифруются и инкапсулируются в протоколе SSH.
Ниже подробно описаны некоторые, но не все, способы использования SSH.
Чтобы выполнить команду в удаленной системе без входа в систему, укажите команду после информации для входа в систему:
$ ssh host command
Например, чтобы проверить удаленное дисковое пространство:
$ ssh host df
Другой пример для Linux - это подключение микрофона от одного устройства к динамикам другого:
$ dd if=/dev/dsp | ssh -C user@host dd of=/dev/dsp
Для копирования данных и файлов через SSH существует несколько вариантов.
Можно скопировать с помощью команды cat. Если вы пытаетесь скопировать вывод процесса вместо файла, это, безусловно, разумный путь:
$ cat file | ssh -e none remote-host 'cat > file'
Если это будут большие файлы, вы можете использовать флаг -C для включения сжатия.
Для копирования файлов программа scp работает как cp, за исключением того, что она также принимает удаленные места назначения:
$ scp .bash_profile matt@example.com:~/.bash_profile
Для FTP-подобного интерфейса для копирования файлов используйте программу sftp.
SSH позволяет безопасную переадресацию портов.
Например, предположим, что вы хотите подключиться от клиента A к серверу B, но безопасно перенаправить трафик через сервер C. Это полезно для обхода брандмауэров.
От А, беги:
A$ ssh C -L localport:B:remoteport
Затем, чтобы подключиться к B:remoteport, подключитесь к localhost:localport.
Если вы используете add -g, то любой, кто может связаться с A, может подключиться к B:remoteport через A:localport.
Например, предположим, что ваша работа забанена reddit.com. Запустите это:
# ssh yourserver -L 80:reddit.com:80
И установите адрес reddit.com и www.reddit.com на 127.0.0.1 в /etc /hosts (вам также необходимо отключить любой локальный веб-сервер). Теперь он будет тайно переходить на reddit.com через ваш сервер.
Если вы делаете это часто, вы можете добавить специальный хост:
Host redditfw
HostName yourserver
LocalForward 80 reddit.com:80
В качестве альтернативы, предположим, что вы хотите предоставить удаленному компьютеру B доступ к другому компьютеру A путем безопасного прохождения через локальный компьютер C.
Затем на C вы можете запустить:
C$ ssh B -R remoteport:A:targetport
На этом этапе локальные пользователи на B могут подключаться к A:targetport через localhost:remoteport.
Если вы хотите, чтобы нелокальные пользователи могли подключаться к A:targetport через localhost:remoteport, то задайте в файле sshd_config:
GatewayPorts yes
Если вы делаете это часто, настройте специальный хост в ~/.ssh/config:
Host exportme
HostName B
RemoteForward remoteport A:targetport
Используя проект FUSE с sshfs, можно смонтировать удаленную файловую систему через SSH. На Mac используйте Fuse4x.
После установки запустите:
$ sshfs remote-host: local-mount-directory
В этом контексте туннелирование SSH аналогично переадресации портов, хотя документация по SSH и параметры конфигурации обычно относятся к более поздним.
Туннелирование или переадресация порта позволяет вам инкапсулировать трафик TCP внутри соединения SSH. Это может быть использовано для
Переадресация локального порта - это когда порт LISTEN устанавливается на стороне клиента. Т.е. вы открываете локальный порт 80 на своей машине, подключенный к другому месту:80 на стороне сервера.
Обратное перенаправление портов происходит, когда порт LISTEN установлен на стороне сервера. Т.е. вы открываете удаленный порт 8080 на сервере, подключенный к your_proxy:8080
Динамический действует как SOCKS прокси.
Примеры сценариев:
Допустим, вы находитесь на компьютере A и подключаетесь к компьютеру B, поэтому A инициирует подключение к B .. Скажем, это веб, так что HTTP соединение. Там нет прокси и нет шифрования. Нет SSH, не используется команда SSH. Вы могли бы запустить это соединение через SSH, что включало бы туннелирование и переадресацию портов и, конечно, также получило бы преимущество шифрования, но туннелирование, которое, кстати, всегда использует переадресацию портов, не является самым простым использованием SSH.
У вас может быть SSH без какого-либо "туннелирования", поэтому без инкапсуляции протокола внутри него, например, скажем, вы находитесь на компьютере A и хотите получить доступ к командной строке на компьютере B. Протокол SSH может это сделать. И на самом деле я видел ssh -X, позволяющий просматривать графический интерфейс на компьютере B, где компьютер B работал под управлением Linux. Так что SSH может делать совсем немного, даже без туннелирования. И вы получаете шифрование SSH всякий раз, когда используете SSH.
Что вы также можете сделать, скажем, вы хотите просматривать веб-страницы из интернет-кафе. Вы можете установить SSH-соединение с компьютера A на компьютер B, установив соединение, которое является SSH-туннелем, оно будет инкапсулировать другой протокол, например запросы к HTTP-прокси, а на компьютере B будет работать веб-прокси, извлекать веб-страницу и отправить ее на компьютер А. Все, что видит человек в интернет-кафе, это зашифрованное ssh-соединение между A и B. Динамическая переадресация порта создаст прокси-сервер SOCKS на B, а прокси-сервер SOCKS может выступать в качестве веб-прокси.
Вы можете использовать VNC для перехода от A к B, но сделать это через соединение SSH ... так что это туннелирование / инкапсуляция соединения VNC через соединение SSH.
В SSH существует концепция переадресации локальных портов и переадресации удаленных портов (обратный туннель). То, какая сторона слушает, а какая вперед. Местный типичный. Например. Ситуация с ssh-туннелированием включает в себя следующие элементы: ssh.exe (инициирует ssh-соединение, это ssh-клиент). sshd.exe (ssh-сервер прослушивает ssh.exe для подключения к нему). И клиент и сервер инкапсулированного протокола. например, клиент VNC и сервер VNC. И у вас есть компьютеры, на которых работает каждый из них.
Скажите, что ваши компьютеры A, B, C, D
A-запускает VNC-клиент B, запускает SSH-клиент C, запускает SSH-сервер D, запускает VNC-сервер
B соединяется с C.
A соединяется с B, затем C передает его на D.
Все между B и C зашифровано.
Все, что находится между A и B или C и D, не зашифровано.
Туннель SSH находится между B и C.
Между A и B и между C и D находится инкапсулированный протокол - в данном случае VNC.
Теперь я пойду к тому, что такое обратный туннель, и это полезно ..
Предположим, что A находится за маршрутизатором NAT, а B - за маршрутизатором NAT. Если A хочет подключиться к VNC на B, то B должен выполнить переадресацию портов на своем маршрутизаторе. (это даже без SSH). Другой способ, хотя, был бы, если бы B мог инициировать соединение с A, позволяя A просматривать B. Таким образом, вы отправляете техническому специалисту joe bloggs исполняемый файл, а затем запускаете его и просматриваете их компьютер. PChelpWare делает это, позволяя вам создать такой исполняемый файл. Но процесс B может соединиться с вами, может быть выполнен с помощью SSH.
Например, в сценарии локального туннеля ssh у вас может быть CompA, запускается VNC-клиент и SSH-клиент CompB, запускается VNC-сервер и SSH-сервер.
Таким образом, туннель и соединение VNC идут в одном направлении.
A подключает свой SSH-клиент (ssh.exe) к SSH-серверу B (sshd.exe). (требует, чтобы B сделал переадресацию портов на своем маршрутизаторе). ssh.exe на A затем создает порт на A - комп, на котором он работает, который прослушивает соединение VNC. Это слушающая сторона туннеля. А также, когда был построен туннель, было определено, что B должен пересылать на любой IP:PORT, B в этом случае. Вот где находится сервер VNC.
CompA/PersonA, соединяет VNC-клиент с портом, который ssh.exe открыл на A. И затем он будет перенаправлен на B.
Но вот проблема с этим, с локальным туннелем ssh. Предположим, Б не знает, как сделать переадресацию портов на своем маршрутизаторе.
Тогда A не может подключить свой SSH.EXE, свой ssh-клиент, к B SSHD.EXE, ssh-серверу B.
Ну, они могли бы сделать обратный туннель SSH
A запускает SSH SERVER, а клиент VNC B запускает SSH CLIENT и VNC Server.
B подключается к A .. командой, которая инструктирует создание обратного туннеля. Таким образом, прослушивание не локально по отношению к тому, где был запущен SSH.EXE (то есть B), но порт прослушивания открыт на A, даже если B запускает ssh.exe, поэтому B подключается к A и устанавливает SSH-соединение. А теперь слушает инкапсулированный протокол.
Затем A подключает своего клиента VNC к порту, который открыт на A, и просматривает B.
B не должен был делать переадресацию портов на своем маршрутизаторе. Поскольку все, что B должен был сделать, было установить соединение .. Не было входящего соединения с Б. Это то, что может сделать туннель SSH.
(обратите внимание, что в настоящее время, когда A хочет просмотреть B, они обычно используют решение, такое как teamviewer, которое, вероятно, включает как установление исходящего соединения)
Но в любом случае это использование обратного туннеля SSH.
Так что использовать ли локальный туннель SSH или обратный, зависит от того, какая сторона блокирует входящие. или какая сторона находится позади устройства, блокирующего вход, которым вы не можете управлять. например, маршрутизатор NAT или межсетевой экран, который вы не можете контролировать.
Динамический туннель, где A подключается к B через SSH, а прокси SOCKS создается в B. Прокси SOCKS подобен универсальному прокси, который может имитировать группу прокси различного типа. Так что он может выступать в качестве веб-прокси. Так что, если вы были в интернет-кафе .. Вы можете использовать динамический туннель. Подключитесь к CompB, и это все, что видит человек, управляющий интернет-кафе. Дело в том, что веб-прокси не перенаправляет на один компьютер, в противном случае вы получите только один веб-сайт. Он пересылается на любой веб-сервер, который вы запрашиваете, позволяя вам просматривать веб-страницы.
Чтобы выполнить SSH с переадресацией локального порта, то есть для локального туннеля ssh выполните SSH -L PORT:IP:PORT user@sshserver -p 22 где PORT:IP:PORT первый "порт" - это порт, который будет выполнять ssh.exe. создать локально для вашего клиента VNC, например, для подключения. и IP:PORT - это IP:PORT, например, VNC-сервера. тогда у вас есть sshserver -p 22 sshserver - это IP-адрес сервера ssh, к которому вы подключаетесь, а -p 22 означает подключение к нему через порт 22. Вы можете вместо PORT:IP:PORT, скажем, IP:PORT:IP:PORT, где первый IP-адрес 0.0.0.0 или *, означает, что любой компьютер может подключиться.
SSH, но с обратным туннелем ssh, переадресация портов локально. Таким образом, вы делаете SSH -R PORT:IP:PORT, где первый PORT - это порт на конце sshd.exe, который прослушивает. И IP:PORT - это IP:PORT, например, VNC-сервера, но это CompA, то есть комп, на котором запущен ssh.exe. И это также SSH -R PORT:IP:PORT user@sshserver -p 22
Динамический SSH будет иметь вид ssh -D 8080 <username>@192.168.1.1
Есть случай, когда кто-то делает обратную версию ... обратный SSH -D. https://stackoverflow.com/questions/842021/ssh-d-port-usernameserver-com-but-in-reverse Он запустил SSH-сервер и хотел, чтобы его друг имел доступ к своему SSH-прокси. Так что его друг запускал ssh -D username@server.com Но он не хотел, чтобы у его друга тоже была консоль SSH. Нет сомнений, что есть лучший способ предотвратить это, но то, что он сделал .. или попросил сделать ... Был ли Он устанавливает соединение SSH со своим другом, но затем пусть его друг получает доступ к своему прокси-серверу SSH SOCKS. Таким образом, у его друга есть прокси для доступа к его SOCKS прокси! Таким образом, он (человек А-человек, настраивающий свой компьютер, чтобы его друг мог получить доступ к своему прокси-серверу (А)), ssh -R 24680:localhost:12345 remotehost А затем выполните команду ssh -D 12345 localhost Это ssh -R означает первый указанный порт (24680) откроется на CompB. И все, что получено на этом (где B подключает свой веб-браузер), будет отправлено на A и перенаправлено на порт 12345, где A запускает свой SOCKS-прокси. И самое забавное в том, как настроен прокси-сервер SOCKS, как прокси-серверы SOCKS с SSH, так как для этого требуется собственное ssh-соединение. Это не туннелирование SSH через SSH .. Запросы SOCKS транслируются через SSH. Но соединение ssh, которое делает прокси-сервер SOCKS, является отдельным соединением, которое поступает от А, подключающегося к его собственному серверу ssh через порт 22. (в дополнение к соединению SSH, которое А подключается к В). Последний пример, обратный ssh -D - очень сложное использование SSH! Другие применения (локальное, обратное и нормальное -D) все еще сложны, но не так сложны, как пример обратного -D. Я просто добавил это для большей полноты.