> [...]
> (For example, I am not sure how well - if at all - the CA infra works
> for SSH.)
> But we do use a web of trust, we have the L[n] keys and we make use of
> that for e.g. signing developer keys (as well as for infra managing
> access to devboxes). That could be replaced by LDAP at least for the
> latter part though, not so much for the former AFAIK (not sure if 'ssh
> keyrings' exist in some exportable forat).
There is no concept of keyrings for ssh, so we would have to come up
with a distribution channel for developer keys (but I mean, a long file
listing all valid ssh keys isn't much different from a key chain...).
An intriguing alternative would be certificates [1].
So let's say you have a developer pubkey id_developer.pub and a gentoo
infrastructure key id_gentoo_ca.pub then you can issue a certificate for
the developer with something like:
ssh-keygen -s id_gentoo_ca \
-I key_id -z serial_number -V validity_interval -n principal \
id_developer.pub
Here,
- key_id and serial_number allow you to use a naming scheme (and
serial number) of your choosing to distinguish certificates
- validity_interval allows you to restrict the validity of the
certificate
- and the "principal" should be the username "[email protected]".
- Furthermore, the -O flag allows you to add a number of ssh-specific,
but also arbitrary options into the certificate. This could be used
to selectively allowing (or disallowing) certain actions (such as
signing a git commit, or pushing to the server).
The developer now ends up with the following triplet of a pubkey:
id_developer
id_developer.pub
id_developer-cert.pub
and openssh uses the certificate transparently when connecting to a
server or (when id_developer-cert.pub is specified) when signing.
openssh, consciously, does not provide any tooling how to distribute or
maintain certificates. So figuring this out would be our
task. Concretely, what we would have to design is an infrastructure that
allows a developer to request the certificate [1, 2].
The nice advantage of this approach is that for validation you only need
to distribute the id_gentoo_ca pubkey along with a description that it
is used as a CA:
*.gentoo.org cert-authority,namespaces="gentoo" <id_gentoo_ca.pub string>
The one big advantage of this approach (as already mentioned in [1]) is
the fact that certificates allow you to validate whether a developer is
allowed to perform a certain action (at a particular instance in time)
without the need of having an up-to-date keychain.
I like this approach for its elegance, but I doubt that we benefit
terribly much from its benefits. So I'll leave my way too elaborate
blabla at that :-)
Best,
Matthias
[1] Support for certificates in openssh exists because it solves a real
problem for large companies where the number of employees who should
be allowed to access a resource might vary wildly, and (a) the
constant redistribution of keychains is painful, and (b) if a server
fails to receive an updated keychain then the failure mode might be
catastrophical.
[2] A number of commercial solutions for this exist, that tie some
enterprisey authentication to retrieving a short-lived purpose-bound
ssh certificate (think "developer is allowed to log into server type
bla for the next 4h".)
[3] We could, for example, provide a command line tool that essentially
ssh'es into dev.gentoo.org, requests the certificate and puts it
into place.
