---In message <x7sn2to3qp.fsf@capsicum.wsrcc.com>

I (johan) said:
>>  From my perspective, the benefit of Kerberized rdist is i use my current
>> krb5 credentials to do an rdist.  With ssh, i believe my choices would
>> involve either typing my password each rdist (or maybe even once per
>> machine, per rdist) or permanently leaving RSA/DSA keys in place on the
>> rdist targets.
>

Wolfgang Rupprecht said:
>I think both allow some unattended method for getting credentials.
>Ssh allows you to generate a private key that has no password
>protecting it.  One can then run ssh out of cron.

That's correct.  I was doing a poor job of explaining myself. Perhaps i
will express myself more clearly after being awake all night. :-)

>Kerberos allows the same thing. I used to run this out of the nightly
>cron:
>
>    export KRB5CCNAME=/tmp/krb5cc_0_$$
>    kinit -k -t /etc/krb5.keytab host/capsicum.wsrcc.com@WSRCC.COM 
>    (date; nice -20 time rdist6 -P /usr/bin/rsh -f /etc/Distfile "$@";\
>         date) 2>&1 >> /var/log/rdist.log
>    kdestroy

Obviously you know how to use stash files and Kerberos. :-) My apologies
for speaking to you as if you didn't.

Wolfgang Rupprecht said:
>The part I found uncomfortable was that in each case there was an
>unencrypted set of root credentials laying around for the taking.  If
>someone manages to copy that file, they could come in from the
>internet side as root.

Yes, this makes me uncomfortable, too, and is one of the reasons why i
only do "manual" rdists that require "manually-gotten" privileges.

 I've thought about this many times, and have not been able to come up
with a "better" solution.  Essentially, if one wants to have an
"unattended" job execute as root on remote machines, then it really seems
one must stash the equivalent of root@remote.machines authority in some
locally stashed file.

Wolfgang Rupprecht said:
>In the normal rsh/rdist case an IPF slapped on the external interface
>would protect against any rsh ever coming in from the internet.  I
>didn't have to worry about someone copying /etc/krb5.keytab or
>/root/.ssh/id_rsa .

Using an IP filter would certainly make it much more difficult for a bad
guy to use a stolen copy of the stashed credentials or password-less ssh
private key file.  But as i'm sure you know, it doesn't entirely protect
against such a problem.

 One thing to consider is that if someone has gotten at the local file
 (containing the stash credentials or password-less private ssh key) on
 the rdist master, then they probably have the equivalent of root
 privileges on your rdist master.  And they could definitely put whatever
 file they like on the rdist targets, as well as the master.  Including
 new IP filter config files, or other back doors.

 The three points i'm really trying to make are:

1) Providing automated access to root on remote machine seems unacceptably
   dangerous.

2) When running rsync or rdist manually, i cannot imagine* how one could
   avoid having to enter the password protecting the ssh key at least once
   per machine being updated, unless the password was cached.

3) If the calling script or program temporarily cached the password which
  protects the ssh key this would present the new problem of the Very
  Important Password being in memory, and if the program or script
  supplying the password to ssh (via rsync or rdist) dumped core, the
  password would probably be in the core file.  With Kerberos credentials,
  if rdist dumps core, the Very Important Password is not in the core
  file.  (Because the password is not in memory after kinit exits.)

*I have not used ssh and "manually called" rdist or rsync.


Sorry if this doesn't seem to directly answer your original "What do other
people do to automate rdist?" question. It's more of a "this is what i do,
why it's not automated, and why i prefer Kerberized rsh over ssh."

 --johan