Как просмотреть журналы journalctl по единицам и идентификаторам с помощью одной команды?
Это не работает, потому что каждая сторона канала работает в подоболочке в bash , а переменные, установленные в подоболочке, являются локальными для этой подоболочки.
Обновление:
Похоже, что легко передать переменные из родительской в дочернюю оболочку, но действительно трудно сделать это по-другому. Некоторыми обходными путями являются именованные каналы, временные файлы, запись в стандартный вывод и чтение в родительском элементе и т. Д.
Некоторые ссылки:
http://mywiki.wooledge.org/BashFAQ/024
https: // stackoverflow .com / q / 15541321/3565972
https://stackoverflow.com/a/15383353/3565972
http://forums.opensuse.org/showthread.php/458979-How-export-variable-in -subshell-back-out-to-parent
Я бы сказал, что SSH-клиент и сервер «уходят с дороги» — это очень плохой способ описать динамическую переадресацию портов,и может быть результатом повторения несколькими авторами плохо написанного или слишком -упрощенного описания, которому их, вероятно, когда-то учили.
Как описывали другие, SOCKS используется как стандартизированный способ сообщить любому совместимому прокси-серверу TCP, куда должно идти проксируемое соединение. По сути, протокол SOCKS похож на использование старого -телефона с коммутацией :«Оператор, соедините меня с телефонным номером Y города X, пожалуйста!» После того, как вы сделаете именно это, оператор (не должен )прослушивать соединение, и вы можете разговаривать с человеком на другом конце, используя любой язык, который вы хотите.
При динамической пересылке SSH клиент приложения открывает TCP-соединение с портом динамической переадресации (портом сервера SOCKS ), отправляет стандартный запрос SOCKS на подключение к определенному IP-адресу и порту, а затем может возобновить использование любого протокола, который он изначально использовал бы для этого TCP-соединения. Он должен быть в состоянии сделать первоначальный запрос SOCKS, но ему не нужно знать что-либо еще. (В конце соединения могут быть некоторые второстепенные особенности SOCKS -, но в остальном переадресованное соединение будет полностью прозрачным и протокольно -нейтральным по отношению к конечным точкам.)
Сервер приложений на другом конце видит простое старое TCP-соединение с SSH-сервером. :Ему не нужно знать, что соединение перенаправляется или что на стороне клиента задействован протокол SOCKS.
(Когда ваш телефон звонит и вы отвечаете на него, вам не нужно делать ничего особенного, даже если звонок будет исходить из музея техники с работающей ручной телефонной станцией с исходящей линией на стационарную телефонную сеть.)
Таким образом, строго говоря, клиент/сервер, когда функция динамической переадресации активирована,SSH-клиент также будет действовать как SOCKS-сервер с особым дополнительным свойством, заключающимся в том, что все соединения, использующие SOCKS-сервер, будут передаваться в пределах зашифрованного SSH-туннеля на удаленный SSH. server и с этого момента возобновите работу как обычные TCP-соединения.
Или, другими словами, комбинация клиента SSH с включенной динамической переадресацией + соединение SSH + сервер SSH будет действовать как прокси-сервер SOCKS, растянутый на расстояние, покрываемое соединением SSH, так что входящая сторона прокси-сервер SOCKS расположен совместно -с клиентом SSH, исходящая сторона находится на сервере SSH, а то, что происходит между ними, для внешних наблюдателей выглядит как незашифрованный -описательный трафик SSH.
Обратите внимание, что только прыжок между клиентом SSH и сервером SSH будет защищен SSH. Но прыжок между клиентом приложения и клиентом SSH/сервером SOCKS обычно осуществляется в пределах одного хоста. Единственная оставшаяся часть, которая может быть незашифрованной (, если только протокол приложения не включает собственное шифрование ), — это переход между сервером SSH и сервером приложений.
Протокол SSH позволяет мультиплексировать несколько независимых потоков данных через одно соединение TCP. Каждый поток данных называется каналом . Все данные, отправляемые через TCP-соединение, шифруются. Отправитель собирает данные из разных каналов в единый поток данных, который затем шифруется. Получатель расшифрует данные и снова разделит агрегированные потоки данных на отдельные каналы.
В случае переадресации портов клиент SSH подключается к удаленному серверу SSH через TCP-соединение с использованием протокола SSH . В обычном случае переадресации клиента ->сервер клиент SSH также прослушивает TCP-соединения на каком-либо порту. Соединения с этим портом будут перенаправлены через сервер на какую-либо цель.
Когда «создатель» (, также известный как «клиент приложения» ), подключается к порту прослушивания клиента SSH, клиент SSH отправляет серверу запрос на открытие канала, запрашивая «прямой -] tcpip" канал . Параметры этого запроса включают имя хоста/IP-адрес и порт, к которому должен быть подключен канал. Сервер SSH установит еще одно TCP-соединение с указанным хостом и портом, который я назову «целевым». Теперь есть три соединения TCP:
- Между отправителем и клиентом SSH
- Между клиентом SSH и сервером SSH
- Между сервером SSH и целью пересылки
Клиент и сервер SSH передают данные в обоих направлениях между отправителем и получателем через соединение SSH.
Таким образом, во время переадресации соединения от отправителя клиент SSH должен сообщить серверу SSH, куда должно быть переадресовано соединение.Если вы запустили sshс параметром строки команды -для переадресации порта, например.:
ssh -L 1234:example.com:2345...
то информация о том, куда пробросить соединение, пришла из параметра строки команды -; sshпомнит, что подключения к порту 1234 перенаправляются на порт 2345 example.com.
Если sshбыл вызван с опцией запуска сервера SOCKS, т.е.:
ssh -D 1234
Затем каждый инициатор, который подключается к порту SOCKS, должен начать с отправки сообщения протокола SOCKS с указанием хоста и порта, к которому он хочет подключиться. sshбудет использовать информацию в сообщении SOCKS для создания прямого -запроса на открытие канала tcpip.