sshd: SSH_CLIENT_CERT and SSH_CLIENT_PUBKEY env variables

[Adam Eijdenberg]

On Fri, May 5, 2017 at 2:45 AM, Anton Worshevsky <gbdj at gbdj.ru> wrote:
> My use case:
> Use sshd for authentication
> but expose verified pubkey/certificate to API server application
> for sophisticated authorization by role based access control.

Last year for a time I thought we might also want something like this,
and I'll share the thought process we went through in case it's
helpful for others, even though it's not directly related to this
patch proposal.

The problem that I was trying to solve was to make use of SSH
certificates to authenticate (using git command line tooling) to a
locally hosted GitLab server.

GitLab by default, expects all clients to connect as the "git" user,
but then automatically maintains an "authorized_keys" file that
essentially acts as a map between the key used to authenticate and a
specific command (that includes a GitLab user identifier) to run.

I ended up auto-generating an authorized_principals file for our
GitLab users instead and documented what we did here:
https://github.com/gitlabhq/gitlab-shell/issues/249

Initially I thought this would have been simpler if an environment
variable with the principals presented during authentication was
present, however the immediate next question would be which one to use
if more than one is present? (and in our case, many of our certs
included multiple principals)

Upon reflection, it felt to me like this was still pretty hacky, and
that a better approach for our particular use-case (with GitLab) may
have been to have the users specify git remotes with their own normal
SSH usernames, then let sshd do it's thing, and then have the
"gitlab-shell" command (or similar on the server) do some kind of SUID
magic to map from the actual unix user authenticated to a command
running as git with corresponding GitLab user ID as an argument
however we ended up feeling that was too invasive a set of changes,
and stuck with our 1-line GitLab patch documented above.