Scripting ssh

Brent,
the following link may help you:
http://www.csua.berkeley.edu/~ranga/notes/ssh_nopass.html
Then, you can run the command(s) you want using "cron".
Also, you can use "cron" on the remote machine to do what you want and avoid using ssh (and therefore scripting).

Mihalis.

Alternative link to AFP548 article on SSH without passwords...

http://www.afp548.com/article.php?story=20040816224717742

Note that if you need to run the remote command as root (sudo) then you will need to ssh as root (ssh root@machine.local) since the command will otherwise still ask for an admin password, even if the user you ssh as (ssh user@) is a local admin.

In order to ssh as root, the root user needs to be enabled on the remote machine, which may not be the case. You can do this using the command line with "sudo passwd root", and enter the 'new' password when requested. This both sets the root user password and enables the root user as a consequence.

Once the ssh keys are set up, you can issue the kickstart command as an argument to the ssh command...

ssh root@machine.local /System/Library/etc.etc/kickstart -restart -agent

Put same into a crontab if done at specific times. Or alternatively put into remote machines crontab as previous post - avoids ssh keys if just requires running at specific times.

-david

Hi Brent,
I don't think it's a good idea to use public key authentication to the root account for arbitrary commands. That means that if one machine is compromised, so is the other. I run specific commands remotely as root using Forced Commands.

That link is to chapter 8 of O'Reilly's SSH, The Secure Shell, The Definitive Guide. I recommend the reading of the entire chapter as it discusses public key authentication in general. Forced commands are a special case of public key authentication. A specific command is included with the key and when that key is used in authentication, the command is run automatically and secure shell exits as soon as the command is finished. Because the command that is run is specified beforehand, even if the private key is compromised, the intruder can only use it to run that one command.

When I create the public/private key pair, I rename the private key file with a name that reflects the command that will be executed: in my case, bunzip_dsa. I put this in my ~/.ssh directory, although the location isn't important. I use it in the following way:

echo "${TARNAME}" | ssh -i ~/.ssh/bunzip_dsa <server_name>

The pipe isn't necessary in your case but I use it as an example of the flexibility of this technique. My forced command is a shell script and I use the "read" command to read the contents of the pipe. That allows my command to be extremely flexible while still being secure.
--
Gary
~~~~
It's not whether you win or lose, it's how you place the
blame.