On Fri, May 5, 2017 at 2:45 AM, Anton Worshevsky <gbdj@xxxxxxx> 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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
