Proposal for collaboration

[Dmitri Pal]

On 03/27/2011 07:16 AM, Damien Miller wrote:
> Hi,
>

First of all thank you for the long awaited reply!

> We'd probably support the your first two feature requests (delegating
> authorized_keys and known_hosts lookups) though agents or plugins.

Can you please elaborate on this a little bit?
Do you have a specific design or plans?

> There are a couple of outstanding bugs on https://bugzilla.mindrot.org/
> with patches to implement at least the authorized_keys part of this
> that have been on my TODO list for a while (and will probably stay
> there for a little while longer, sorry)

Any hints on when you would be able to look into this?
We have our own prioritization and time lines so without a clear
understanding of when it is possible we would not be able to plan the
effort on our side.

> I don't know if we would be that interested in externally-managed
> .shosts/.rhosts support. Hostbased authentication is a niche feature
> as it is and I'm not convinced that we should invest more effort to
> generalise it. I guess if the authorized_keys agent/helper code is
> reusable then we might consider it.

This was just an idea as we in IPA and SSSD pay a lot of attention to
the host management to and have a way to provide this information easily.
We can defer it for now.

> -d
>
> On Wed, 23 Mar 2011, Dmitri Pal wrote:
>
>> Hello,
>>
>> Some time ago I sent an email below with the thoughts regarding
>> integrating SSH with the central identity server (IPA) that would
>> provide the storage for keys and policies.
>> The details are below. Unfortunately there was no reply then.
>>
>> We are very interested in continuation of this conversation as
>> integration of SSH with central management solutions is something that
>> is very frequently asked about.
>>
>> I hope we can start over and have a productive dialog this time.   
>>
>> Thank you,
>> Dmitri
>>
>> On 09/08/2010 08:44 PM, Dmitri Pal wrote:
>>> Hello,
>>>
>>> My is Dmitri Pal and for the last two years I have been working on SSSD
>>> and IPA open source projects.
>>> SSSD is effectively a replacement for PAM/NSS combination with offline
>>> caching. The details about the project can be read here:
>>> https://fedorahosted.org/sssd/
>>> Quick overview of features is here:
>>> https://fedorahosted.org/sssd/attachment/wiki/Contribute/sssd%20overview%20slides.2.pdf
>>> SSSD has been actively developed during last two years. It is a part of
>>> several Linux distributions and is pretty stable now.
>>>
>>> IPA is a project that combines MIT KDC with 389 DS. Its v2 is due to be
>>> released later this year.
>>> http://www.freeipa.org/page/Main_Page
>>> https://fedorahosted.org/freeipa/
>>>
>>> IPA as a server (though in the context of the discussion below can be
>>> replaced with any other LDAP server) together with SSSD provide a
>>> powerful central management solution for different security and identity
>>> aspects of the UNIX/Linux systems.
>>>
>>> We think that SSSD and IPA projects are mature enough to start thinking
>>> about integrating more tightly with different much more well established
>>> utilities and security solutions as sudo and openssh.
>>> Here are several ideas about how SSSD and IPA can be integrated with
>>> openssh to provide better management capabilities to the users.
>>>
>>> 1) Centrally managing the user public keys. Instead of having user
>>> public keys in a key file on each system the appropriate key(s) can be
>>> delivered to the server host via SSSD and IPA (or other LDAP server). It
>>> is similar to openssh-lpk effort but a bit different  (see below).
>>> 2) Centrally managing fingerprints  of the server keys. If the server
>>> host fingerprint is loaded into the central server like IPA the SSSD
>>> would be able to get and cache it. openssh in turn can fetch it from
>>> SSSD on as needed basis and do a silent fingerprint verification without
>>> requiring user interaction. I see that there is a DNS option supported
>>> but  this lacks caching that SSSD will be able to provide.
>>> 3) IPA introduces concept of hosts and host groups. SSSD has/will have a
>>> capability to take advantage of such functionality. This means that SSSD
>>> would be able to help openssh with .shosts and .rhosts contents too.      
>>>  
>>> I do not know the design and code of the openssh, sorry, to the extent
>>> of starting to talk about specific functions but what I wanted to
>>> suggest is defining some kind of pluggable interface in openssh that
>>> would abstract the source of the public keys, fingerprints and access
>>> checks (may be something else we can help with too). Such pluggable
>>> interface would allow projects like openssh-lpk and SSSD to build
>>> pluggable providers for those crucial pieces of information.
>>>
>>> Is there any interest of pursuing such path together? I see it as
>>> creating an interface that can be enabled through a specific config
>>> value. For example "SecurityProvider". This option would have to be a
>>> path to a .so that should provide a defined agreed to interface. If the
>>> configuration option is not given the current rules are respected. If it
>>> is given then the openssh will call API functions to get keys,
>>> fingerprints or do host checks implemented by this .so.
>>> This can definitely be designed in some other way more suitable for the
>>> openssh project and aligned to its vision but I hope it is clear what we
>>> want to try to accomplish.
>>>
>>> Would be glad to discuss any options of mutual long and short term
>>> collaboration.
>>>
>>> Thank you,
>>> Dmitri Pal
>>>
>>>
>>
>> -- 
>> Thank you,
>> Dmitri Pal
>>
>> Sr. Engineering Manager IPA project,
>> Red Hat Inc.
>>
>>
>> -------------------------------
>> Looking to carve out IT costs?
>> www.redhat.com/carveoutcosts/
>>
>>
>>
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/