SSH: Предоставляет дополнительные fds-каналы в дополнение к stdin, stdout, stderr

Нет никакого различия AFAIK кроме того, что вторая версия является более портативной.

12
31.08.2015, 20:42
3 ответа

Вы можете сделать это с помощью переадресации сокетов, которая доступна начиная с openssh-6.7. Это какая-то труба. Этот метод описан, например, здесь: http://www.25thandclement.com/~william/projects/streamlocal.html

Вы получите двусторонний маршрут для ваших данных. Вот пример с mysql:

Прокси-соединение клиента MySQL на удаленном сервере с вашим локальным экземпляром:

 ssh -R / var / run / mysql.sock: /var/run/mysql.sock \ {{1} } -R127.0.0.1: 3306: /var/run/mysql.sock somehost 
 
6
27.01.2020, 19:56

Я уверен, что это должно быть возможно. Я могу только предложить хакер, в котором вы используете дополнительные ssh-соединения, чтобы каждое из них переносило другую пару файловых дескрипторов. Например. следующий сценарий, подтверждающий концепцию, выполняет первый ssh ​​для запуска фиктивной команды (сна) для подключения локальных fds 5 и 6 к удаленным stdin и stdout, предполагая, что эти fd являются теми, которые вам нужны добавить к обычным 0,1,2.

Затем настоящий ssh ​​выполняется, и на удаленном компьютере он подключает удаленные fds 5 и 6 к стандартному вводу и выходному файлу другого ssh.

В качестве примера, этот сценарий передает сжатую страницу руководства на удаленный компьютер, который распаковывает и запускает ее через man. Стандартные входы и выходные данные реального ssh по-прежнему доступны для другое.

#!/bin/bash
exec 5</usr/share/man/man1/ssh.1.gz 6>/tmp/out6 # pretend need 5 and 6

ssh remote 'echo $$ >/tmp/pid; exec sleep 99999' <&5 >&6 &
sleep 1 # hack. need /tmp/pid to be set

ssh remote '
  pid=$(</tmp/pid) 
  exec 5</proc/$pid/fd/0 6>/proc/$pid/fd/1
  echo start
  gzip -d <&5 | man /dev/stdin >&6
  echo stop
  kill -hup $pid
'
wait
less /tmp/out6
1
27.01.2020, 19:56

Проблема с ответом @jakuje заключается в том, что :он работает только с сокетами , но вы не можете использовать стандартные инструменты UNIX, ожидая файлы с ними:

ssh -R/tmp/sock.remote:/tmp/sock.local "$HOST" 'LANG=C cat >/tmp/sock.remote'

bash: /tmp/sock.remote: No such device or address

Также существует проблема, заключающаяся в том, что локальный файл сокета не удаляется на удаленном хосте; когда вы в следующий раз запустите ту же команду, вы получите предупреждение, и сокет не будет повторно -создан правильно. Вы можете указать опцию -o StreamLocalBindUnlink=yesна ssh, чтобы отключить этот старый сокет, но в моих тестах этого было недостаточно; вы также должны отредактировать sshd_config, чтобы он содержал StreamLocalBindUnlink=yes, чтобы эта опция работала.

Но вы можете использовать socatили netcatили любой другой подобный инструмент, поддерживающий локальные сокеты UNIX(netcat-traditionalНЕ достаточно! )использовать локальную переадресацию сокетов для передачи файлов:

# start local process listening on local socket, which receives the data when ssh opens the connections and saves it to a local file
nc -l -N -U /tmp/sock.local >/tmp/file.local &
# connect to remote $HOST and pipe the remote file into the remote socket end
ssh \
 -o ExitOnForwardFailure=yes \
 -o StreamLocalBindUnlink=yes \
 -R /tmp/sock.remote:/tmp/sock.local \
 "$HOST" \
 'nc -N -U /tmp/sock.remote </tmp/file.remote'

Вы также можете запускать интерактивные команды, и в этом случае вы должны использовать ssh -tдля выделения TTY.

Проблема с этим решением заключается в том, что вы должны жестко -кодировать пути к локальным сокетам UNIX. :Локально это не такая большая проблема, поскольку вы можете включить $$в путь, чтобы сделать его процесс или пользователь временный каталог, но на удаленном конце -вам лучше не использовать мир -доступный для записи каталог /tmp/, как я делаю в своем примере. Каталог также должен уже существовать при запуске сеанса ssh. А индексный дескриптор сокета останется даже после закрытия сеанса, поэтому использование чего-то вроде «$HOME/.ssh.$$» со временем загромодит ваш каталог мертвыми индексными дескрипторами.

Вы также можете использовать TCP-сокеты, привязанные к localhost, что избавит вас от загромождения вашей файловой системы мертвыми инодами, но даже с ними у вас все равно возникнут проблемы с выбором (уникального )неиспользуемого номера порта.. Так что еще не идеал.(sshсодержит код для динамического распределения портов, но я не нашел способа получить эту информацию на удаленном хосте.)

Вероятно, самым простым решением для копирования файлов является использование встроенной -в функции совместного использования соединения ssh и выполнение команды scpили sfrp, пока ваш интерактивный сеанс все еще выполняется параллельно. См. Скопируйте файл обратно в локальную систему с помощью ssh .

3
27.01.2020, 19:56

Теги

Похожие вопросы