"Password validation services" -- how can we avoid creating more of them?

Fri Dec 29 10:46:06 PST 2006

> > have them; but password authentication helps to cover those
> > authentication corner cases that crop up every so often (a staff
> > member is on a trip, their laptop dies, they find an internet kiosk at
> > the public library...)
> 
> Hmmm... it seems that I failed to communicate my concern.
> 
> At least for OpenSSH, I do not know of a way to (only) permit public
> key authentication for some users, while allowing password
> authentication for others.  If this assertion is correct, allowing *any*
> password authentication for a given machine exposes *every* user with an
> account on that machine to precisely the type of password-acquisition
> abuse that I'm trying to avoid.

Well, OpenSSH doesn't, but there's always the trivial OS workaround:
1) outside SSH is via designated access hosts, i.e. bastions.
2) by default, shadow entry for each user is locked (set to * or *LK*,etc).
3) SA sets up initial key access for each user (can be automated, of course)
4) when temporary password access is needed, set a password, and (depending on
account options), set account to expire the day after said user gets back from
trip.

It's a bit manual, but usually there aren't that many folks who actually need
to keep access, and can do so if their own laptop is missing (SA's better be
able to, but most developers and the like seem dependent on other tools so
end up just having to take some time away from work).  Biggest PITA is
setting up all those user keys in the first place.  Even using CFEngine to
propagate to all the bastions doesn't usually save me from helping most
users get it right in the first place, which effectively means personally doing
it for each user.