OpenSSH daemon security bug?

[Carson Gaspar]

Jamie Beverly wrote:

>> This could easily be handled via a PAM module; one that tracks
>> user's public keys, and forces them to change every N
>> (configurable) days... with similar rules to password management,
>> i.e. no repeats within N days, cannot change for N days, etc,etc...
>> 
>> 
>> I suspect it would have to sit in the session stack so that it
>> would still be hit in the pam_open_session phase of login via
>> public-key authentication...
>> 
>> If there is interest, I'd be happy to write it.
>> 
> 
> 
> Actually thinking more about it, this might make more sense as an
> sshd configuration item. Especially since it would mingle very nicely
> with Match rules.
> 
> I'm thinking something like, when a user logs in who is required to
> pass key-aging rules, sshd would check the mtime of the configured
> authorized_keys file as preliminary check, and if the file itself is
> recent enough, it would then then iterates the users public keys. If
> they key has already been recorded in an expiration cache, it would
> compare the current-time against the recorded-time; if they key has
> not already been recorded, the key would get recorded with a
> timestamp (the mtime of the file? current time? something...). Any
> public key known to not match the configured aging rules would simply
> get ignored. Additionally, a host-wide black-listing facility would
> be good.
> 
> There would be corner cases that this wouldn't catch, e.g. a user who
> had never logged in before, but had a recently touched
> authorized_keys file containing old keys; but in the general case, it
> might be worthwhile to have...
> 
> Thoughts? Additions? Alternate approaches?


See the mail I just sent to the list. Leaving authorized_keys in a 
user's home directory is a really bad idea if you want to actually 
enforce policy.

-- 
Carson Gaspar