On May 11, 2004, at 7:13 PM, steve wrote:
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 using
ssh.
Test. 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.
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 :-)
But seeing as the public key is a) machine specific, b) user specific, and c) of use only on the target machine, the only way you can use it is if you are on the source machine, logged on as that user, connecting to that target, or connectnig said user to another host, for which you already have privileges to modify the authorized_hosts file.
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)
How can you automate the provision of a pass phrase without writing it down when this job is to be run fron cron?
I think that you've missed the point of ssh/scp. It has nothing to do with the security of your machine, which is what all of your points are aimed at. What it does provide is an encrypted link between two hosts which cannot 'easily' be hacked ( especially as I recommended the use of a dsa pair in the bit you snipped ) by a third party, as opposed to telnet/ftp which is all cleartext, making it well suited to transmission across the internet.
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
Site security is a completly different subject.
Steve
