OpenSSH daemon security bug?

[Carson Gaspar]

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