We are on our first Linux platform and I am trying to coordinate a distributed application backup across multiple machines. I am trying to write a script in which I would have used RSH to execute scripts on the other servers. We are no longer allowed to use rsh, and someone suggested ssh. I am using that instead of telnet, but I am not sure of the syntax.

"rsh server [-n] path/executable" is what I would have used, just not sure of the syntax for ssh.

Yes I am looking at the man pages, but I can't get it to execute without prompting for a password.

Any help is appreciated.

If you had key-based authentication enabled, you might be able to do this, with or without a key passphrase. Obviously it will work without a passphrase, but many people go this route because of the difficulty of doing it with passphrase. It can be done (using ssh-agent, which has a manpage, BTW).

I hope this info is enough to see you through to your intended results.

Depending whether the admins like it: it's possible to run a second sshd on the target machine on a different port allowing login only from certain machines. Normally I advice the users to use an ssh-agent as mentioned as it's really convenient, but for some automatic processing I don't like having the agent running all the time and check this - the backup process might fail because the agent crashed for any reason. So this can be an exception to have a dedicated passphraseless ssh-key for a special "backup user" which is only for one purpose: accessing exactly this machine on a special port.

Another option could be hostbased authentication, then you don't need any ssh-keys or filled personal ~/.ssh/known_hosts file.

Good that you can't use rsh anymore. Gaping security hole. Telnet as well.

SSH is routine and easy in these situations, but be sure not to do it with root. For example, I have backup routines that have to run as root. In those situations where a remote tape drive is needed, the backup script does an su to a backup user piping the backup stream through that user and ssh to the tape drive on the remote system. So, how...

The user that the script is going to use for ssh needs to be configured for public key authentication. My favorite howto has disappeared from the web, BUT, the wayback machine comes to the rescue. You can get an explanation and details on how to do the ssh public key setup here http://web.archive.org/web/200712191...ublickey-auth/.

Following are a couple of example's of the ssh syntax embedded in an su in my backup script. They seem a bit complex, but it's easy to decompose them. In the first one all the pieces of the ufsdump command and the capture of its status code are enclosed in parenthesis to make it a subprocess (otherwise I couldn't both catch the status code and pipe the output). The output from that subprocess is then piped to the su. The su uses the -c followed by a quoted string to specify the command to be executed. That command is the ssh. The ssh then takes a quoted string at the end to indicate the command to be executed on the remote system. The quotes for that string have to be escaped since they are inside another quoted string. It looks a bit more complicated because of all the script variables used in the parameters.

I've also used ssh key access limits to restrict the use of the key so that only the machines doing backups are allowed access and only to do the specific commands needed. That is also explained in the guide I linked to above. Details can also be found in `man authorized_keys`.

Add-on to choogendyk's implementation:

What about using sudo instead of su? Inside /etc/sudoers it can also be specified, that a:will switch automatically to the backup user, when the string matches:

(replace the_user with the user who is granted access to it [it can also be a group]).

It won't need a password due to the NOPASSWD: option, but it can only be used for exactly this command and nothing else.

sudo is for providing tightly controlled privileges to a user who wouldn't otherwise have them. In this case it is an unnecessary added complication. My backup script is running as root. The issue is that root shouldn't be allowed to login to another computer. So, you su to an unprivileged user that will log in to the other computer. Root can su without a password. The unprivileged user then logs in to the other computer using ssh with public key authentication. That key is restricted on the other computer to only allow this computer for this usage.

If you don't need root (I used root because it was a backup script running fssnap and ufsdump) then you don't need the su. The unprivileged user, typically a special user for a particular application, runs the script and makes the connection to the other computer using public key authentication.

Aha - I wasn't aware that you run it from root itself, hence I thought switching to the backup user would need a password.

1. To execute some script in remote machine,u must have to give the passwd of remote machine.
In other word, you must own the right permission.

2. Else change the effective id of the executable before u access that.

Thanks to all for your replies. I am having the server team setup the appropriate ID permissions across the servers so SSH won't prompt for pwds.

Appreciate all your time and thoughts,
Kevin