Нет никакого различия AFAIK кроме того, что вторая версия является более портативной.
Вы можете сделать это с помощью переадресации сокетов, которая доступна начиная с 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
Я уверен, что это должно быть возможно. Я могу только предложить хакер, в котором вы используете дополнительные 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
Проблема с ответом @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 .