Christos Zoulas wrote:
> In article <20050314102548.GH27469@apb-laptoy.apb.alt.za>,
> Alan Barrett  <apb@cequrux.com> wrote:
> 
>>On Sun, 13 Mar 2005, Christos Zoulas wrote:
>>
>>>Why is everyone jumping the gun? I just tried it and it works fine for
>>>me. Can someone explain what the problem is? I commented out all my
>>>authorized keys entries and sshd did not let me in anymore.
>>
>>I explained it before.  See
>>http://mail-index.NetBSD.org/tech-security/2005/02/27/0002.html.
>>
>>If you don't see the problem from that explanation, then
>>perhaps this scenario will help.
>>
>>I have two hosts, laptop and desktop.
>>
>>desktop is in a secure location.  No untrusted people have physical
>>access to it.  No untrusted people have root on it.  No backups are
>>stored in untrusted locations.  No untrusted people even have accounts
>>on it.
>>
>>I have an ssh key pair, K_public and K_private.  On my desktop machine,
>>K_public is listed in ~/.ssh/authorized_keys.  On my laptop machine,
>>K_private is encrypted using a strong passphrase, and the resulting
>>copy of E(strong,K_private) is stored in the file system.  On my
>>desktop machine, K_private is encrypted using a weak passphrase, and
>>the resulting copy of E(weak,K_private) is stored in the file system.
>>The copy of E(weak,K_private) is protected by filesystem permissions,
>>with the intent that only trusted people who have already logged in, or
>>people with physical access to bypass filesystem permissions, can read
>>the file in which the key is stored.
>>
>>In the past, to login to my desktop, I would start on my laptop, use the
>>strong passphrase to unlock the laptop's copy of E(strong,K_private) to
>>ssh to the desktop.  Once I was on the desktop, I could use the weak
>>passphrase to unlock the desktop's copy of E(weak,K_private) to ssh to
>>anywhere else.  The weak passphrase was never useful to people who did
>>not already have access to my files on my desktop machine.
>>
>>In the past, somebody with physical access to my desktop could bypass
>>filesystem security to steal a copy of E(weak,K_private), and guess
>>the weak passphrase, and thereby get access to my account.  Similarly,
>>somebody who could exploit bugs to get access to my account on desktop
>>could steal a copy of E(weak,K_private).  But I judged the risk of that
>>to be acceptable.
>>
>>Now, the weak passphrase allows anybody to login to my desktop machine,
>>without even having to steal a copy of E(weak,K_private).  This is a
>>huge break with past tradition.  This totally changes the security model
>>for SSH private keys.  I do not like this at all.
> 
> 
> Weak == "empty passphrase". Isn't that right? 

No, not necessarily empty.  Just "weak".  I used an empty passphrase in 
my example because it was the particular case that bit me, and will 
likely bite others.

But consider that the system may have a password policy that prevents 
you from setting a stupid password like "hi" on your account.  And that 
"ssh-keygen" enforces no such policy.  So with pam_ssh enabled, I can 
bypass the system policy and set any password I like on my account, 
simply by creating an ssh private key with my desired bad password as 
its passphrase.

> The issue here is with
> the pam module, loading the weak key and trying to authenticate with
> an empty passphrase. Or am I understanding this incorrectly?

That's worded way too vaguely for me to tell if you're understanding the 
problem or not.  The pam_ssh module isn't "loading" any keys in the 
sense of using those keys themselves for authentication.  It just allows 
the *passphrase* for the private key to be used as an *additional* login 
password for the account containing that private key.  In many common 
cases, that passphrase will be too weak to be desirable as a login 
password.  So in the true UNIX tradition, go ahead and give the admin 
the rope, but *please* don't hang him with it by default.  Please!

-- 
entropy -- it's not just a good idea, it's the second law.