Define and document the effects of X11 forwarding requests on gitlab-sshd
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Summary
Via this (internal only) ticket: gitlab-sshd's handling of X11 forwarding requests is unspecified.
We lack documentation around whether this could cause problems or not and we also don't seem to explicitly discourage users from using this flag (Even though it should have no effect)
As observed in the ticket mentioned above, this interaction appears to cause connections to not get closed immediately when using our suggested CNH infrastructure.
This was observed when using git for Windows and plink.exe (PuTTY CLI) as a drop in replacement for OpenSSH
Steps to reproduce
Example Project
I've been unable to reproduce this using standard Omnibus based deployments and ssh -X though we've received confirmation from the customer that simply disabling X11 forwarding completely solves the problem.
What is the current bug behavior?
Currently, gitlab-shell rejects X11 forwarding requests:
Authenticated to localhost ([127.0.0.1]:2222).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: exec
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = C.UTF-8
debug1: Sending command: git-upload-pack '/root/abvc.git'
X11 forwarding request failed on channel 0
remote: Enumerating objects: 15, done.
remote: Counting objects: 100% (2/2), done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 15 (delta 1), reused 0 (delta 0), pack-reused 13
Receiving objects: 100% (15/15), 5.83 KiB | 5.83 MiB/s, done.What is the expected correct behavior?
Whether we continue to do this the same way or not, we should document the potential downsides. If anyone has a better approach, feel free to suggest it.
To be clear, we already reject X11 forwarding requests and I don't know that any more actions on the gitlab-shell side of things will help this, but we should document and advise against this at a minimum.
Relevant logs and/or screenshots
N/A
Output of checks
N/A
Results of GitLab environment info
GitLab CNH 3k Reference architecture; 16.4.1 and 16.5.1 have been tested thus far.
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)(we will only investigate if the tests are passing)