Agreed, I think we should look for better integrations into other projects like FreeIPA, so users can easily do this. A authentication infrastructure project like FreeIPA will always do a better job than we could do imo
Sean On Tuesday, 13 September 2016, Stephen Benjamin <[email protected]> wrote: > > > ----- Original Message ----- > > From: "Marek Hulán" <[email protected] <javascript:;>> > > To: [email protected] <javascript:;> > > Sent: Tuesday, September 13, 2016 10:13:45 AM > > Subject: Re: [foreman-dev] Using certificates for SSH access > > > > Hello > > > > some comments below > > > > On Tuesday 13 of September 2016 08:51:12 Ohad Levy wrote: > > > Hi, > > > > > > I was looking at [1] which talks about how to leverage a CA for > managing > > > SSH access, and I thought it could be interesting for REX and > potentially > > > for foreman to manage. > > > > > > In the post, they describe how they create different principles > (groups - > > > think hostgroups) for access, generating certificates with expatriation > > > etc. > > > > > > Since we already have some of the certificate handling code (puppet ca, > > > pulp / katello certs) I wonder if it make sense to generalize it and > offer > > > SSH certificates (and their management and possible an auditing system > for > > > their usage) offering? > > > > I was thinking about this earlier, the major benefit I see is that in > case we > > change the key that Foreman uses we wouldn't have to update all hosts. > Since > > we currently only install it during provisioning it might be very > helpful. > > OTOH we should also provide puppet module that would configure this key > so > > there's easy way to update it also for unmanaged hosts. Then the CA > might not > > have that many benefits, we'd have to distribute the CA pub key instead > of > > the > > main pub key. Probably the biggest benefit would be the key expiration. > > > > If we decide to generalize the CA handling I'd first look if we could use > > something existing, e.g. FreeIPA. Maybe we could provide our simple > backend > > too but I'd like to avoid building our own CA on top ssh-keygen :-) I'd > also > > like to keep it in separate plugin - probably rex. > > > The CA use with ssh-keygen is a neat idea, but FreeIPA does some great > things > that I'd rather not have us have to deal with. The Facebook article > towards > the end evens offers warnings about the lack of any kind of revocation > scheme. > > FreeIPA can do that, and handles it quite gracefully. If a smart proxy key > gets compromised, you can just remove it from authorized keys in FreeIPA > and it propagates everywhere automatically. > > And we could even go further with FreeIPA and not have to deal with SSH > keys > at all and go the kerberos route, which handles access controls, key > revocation, > expiration, etc all very nicely. We have an RFE for that[1]. > > > - Stephen > > [1] http://projects.theforeman.org/issues/11936 > > > > -- > > Marek > > > > > > > > Ohad > > > > > > [1] > > > https://code.facebook.com/posts/365787980419535/ > scalable-and-secure-access-w > > > ith-ssh/ > > > > -- > > You received this message because you are subscribed to the Google Groups > > "foreman-dev" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected] <javascript:;>. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:;>. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
