Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question
up vote 1 down vote accepted

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_? 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.


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.

share|improve this answer
aka "copy the binary to the cpu that you want to execute the code". – akira Mar 1 '11 at 6:55
@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. – intuited Mar 1 '11 at 14:49
aka "copy the binary to the cpu that you want to execute the code". your "solution" does exactly that. – akira Mar 1 '11 at 19:54
Well, I suppose that if the entire executable is being loaded into memory, and you consider the definition of "copying" to include loading something into memory, you could say — if you wanted to be particular about it — that it does "copy the binary" . . . along with the other stuff I mentioned in my last comment, which could make use of sshfs considerably more convenient for binaries with complex dependencies. – intuited Mar 1 '11 at 20:35
sshfs is more convinient, undoubted. but you have to load the damn binary into the remote cpu, no matter what :) – akira Mar 2 '11 at 11:32

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.

share|improve this answer
Hi, I just want to execute the code remotely without having to move the files. – mnml Feb 3 '11 at 15:49
"You can not execute code on a CPU without making it available to the CPU before." – akira Feb 3 '11 at 15:54
"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? – CarlF Feb 28 '11 at 20:11

You can from one machine(machine A) request that another machine(machine B) run a program already on machine B. ssh would let you do that.

And I think you can from machine A access say an installation file from machine B, and run it on machine A, which would transfer the file into machine A's RAM. I think windows file sharing does that. (that doesn't move or copy the file by the way, no file disappears or appears anywhere in doing that. Better terminology might be that the file is copied into RAM and becomes a process, this happens any time a program is run even when local)

In theory I suppose a very cool CPU and instructions could read from RAM on another computer. You'd want over a network too. Maybe the technology is literally out there but I wouldn't know where/what.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .