ssh server configuration - Are public key and password exclusive?

[Christopher Browne]

On Fri, Jan 13, 2012 at 2:07 PM, William Muriithi
<william.muriithi-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
>>
>> Well, if I use a key that has a password attached, then the local
>> agent checks the password before allowing access to the key for the
>> purposes of using the key to access a remote system.  However there is
>> not a way for the sshd server to determine whether or not the password
>> on that key was null, and the validation takes place on the local
>> host, it's not done by sshd.

> No that is not what I wanted.  That is a client solution and does not
> scale or can not be enforced

It *can* be enforced if the process that draws in entries for
~/.ssh/authorized_keys requires checking that the private key has a
password.

As for "does not scale," I'm not sure that your requirement can be
considered to "scale", but I think that requires explaining precisely
what you mean, as "does not scale" is an overloaded term that itself
'does not scale'.

> Hmm, now that is the answer to my question.  Hmm, I guess I will go
> with Google authenticator as Jason mentioned.

Plausible.  That requires NTP syncing.  There may be other
implementations of RFC 4226 available; haven't looked hard, so not
certain.

>> Another thought would be to hack with the resulting shell to require a
>> password check after logging in via the public key.
> Agree Neil, I do not see why openssh decided not to support password
> and PKI.  They would just have needed one configuration flag and a bit
> of code refactoring.
>
> Wonder if there is any public discussion out there on how they arrived
> on this decision?  May be there is security implication behind it,
> since openssh developers are security guys.

They put a hook in place allowing a secondary authentication layer.

But configuring multiple mechanisms is something that I'd suggest
"does not scale," as it requires an exponential growth of
configuration to control what authentication is to be used, in which
order, and it introduces additional failure modes, thereby lowering
reliability and introducing risks of self-imposed denials of service.

It's not obvious that there's much gained for those diminishments of
scalability...
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists