SSH: Provide additional "pipe" fds in addition to stdin, stdout, stderr

Question

When connecting to a host with SSH, usually three "pipes" are provided between host and guest, for stdin, stdout, and stderr.

Is there a command-line option to create forwards for additional file descriptors (3 and onward)?

For example, I'd like to do

ssh --forwardfd=10:3 remotehost 'echo test >&3'

which would print 'test' to the locally-opened file descriptor 10.

Answer 1

You can do this using socket forwarding, which is available since openssh-6.7. This is some kind of pipe. This technique is described for example here: http://www.25thandclement.com/~william/projects/streamlocal.html

You will gain two-direction route for your data. There is example with mysql:

Proxy MySQL client connections on a remote server to your local instance:

ssh -R/var/run/mysql.sock:/var/run/mysql.sock \
    -R127.0.0.1:3306:/var/run/mysql.sock somehost 

Answer 2

The problem with the answer from @jakuje is: it only works with sockets, but you cannot user standard UNIX tools expecting files with them:

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

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

Also there's the problem that the local socket file is not deleted on the remote host; when next you run the same command, you get a warning and the socket is not re-created correctly. You can give the option -o StreamLocalBindUnlink=yes to ssh to unlink that old socket, but in my tests it was not enough; you also have to edit you sshd_config to contain StreamLocalBindUnlink=yes for that option to work.

But you can use socat or netcat or any other similar tool supporting UNIX local sockets (netcat-traditional is NOT enough!) to use the local socket forwarding for file transfer:

# 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'

You can also run interactive commands, in which case you should use ssh -t to allocate TTYs.

The problem with this solution is that you must hard-code the paths of the UNIX local sockets: Locally this is not that much a problem as you can include $$ in the path to make it unique per process or user a temporary directory, but on the remote-end you better do not use the world-writeable directory /tmp/ as I do in my example. The directory must also already exist when the ssh session is started. And the socket inode will remain even after the session is closed, so using something like "$HOME/.ssh.$$" will clutter your directory with dead inodes over the time.

You also could use TCP sockets bound to localhost, which will save you from cluttering your file systems with dead inodes, but even with them you still have to problem to choose a (unique) unused port number. So still not ideal. (ssh has code to dynamically allocate ports, but I found no way to retrieve that information on the remote host.)

Probably the easiest solution to copy files is to use ssh's built-in connection sharing functionality and to do a scp or sfrp command while your interactive session is still running in parallel. See Copy a file back to local system with ssh.

Answer 3

I'm sure it ought to be possible. I can only suggest a hack where you use extra ssh connections to each carry another pair of file descriptors. E.g. the following proof of concept script does a first ssh to run a dummy command (sleep) to connect up local fds 5 and 6 to remote stdin and stdout, presuming these fds are the ones you want to add to the usual 0,1,2.

Then the real ssh is done, and on the remote it connects up remote fds 5 and 6 to the stdin and stdout of the other ssh.

Just as an example, this script passes a gzipped man page through to the remote, which unzips and runs it through man. The stdin and stdout of the real ssh are still available for other things.

#!/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