ssh server configuration - Are public key and password exclusive?

[Christopher Browne]

On Fri, Jan 13, 2012 at 3:03 PM, Jamon Camisso
<jamon.camisso-H217xnMUJC0sA/PxXw9srA at public.gmane.org> wrote:
> 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.

... Or by *any* mechanism that allows authorized keys to get captured
in a centralized way.

I might like the idea of inserting the ssh key, along with other data,
into a Postgres table.

You might be keen on stowing the ssh keys into a set of files pulled
into place by Puppet/CFEngine.

Someone else might feel that MongoDB is more "web scale", and stow ssh
keys into a MongoDB store.

The other option I'd think pretty logical would be to stow the ssh
keys as attributes in an LDAP store.

And it's a SMOP (Simple Matter Of Programming) to pull the data out of
*any* of those to generate an authorized_keys file.

Note that the Original Poster *wanted* to use ssh keys as part of the
authentication process; in that case, if the authorized_keys mechanism
"doesn't scale," then the whole notion of using ssh keys is
problematic, and all of the above amounts to shuffling around deck
chairs whilst the ship is sinking underneath you...
-- 
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