OpenSSH daemon security bug?

[Jamie Beverly]

> ----- Original Message ----

> 
> > From: Michael Stone 
> > To: openssh-unix-dev at mindrot.org
> > Sent: Tue, January 5, 2010 11:18:03 AM
> > Subject: Re: OpenSSH daemon security bug?
> > 
> > On Tue, Jan 05, 2010 at 07:27:00PM +0100, you wrote:
> > > Password authentication with a weak password is in itself no more secure
> > > than public key authentication where the private key is protected with a
> > > weak password. In the former case the attacker only needs to guess the
> > > password, in the latter case they also need to get the private key.
> > > Knowledge of the public key does not help an attacker.
> > 
> > You can force the password complexity on the server side. You can't force the 
> > key management through technical means. That's a very important difference. 
> > Where this has proven to be a major headache in practice is when people have 
> > copies of their private keys scattered around on various machines, leading to 
> > intruders being able to jump from one machine to another. (Possibly from one 
> > organization to another, especially in collaborative environments like 
> .edu's.) 
> > 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.
> 
> 
> 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?