Change Details

The way GitLab sets up Git access is to create a local `git` user and add to that user's `authorized_keys` file a line for all the suers; e.g., `command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-[key-id]",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty [key]` By default (for the omnibus package) this seems to live in `/var/opt/gitlab/.ssh/authorized_keys` (`/var/opt/gitlab` is the `$HOME` for the `git` user that it creates). GitLab does allow ssh to run on a non standard port by setting `gitlab_rails['gitlab_shell_ssh_port'] = [alt-port-number]` in `/etc/gitlab/gitlab.rb`. This becomes complicated on our production machines: * Puppet manages SSH which would probably not appreciate this system interfering * There are bastions involved (which wouldn't necessarily have the keys of folks who registered for developer accounts even though those keys are in ldap). A proposal for a workaround would be to have a second `sshd` process running on a different port that GitLab can manage. This is effectively what we do for Gerrit (i.e., Gerrit has an ssh daemon that is running on the JVM on port 29418 that is managed entirely by Gerrit.

The way GitLab sets up Git access is to create a local `git` user and add to that user's `authorized_keys` file a line for each user; e.g., `command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-[key-id]",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty [key]` By default (for the omnibus package) this seems to live in `/var/opt/gitlab/.ssh/authorized_keys` (`/var/opt/gitlab` is the `$HOME` for the `git` user that it creates). GitLab does allow ssh to run on a non standard port by setting `gitlab_rails['gitlab_shell_ssh_port'] = [alt-port-number]` in `/etc/gitlab/gitlab.rb`. This becomes complicated on our production machines due to (at least): * Puppet manages SSH which would probably not appreciate this system interfering * There are bastions involved (which wouldn't necessarily have the keys of folks who registered for developer accounts even though those keys are in ldap). A proposal for a workaround would be to have a second `sshd` process running on a different port that GitLab can manage. This is effectively what we do for Gerrit (i.e., Gerrit has an ssh daemon that is running on the JVM on port 29418 that is managed entirely by Gerrit.

The way GitLab sets up Git access is to create a local `git` user and add to that user's `authorized_keys` file a line for all the suers;each user; e.g., `command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-[key-id]",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty [key]` By default (for the omnibus package) this seems to live in `/var/opt/gitlab/.ssh/authorized_keys` (`/var/opt/gitlab` is the `$HOME` for the `git` user that it creates). GitLab does allow ssh to run on a non standard port by setting `gitlab_rails['gitlab_shell_ssh_port'] = [alt-port-number]` in `/etc/gitlab/gitlab.rb`. This becomes complicated on our production machines due to (at least): * Puppet manages SSH which would probably not appreciate this system interfering * There are bastions involved (which wouldn't necessarily have the keys of folks who registered for developer accounts even though those keys are in ldap). A proposal for a workaround would be to have a second `sshd` process running on a different port that GitLab can manage. This is effectively what we do for Gerrit (i.e., Gerrit has an ssh daemon that is running on the JVM on port 29418 that is managed entirely by Gerrit.