Using certificates for SSH access

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?

Ohad

[1]

Hello

some comments below

> 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 :slight_smile: I'd also
like to keep it in separate plugin - probably rex.

··· On Tuesday 13 of September 2016 08:51:12 Ohad Levy wrote:


Marek

Ohad

[1]
https://code.facebook.com/posts/365787980419535/scalable-and-secure-access-w
ith-ssh/

> From: "Marek Hulán" <mhulan@redhat.com>
> To: foreman-dev@googlegroups.com
> Sent: Tuesday, September 13, 2016 10:13:45 AM
> Subject: Re: [foreman-dev] Using certificates for SSH access
>
> Hello
>
> some comments below
>
> > 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 :slight_smile: 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] Feature #11936: Support kerberized SSH as an alternative to keys - Foreman Remote Execution - Foreman

··· ----- Original Message ----- > On Tuesday 13 of September 2016 08:51:12 Ohad Levy wrote:


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 foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

----- Original Message -----

From: “Marek Hulán” <mhulan@redhat.com <javascript:;>>
To: foreman-dev@googlegroups.com <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 :slight_smile: 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] Feature #11936: Support kerberized SSH as an alternative to keys - Foreman Remote Execution - Foreman


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 foreman-dev+unsubscribe@googlegroups.com <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 foreman-dev+unsubscribe@googlegroups.com <javascript:;>.
For more options, visit https://groups.google.com/d/optout.