Don Gould wrote:Indeed - creating passwordless keys is the quick and easy way to approach the problem.I want to set up a script to move a file from one server to another usingTest. log out back to the source machine, and ssh to the target. If you're not asked for a password, then you can also scp without needing a password.
ssh.
Unfortunately, for that elusive beast, "security", this is a bad thing. Possession of the public key will allow anyone to connect to the target machine with an interactive shell. In this case, the super-encryption-powers of ssh are wasted :-)
There are a number of approaches that can be taken, individually or combined :-
You can set up a user at the far end who only has access to the file tree that you need to copy, and pop the keys in there.
Given a suitable shell (/bin/false?) you can't do too much damage to the rest of the system (caveat - will scp work over a non-shell account? I haven't tested it)
You can restrict the commands that ssh will run, and the hosts that will be able to connect, using the authorized_keys file.
You can give the key a passphrase, and use an ssh-agent to hold the key in memory after you have provided the passphrase once (yes, this will fail if the ssh-agent terminates, e.g. on reboot)
BTW, scp will always move the whole file, regardless of how much has changed. rsync will move "only the changed bits". unison will do the same, but allow you to propogate changes in both directions (which is how I maintain a shared offline directory between my various workstations and servers in different locations)
But yes, the principle is that you have to use keys for the ssh authentication to do this job ;-)
-jim
