OpenSSH daemon security bug?

[Jamie Beverly]

----- Original Message ----

> From: Carson Gaspar <carson at taltos.org>
> To: "<openssh-unix-dev at mindrot.org>" <openssh-unix-dev at mindrot.org>
> Sent: Tue, January 5, 2010 5:19:37 PM
> Subject: Re: OpenSSH daemon security bug?
> 
> Michael Stone wrote:
> 
> > Private keys are seldom expired on a routine basis, so there may be
> > forgotten copies lying about that haven't been used in years. (Should
> > people do this? No.  Does it happen? Yes. Can you prove none of your
> > users have done it?  Probably not.) Even with a strong password,
> > there's a big difference between a passive offline attack against a
> > key and an active brute force of a login password.
> 
> You _can_ enforce private key expiry, if you wish, but it requires some extra 
> code. One possible implementation:
> 
> - Use an authorized_keys path outside the user's control (sshd already allows 
> this)
> 
> - Provide a method for users to add a new public key (via HTTP, command line 
> with setuid / sudo, ...). Said method needs to record the date the key was added 
> (in a comment or in a sidecar DB). It should also remember past keys (easy to 
> implement via commented out old keys or in a sidecar DB)
> 
> - Create a pam_session module to warn users of approaching key expiry on login 
> (or add something to the standard shell profiles, but PAM is more robust if 
> you're using it already).
> 
> - Expire the keys via a daemon / scheduled job, optionally changing a 
> sufficiently recently expired key to have a forced command that allows a user to 
> update their key, and nothing else.
> 
> - (Optional) synchronize authorized keys across a set of servers in the same 
> security domain for ease of use of users (as their home dir no longer provides a 
> de facto synchronization method)
> 
> Then you have the mechanism to implement a policy (key length / type, max age, 
> etc.)
> 
> -- Carson Gaspar

That
is almost precisely how I've always done it whenever I was concerned
about users following key policies, minus the pam_session module (I was
a bit lazier than that, and just used an /etc/profile.d script, as you
noted as an alternative)

I proposed a possible feature request
in another message within this thread to add some level of daemon-level
configuration and enforcing of aging policy; but I've not entirely
convinced myself its really necessary given how easily it can be done
outside of openssh... (my perl script for expiring users' keys is I think 68 lines ish... )