How to run a local application on a distant server with SSH?

Question

I would like to know if it is possible to run a local application on a distant server using the SSH protocol?

Solution 1

To execute locally-installed applications using another computer's CPU and memory, you could — assuming that the processors are compatible — try this. I'm not sure how well it will work, but the theory seems sound :) You will probably need superuser access on the remote server for this to work.

• ssh in to the distant server

• Mount the local root filesystem somewhere. You should not do this at all unless you're quite certain that you can trust the administrators of the remote system.

  • This can be done via sshfs as long as you can ssh from the server to the local system. I think you can rig this up by forwarding a port back through the connection that you have made when sshing in from local to server, but I've not gotten in to such shenanigans myself.
    • Typically, if the local machine is on a home network, you would just set up port forwarding on your router. You should probably disable password login in your local system's sshd_config before going this route, and generate an ssh key with passphrase for your account on the server, scping the id_?sa.pub file back to local to append it to your ~/.ssh/authorized_keys. Restricting the IP addresses which can ssh in to your machine is another good idea. Et cetera.
  • If you want to run anything that needs to run as root, I think you'll need to set up the sshfs mount to be root on your local filesystem. That means you'd need to allow people to ssh in to your local box as root, which is another dubious policy move. I actually am not sure about this, you might be able to sudo within the chroot shell.
  • You could mount it other ways, for example through NFS, but sshfs is probably the easiest one to secure. Doing all of this over a VPN would probably be wiser.

• Once you've got the filesystem mounted, and are still ssh-in-ed to the server, do

  chroot /path/to/mount/of/local/filesystem COMMAND ARGS

Or you can just cd to the directory and run chroot, and then you will sort of have a root shell on your own system, with processing being done by the server. The first form has the advantage of letting you conveniently save output to the server system, since any redirections will be done onto the server. E.G.

chroot /path/to/mount/of/local/filesystem find -iname "somefile" > ~/tmp/somefile.find.out

will save the list of files named "somefile" in your home temp directory on the server.

caveats

This is, at least from my point of view, pretty experimental. I'm not sure what could go wrong, but I wouldn't try it unless a few people vouch for it. Even then I wouldn't try it on a production system. If I were doing an IT TV show, this segment would be subtitled with the words "DON'T TRY THIS AT HOME".

Definitely you'll need to have compatible processors on the two machines: if the local system is i386, the server will have to be i386 or amd64. Also, since the server's kernel is going to be doing the work, you'll only be able to run local apps which work with the version of the kernel that's running on the server. It would probably be best if they were the same version. So if both your local box and the remote server are running 32-bit Debian Squeeze, then this might work without issues.

As a further note: there may be very limited advantage to doing things this way, since any data that needs to be transferred back and forth — including both files to be processed and the applications themselves — will have to be encrypted and transferred over your remote connection. So if you are looking to do this in order to harness the superior processing power of the server, you may not gain very much in the end, and may lose some.

Solution 2

That depends a lot on how you define the terms you are using:

• 'Running an application' normally means 'letting the CPU process the instructions of a binary ("the .exe")'.

• 'Locally' normally means 'the CPU of the machine I am sitting in front of is executing the code'

• ssh is used to encrypt streams of information

So, what shall it be?

• Do you want to run your local application locally (by your CPU) but you want to interact with it from the server? Yes, that can be done via ssh, look for 'ssh tunneling'.

• Do you want your local application to be processed by CPU(s) of the server? Then you have to copy your binary / the local application onto the server and then you start it on the server. You could use ssh to do the copying. But your 'local application' is not that local any more after the copying.

You can not execute code on a CPU without making it available to the CPU before.

Solution 3

A small shell script for quick-and-dirty execution of binaries on remote systems:

#!/bin/bash

SOURCE_BIN="/some/path/binary"
DEST_HOST="name-of-system"
DEST_BIN="/another/path/binary"

cat ${SOURCE_BIN} | \
ssh ${DEST_HOST} "cat >${DEST_BIN}; chmod +x ${DEST_BIN}; ${DEST_BIN} with args; rm ${DEST_BIN}"

Comments

[Manish KUmar]

Hi, I just want to execute the code remotely without having to move the files.

[akira]

"You can not execute code on a CPU without making it available to the CPU before."

[CarlF]

"Hi, I just want to execute the code remotely without having to move the files." You want the CPU to execute code that it doesn't have the ability to load? Did you read Akira's answer?

[akira]

aka "copy the binary to the cpu that you want to execute the code".

[intuited]

@akira: along with any libraries that it uses, any configuration files that it needs, and any other apps that it execs and their libraries and configuration files. That will also require free storage space on the server, which may not be available.

[akira]

aka "copy the binary to the cpu that you want to execute the code". your "solution" does exactly that.

[akira]

sshfs is more convinient, undoubted. but you have to load the damn binary into the remote cpu, no matter what :)