My oh my. I pity the original poster as some of the replies here are confusing several concepts into one big mess of crap.

As it appears to me the intent of the original author is to:
1. Create a web-based administration interface
2. Use this interface to cause the execution of root privileged commands on a machine other than the webserver
3. Do so in a manner that is "secure"

To accomplish this, the author is asking how to perform items 2 and 3 without the need to specify a password or any other type of manual intervention in the authentication process.

To the original author, what you are doing is reasonable, but you need to consider several things to ensure that your system can't be easily abuse to exploited:

- How to prevent an authorized user from escalating their privileges. I've seen several CGI applications that use hidden fields to key actions. These hidden fields are then passed to an action script which blindly trusts its passed parameters. There is nothing to stop an attacker from modifying the form and posting it to the action script to do bad things. A simple fix is to include some kind of secret-derived value, such as an HMAC of the form variables plus a secret key, when you post to the action script. Have the action script check this result to make sure bad things aren't taking place. Check out Digest::HMAC.

- Intermediate files create race conditions! This may not be an issue for your particular case but be wary. Particularly since you would have a root privileged process making decisions based on the contents of the file.

Now to deal with your need for remote execution. There are a couple of ways you can do this:

1. Have your script issue the remote commands directly to the remote host. This seems to be the path your are already on using SSH.
2. Run a process on the remote machine that listens on a port and processes requests as they come in.
3. Use something like Rexec or Rsh

Don't do option 3; it's security nightmare. Option 1 is fine and it seems that what you're already trying to do via SSH. If you can get the password issues worked out that's fine however you are giving a script full-blown account access. From your follow-ups it looks as if you are doing this via an RSA key without a password. That's a _lot_ of trust for the machines and processes. Security principals dictate that we minimize privileges and trust. If you choose to do it this way, limit the account's privileges with sudo or something similar. Also strongly consider using tcp_wrappers to provide additional fine-grained access control to the SSH processes.

I would suggest you also consider option 2. The password/account issues goes away. Instead, you will need to create a small daemon on the remote end that listens for requests from the web script. This daemon has a list of actions it will perform and no more. To protect this channel you can utilize a blizzard of options. Since confidentiality for this connection is not a concern utilize a scheme similar to the one I described above: a shared secret between the daemon and the CGI process that is used to key an HMAC of the request.

I just previewed my response and realized how long it's become so I'll stop now. The whole reason I can write this much is because I have both screwed-up and taken advantage of many screw-ups related to remote command execution. Just understand that because it's on an "internal" network doesn't mean you can trust that network or drop your guard.