Proposal for collaboration

[Damien Miller]

Hi,

We'd probably support the your first two feature requests (delegating
authorized_keys and known_hosts lookups) though agents or plugins.
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)

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.

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