Mfcttrf

I have a program on a remote host, whose execution I need to automate. The command execute that program, on the same machine, looks something like this:

/path/to/program -a file1.txt -b file2.txt

In this case, file1.txt and file2.txt are used for entirely different things within the program, so I can't just cat them together. However, in my case, the file1.txt and file2.txt that I want to pass into the program exist only on my device, not on the host where I need to execute the program. I know that I can feed at least one file through SSH by passing it through stdin:

cat file1.txt | ssh host.name /path/to/program -a /dev/stdin -b file2.txt

but, since I'm not allowed to store files on the host, I need a way to get the file2.txt over there as well. I'm thinking it might be possible through abuse of environment variables and creative use of cat and sed together, but I don't know the tools well enough to understand how I would use them to accomplish this. Is it doable, and how?

If the files given as arguments to your program are text files, and you're able to control their content (you know a line which doesn't occur inside them), you can use multiple here-documents:

 echo "cat /dev/fd/3 3<<'EOT' /dev/fd/4 4<<'EOT' /dev/fd/5 5<<'EOT'"
 cat file1
 echo EOT
 cat file2
 echo EOT
 cat file3
 echo EOT
 | ssh user@host sh

Here cat is a sample command which takes filenames as arguments. It could be instead:

echo "/path/to/prog -a /dev/fd/3 3<<'EOT' -b /dev/fd/4 4<<'EOT'

Replace each EOT with something that doesn't occur in each of the files, respectively.

If you can set a TCP listener (can be a higher port), then you could use a second SSH session to establish the second input source with nc.

Example:

There's this script on the server (~/script.bash):

#!/usr/bin/env bash
cat "$1" | tr a 1
nc localhost "$2" | tr '[:lower:]' '[:upper:]'

And there are these two files locally:

$ cat a 
aaa
aaa
aaa
$ cat b
bbb
bbb
bbb

Now first start the second source ($serv is the server):

ssh "$serv" nc -l -p 2222 -q1 <b &

And run the command proper:

$ ssh "$serv" ./script.bash - 2222 <a
111
111
111
BBB
BBB
BBB
[1]+ Done ssh "$serv" nc -l -p 2222 -q1 < b

Unfortunately there's not a great way to do this directly, since the ssh client will only pass the three file descriptors (stdin, stdout and stderr) to the server and it doesn't have provisions to pass additional file descriptors (which would be helpful for this particular use case.)

(Also note that the SSH protocol has provisions to pass additional file descriptors, only the ssh client doesn't implement a way to use that feature. Theoretically, extending the client with a patch would be enough to expose this feature.)

One hacky way to accomplish what you're looking for is to use file descriptor 2 (the stderr file descriptor) to pass the second file. Something like:

$ ssh remote.name 
 /path/to/program -a /dev/stdin -b /dev/stderr 
 <file1.txt 2<file2.txt

This should work, it just might cause an issue if program tries to write to stderr. You can work around that by re-juggling the file descriptors on the remote end before you run program. You can move file2.txt to file descriptor 3 and re-open stderr to mirror stdout:

$ ssh remote.name 
 /path/to/program -a /dev/stdin -b /dev/fd/3 
 '3<&2' '2>&1' 
 <file1.txt 2<file2.txt

If you're allowed to forward ports over ssh, and you have access to wget on the remote machine and to busybox on the local machine, you can do something like:

mkdir /tmp/test; cd /tmp/test
echo 1st_file > 1st_file
echo 2nd_file > 2nd_file

busybox httpd -f -p 127.0.0.1:11080 &
ssh USER@HOST -R 10080:127.0.0.1:11080 '
 cat <(wget -q -O- http://localhost:10080/1st_file) 
 <(wget -q -O- http://localhost:10080/2nd_file)
'
kill $!

(using cat as an example program which takes two file arguments).

Only the ability to forward ports via -R is essential -- instead of doing http, you can use other methods (2 netcats and 2 forwardings, /dev/tcp/ in bash on the remote side, etc). But convincing a netcat without the -N option to close the connection proved to be much messier than I though.

There may be ways to replace the <(...) process subtitutions if the shell on the remote machine isn't ksh- or bash- like.

All in all, this isn't too great -- better knowledge about the exact system/shells/config/permissions (which you haven't provided) could allow for smarter solutions.

Perhaps not exactly what you want... But maybe consider sending a tarball through the pipe opened by ssh?

You said that:

I'm not allowed to store files on the host.

It's possible that you don't have a writable home directory or other convenient location to store files long term, but I'd say it's unlikely you don't have any writable location, even if a temporary tmpfs that will be made available only for your particular connection.

Many programs (and even libc routines) require a writable /tmp, so it's very likely one will be available to you.

Then you could use a script that will unpack the tarball into a temporary directory, run your program and cleanup through the ssh connection.

Something like:

$ tar cf - file1.txt file2.txt |
 ssh host.name '
 set -e
 tmpdir=$(mktemp -d -t tmp.XXXXXXXXXX)
 cleanup () rm -rf "$tmpdir"; 
 trap cleanup EXIT
 cd "$tmpdir"
 tar xf -
 /path/to/program -a file1.txt -b file2.txt
 '

This might need some extra care with file paths and there are some corner cases to consider (test for them), but the general approach should work.

If no writable directory is available, a possible approach would be to modify program to take a tarball as single input and unpack its contents to memory. For instance, if program is a Python script, then using the built-in tarfile module would easily accomplish something like that.