On Thu, 2020-01-30 at 16:37 +0000, Brian Candler wrote:
> On 30/01/2020 15:02, Christian, Mark wrote:
>
> > On Thu, 2020-01-30 at 12:27 +0000, Brian Candler wrote:
> > > As a concrete example: I want Alice to be able to login as
> > > "alice"
> > > and
> > > "www" to machines in group "webserver" (only). Also, I want Bob
> > > to
> > > be
> > > able to login as "bob" and "www" to machines in group "webserver"
> > > (only).
> >
> > Why can't you have a AuthorizedPrincipalsFile for alice, bob and
> > www on
> > each of the "web servers", where the contents of the alice file
> > include
> > the principal name alice, the contents of the bob file contain the
> > bob
> > principal, and the contents of the www file contain the contents
> > alice
> > and bob? Wouldn't that allow alice to ssh as alice, and www, and
> > allow
> > bob to ssh as bob and www to any machines that had this
> > authorizedPrincipals file configuration?
>
> Yes, that would work, but then it comes back down to configuration
> management to push out all authorizations (and more importantly,
> remove them when no longer authorized). If you're going to do that,
> it's not too far removed from pushing out ~/.ssh/authorized_keys for
> each user.
>
>
> I was hoping to avoid the dependency on configuration management by
> carrying the authorization in the certs themselves - if that is in
> the spirit of the SSH cert mechanism.
>
Sign alice and bob's ssh cert with principal's alice,www and bob,www
respectively. Configure sshd_config so that individuals don't require
an authorizedprincipalfile, and use Match within sshd_config for any
"service/faceless" account like www, to force use of an
authorizedprincipalfile. The contents of www's authorizedprincipal
file will simply contain the principal "www" or whatever you
choose. This should limit configuration mgmt dependency.
However, when alice is no longer authorized, and assuming her cert is
still valid, you're going to want to use some configuration mgmt to
manage RevokedKeys, otherwise ensure that alice's cert is valid for a
short period of time.
Mark
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
