>  > > rdist over ssh? It's not quite drop-in, but it's pretty easy to set up.
>  > > (would be nice to get some out-of-the-box support for it though sometime.)
>  > 
>  > Copying the passwd file to all hosts doesn't scale very well
>  > for even moderate numbers of users or hosts.  
> 
> Even a 10,000 user password file is well under a megabyte. Keeping
> this on each machine just doesn't strike me as a particularly large
> problem. And that's generally considered a large number of users.

The problem with the number of users isn't the size of the file, it's 
the frequency of change, and needing to keep all hosts' views of the
passwd file reasonably in sync.
 
> Updating it to a couple of hundred machines *might* saturate the
> network for a few minutes at 5 am or some other time nobody's doing
> anything critical. If you use rsync, it wouldn't take even that.

Our users wouldn't consider even an hourly update acceptable. 
It's not just password changes (though these are important) -
If we have to move a user's home directory from one server to
another, we can't afford to wait an hour until the change propagates.
And occasionally we have to disable a user's account immediately.

(and there is *no* time when nobody's doing anything critical.
our net is busier at night and early morning than in the day,
due to amanda backups and pvm jobs) 

>  > And we'd still need 
>  > something like yppasswd (with something better than "privileged 
>  > ports" for authentication) to let people change their passwords. 
> 
> % cat /usr/local/bin/passwd
> #!/bin/sh
> exec ssh centralhost "passwd $*"

There's no way in Hell we'd ever give students accounts on our master 
server, even with restricted shells that could only run passwd.

>  > > Nothing anyone does to YP will ever really be more than a bandaid.
>  > 
>  > granted.  If I had the luxury of replacing all of the "login" programs
>  > on all of the systems, I'd start with Kerberos and work up from there.  
>  > Meanwhile, a bandaid would do a lot to thwart this very common kind of
>  > attack.  
> 
> Kerberos is far from an ideal solution itself.

agreed, but it's better thought out than any solution I'm likely
to produce, given the amount of free time I'm likely to have to work on it.

Keith

p.s. we've tested the yp hack I mentioned earlier, and it appears to do
the Right Thing on every flavor of unix we have.  so we're going to install
it on our production servers and see what breaks.  one interesting side 
effect we've thought of is that it will break all of the private copies of 
xlock that people are running...but most of the sysadmins here consider 
that a feature!  (some folks use xlock to 'reserve' a public workstation 
for themselves while they go out to eat dinner... so private copies of
xlock are frowned upon.)