Proposal for collaboration

[Dmitri Pal]

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