S SH туннелирование, S SH консольные сессии и SFTP-сессии - функционально не связанные вещи. Они могут использоваться одновременно в течение одного сеанса, но обычно это не так, поэтому не пытайтесь найти какое-либо отношение или роль туннелирования в сеансе ssh / sftp.
Нет смысла смешивать s sh туннелирование с несколькими сессиями ssh / sftp. В основном вы бы использовали выделенный сеанс s sh для туннелирования и дополнительные сеансы для консоли и передач.
Что за чертовое туннелирование S SH?
Довольно часто обе стороны (вы и сервер) находятся в разных сетях, где произвольные сетевые соединения между такими сетями невозможны.
Например, сервер может видеть на своей сети рабочие станции и узлы обслуживания, которые не видны внешней сети из-за NAT .
То же самое относится и к пользователю, который инициирует подключение к удаленному серверу: так что вы (клиент s sh) можете видеть ваши локальные ресурсы (узлы хранилища и узлы сервера), но не можете видеть узлы на сеть удаленного сервера.
А вот и s sh Туннелирование .
S SH Туннель НЕ является инструментом для помощи с sh такие вещи, как сеансы удаленной консоли sh и безопасная передача файлов , но с другой стороны - это протокол sh, который помогает вам строить транспорт в туннель el generi c TCP-соединения работают так же, как TCP-прокси. Когда такой канал построен и работает, он не знает, что передается через такой канал / туннель.
Его концепция похожа на TCP-прокси.
TCP-прокси работает на одном узле, поэтому служит акцептором соединений и инициатором исходящих соединений.
В случае туннелирования S SH такое понятие TCP-прокси разделяется на две половины - один из узлов (участвующих в сеансе s sh) выполняет роль прослушивателя (приемщика подключений), а второй узел выполняет роль прокси-сервера (т. е. инициирует исходящие подключения).
Когда вы устанавливаете sh сеанс S SH на удаленном сервере, вы можете настроить два типа туннелей, которые активны, пока ваше соединение s sh активно. Несколько клиентов s sh используют записи типа
- R [IP1:] ПОРТ1: IP2: ПОРТ2
- L [IP1:] ПОРТ1: IP2: ПОРТ2
Самая запутанная / сложная часть для понимания этой туннельной системы s sh - это L и R маркеры / переключатели (или что-то еще).
Эти буквы L и R могут сильно запутать новичков, потому что на самом деле в этой игре 6 (!!!) сторон (каждая со своей точкой зрения на то, что локально, а что удаленно):
- вы
- s sh сервер
- ваших соседей, которые хотят предоставить свои порты любому, кто видит сервер
- ваших соседей, которые хотят подключиться к любому сервисному серверу видит
- любого, кто видит сервер и хочет подключиться к любой услуге, которую ваш сосед предоставляет (противоположная сторона / сокет случая № 3)
- любой сервис в локальной сети сервера, который хочет быть подвергается воздействию вашей локальной сети (противоположная сторона / розетка корпуса № 4)
в терминах s sh клиентские эти типы туннелей: :
- "R" туннель (сервер прослушивает) - ВЫ предоставляете сетевые сервисы из вашей ЛОКАЛЬНОЙ ЛВС в удаленную ЛВС (вы указываете Сервер sshd для запуска прослушивающих портов на удаленной стороне и маршрутизации всех входящих соединений)
- Туннель "L" (вы слушаете) - Сервер выставляет ресурсы своей ДИСТАНЦИОННОЙ ЛВС в вашу ЛВС (ваш s * Клиент 1167 * запускает прослушивание портов на вашей рабочей станции. ваши соседи могут получить доступ к сетевым службам удаленного сервера, подключившись к портам вашей рабочей станции. сервер устанавливает исходящие соединения с локальными службами от имени вашего клиента * sh)
Таким образом, туннелирование S SH подразумевает предоставление доступа к службе, которая обычно недоступна из-за сетевых ограничений.
А вот простое интуитивно понятное правило, которое нужно запомнить при создании туннелей:
- , чтобы открыть доступ к R службе эмоций, которую вы используете -L switch
и
- , чтобы открыть доступ к L ocal сервису, который вы используете -R switch
примеры туннелей "R":
Джек - ваш коллега (бэкэнд-разработчик), и он разрабатывает код на стороне сервера на своей рабочей станции с IP-адресом 10.12. 13,14. Вы руководитель команды (или системный администратор), который организует условия труда. Вы сидите в одном офисе с Джеком и хотите открыть его веб-сервер для внешнего мира через удаленный сервер. Таким образом, вы подключаетесь к серверу s sh с помощью следующей команды:
ssh me@server1 -g -R 80:ip-address-of-jack-workstation:80
. В этом случае любой пользователь Inte rnet может получить доступ к текущей версии сайта Джека, посетив http://server1/.
Предположим, что в мире существует множество устройств IoT Linux (например, Raspberry Pi), которые находятся в нескольких домашних сетях и поэтому недоступны извне. Они могут подключиться к домашнему серверу и предоставить свой собственный порт 22 серверу, чтобы администратор мог подключиться ко всем этим серверам. Таким образом, устройства RPi могут подключаться к серверу следующим образом: устройство RPi # 1
ssh rpi1@server -R 10122:localhost:22
устройство RPi # 2
ssh rpi1@server -R 10222:localhost:22
устройство RPi # 3
ssh rpi1@server -R 10322:localhost:22
и системный администратор, находясь на сервере, может подключиться к любому из них:
ssh localhost -p 10122 # to connecto first device
ssh localhost -p 10222 # to connecto second device
ssh localhost -p 10322 # to connecto third device
администратор удаленных помещений заблокировал sh исходящие соединения, и вы хотите, чтобы рабочий сервер связывался с битбакетом через ваше соединение ...
#TODO: add example
Типичные ошибки в туннелировании s sh:
отображение удаленного сервиса на локальный привилегированный порт
ssh me@server -L 123:hidden-smtp-server:25 # fails
#bind fails due to priviledged ports
#we try to use sudo ssh to allow ssh client to bind to local port switches
sudo ssh me@server -L 123:hidden-smtp-server:25 # fails
#this usually results to rejected public keys because ssh looks for the key in /root/.ssh/id_rsa
#so you need to coerce ssh to use your key while running under root account
sudo ssh me@server -i /home/me/.ssh/id_rsa -L 123:hidden-smtp-server:25
предоставление какой-либо услуги из локальной сети кому-либо через сервер publi c:
типичная команда будет
ssh me@server -R 8888:my-home-server:80
#quite often noone can't connect to server:8888 because sshd binds to localhost.
#To make in work you need to edit /etc/ssh/sshd_config file to enable GatewayPorts (the line in file needs to be GatewayPorts yes).
мой туннель прекрасно работает на мой компьютер только для меня, но я бы хотел, чтобы мои коллеги также получили доступ к моему туннелю
типичная рабочая команда, с которой вы начинаете, будет
ssh me@server -L 1234:hidden-smtp-server:25
#by default ssh binds to loopback(127.0.0.1) and that is the reason why noone can use such tunnel.
#you need to use switch -g and probably manually specify bind interface:
ssh me@server -g -L 0.0.0.0:1234:hidden-smtp-server:25