ssh server configuration - Are public key and password exclusive?

[Jamon Camisso]

On 1/13/2012 2:32 PM, Christopher Browne wrote:
> 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'.

Relying on .ssh/authorized_keys is probably only maintainable using
something like puppet or cfengine. Otherwise, that certainly won't
scale. Also, if the user can change the contents of that file, whatever
commands are being enforced there can be bypassed. Better to use
ForceCommand in sshd_config.

>> 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.

It is not that difficult to maintain accurate time these days. I haven't
run into any problems using my mobile phone with google authenticator.
Additionally, the RFC 4226 allows for HMAC one time passwords instead of
time based, so maintaining clock-sync needn't be a complete blocker for
implementing this.

>>> 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...

Using Match Group haxors and a subsequent ForceCommand to control
multi-factor authentication can scale to as many users as are in said
haxors group, or as many users or groups as you need to support. With a
central policy based configuration tool there is no reason this cannot
scale to as many entries as SSH itself supports in sshd_config (no idea
what that limit might be).

This type of configuration also addresses the problem of users being
able to manipulate their .ssh/authorized_keys files, since the command
cannot be altered by the user.

Jamon
--
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