Proposal for collaboration

Dmitri Pal dpal at
Thu Mar 24 00:47:17 EST 2011


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,

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:
> Quick overview of features is here:
> 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.
> 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?

More information about the openssh-unix-dev mailing list