Shell Programming and Scripting

rdist is a good option ... we use rdist in our environment ....

Not possible. The policy is very strict and, as I said, not under our control.
I have not heard of rdist. I will look into it and probably be back with more questions.

Thanks.

pallak7:

Passphrase and password are not identical constructs under SSH Automation. Whether the policy dictates no embedding passwords into scripts or not, the passphrase is simply a means of challenging a would-be attacker with a pseudo-password. You can (and should) generate your passphrase at ssh-keygen runtime via the generator utility's prompting.

Once the passphrase is embedded into the key-pair, it's unknown and heretofore un-knowable..so long as the RSA/DSA algorithms remain un-cracked. However, it can be replaced or re-embedded later by way of the same ssh-keygen utility, but that is a convenience factor as well, should your policies require passphrases be expired similar to passwords.

My "keys to the kingdom" comment should not scare you from using this approach. It is the only means of full automation without embedding a plain-text string somewhere in the SSH/SCP/SFTP processing.

HTH

If you have these many restrictions, this looks like a job for expect, where you can easily pass all the variables you need on the command line (like usernames and passwords, or directories and files) then let expect do the tarring, compressing, and scp'ing of files for you.

@Klashxx:

After looking at rdist, it doesn't seem like this will be an option as it requires all machines to be running the rdist daemon, correct? The three servers do not run them and it's not likely that we ccould convince the administrators to do so.

Also, rdist would automatically update the servers whenever my local directory was updated, correct? I don't think we'd want that. We would only want the servers updated when we explicitly said so (i.e. OK, go deliver the code now).

@curleb:

I understand the concept behind a passphrase-less key but this cannot be a solution because of two things: 1. the policy (no passphrase-less keys) and 2. the fact that only 1 of the 3 servers even supports public-key authentication.

@System Shock:

As I said, I've tried expect with no success. It's just about as cumbersome as having to enter your password 5 times.

Anyways, it doesn't seem like I'll be able to get away from scp. That's fine. Our developers will just have to live with having to re-authenticate multiple times.