BranchesTags

Repository files navigation

GitLab SSH Proxy

One if the issue with running a GitLab instance in a container is to expose the GitLab SSH in the host machine without conflicting with the existing SSH port (22) on the host.

What usually happens:

git://git@hostname:2222/username/project.git

We want them to look like this instead:

git://git@hostname/username/project.git

There are several alternatives online (see References below). But I would like to avoid:

  • Hardcoding the UID and GID of any account in the host machine
  • Running additional services/daemon in the host machine
  • Providing Docker access to a special account in the host machine
  • Duplicating GitLab's authorized_keys files in the host machine

For a detailed explanation, see the How Does It Work section below.

Step by Step

Build and install.

sudo ./setup.sh install

It will do the following things:

  1. Copy the follwoing scripts to /usr/local/bin
  2. Build and install an SE Linux policy module: gitlab-ssh.te to allow scripts executed from the SSH daemon to run the ssh binary.
  3. Copy 99-gitlab-proxy.conf to /etc/ssh/sshd_config.d/

Create the git user on the host

sudo useradd -m git

Create a new SSH key-pair

sudo su - git -c "ssh-keygen -t ed25519"

Assuming the GitLab container was started with --volume /srv/gitlab/ssh:/gitlab-data/ssh:Z, copy and rename the public key to /srv/gitlab/ssh/authorized_keys.

sudo cp /home/git/.ssh/id_ed25519.pub /srv/gitlab/ssh/authorized_keys

Fix the permission/ownership of the authorized_keys file to ensure that is only readable by the git user within the container. Otherwise SSH won't use the file.

# If you are using Docker, substitute podman with docker
podman exec -it gitlab /bin/sh -c \
"chmod 600 /gitlab-data/ssh/authorized_keys; chown git:git /gitlab-data/ssh/authorized_keys"

Reload the SSH Service

sudo systemctl reload sshd

You're good to go!

Configuration

By default the scripts assumes that the GitLab SSH service is accessible at git@localhost port 2222. If your setup is different, you can override this by creating a file named gitlab-ssh.conf in /home/git/.config or /etc.

In this file you can define the following environment variables:

GITLAB_HOST=git@localhost
GITLAB_PORT=2222

Uninstall

This will remove all the script files and the SE Linux proxy module.

sudo ./setup.sh remove

How Does it Work

First we would need to have a git user in the host machine. When a user connects via SSH, it should be able to somehow redirect/forward the request as the git user in the container.

GitLab authenticates users based on their SSH keys. This is traditionally done by adding the user's public key into an authorized_keys file. Recently GitLab foregoes this file and uses a database instead. To do this GitLab uses a feature in the Open SSH server called AuthorizedKeysCommand which allows it to execute a program to query its keys database and return the relevant key data.

In the host, we do the same thing. We configure the AuthorizedKeysCommand to call our gitlab-keys-check script when someone tries to login as git. This script runs ssh to the container (via port 2222) and execute the actual tool, gitlab-shell-authorized-keys-check. It would return an authorized_keys entry which looks like this:

command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The command option at the beginning forces the SSH server to execute /opt/.../bin/gitlab-shell when the key is used to login. This command does not exist in the host machine. Therefore before we return it we must replace this with /usr/local/bin/gitlab-shell-proxy.

command="/usr/local/bin/gitlab-shell-proxy key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The SSH server will see the updated command and execute gitlab-shell-proxy. This script will ssh to the container and execute the actual binary /opt/.../bin/gitlab-shell, effectively creating a proxy to the GitLab container.

For this to work, the git user in the host would need to have an authorized_key in the GitLab container. Therefore copy its public key file into /gitlab-data/ssh/authorized_keys in the container. We also need to adjust the file permission as Open SSH is quite strict about it.

There is one complication. In machines with SE Linux enabled, we are unable to execute ssh from the AuthorizedKeysCommand. To workaround this, we would need to install a custom policy file gitlab-ssh.te to enable this.

References

About

SSH Proxy for Dockerized GitLab Container

Topics

gitlabgitlab-cegitlab-dockerssh-config

Resources

Readme
Activity

Stars

27 stars

Watchers

1 watching

Forks

8 forks
Report repository

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
BranchesTags
Repository files navigation
GitLab SSH Proxy
One if the issue with running a GitLab instance in a container is to expose the GitLab SSH in the host machine without conflicting with the existing SSH port (22) on the host.
What usually happens:
git://git@hostname:2222/username/project.git 
We want them to look like this instead:
git://git@hostname/username/project.git 
There are several alternatives online (see References below). But I would like to avoid:
  • Hardcoding the UID and GID of any account in the host machine
  • Running additional services/daemon in the host machine
  • Providing Docker access to a special account in the host machine
  • Duplicating GitLab's authorized_keys files in the host machine
For a detailed explanation, see the How Does It Work section below.
Step by Step
Build and install.
sudo ./setup.sh install

It will do the following things:
  1. Copy the follwoing scripts to /usr/local/bin
  2. Build and install an SE Linux policy module: gitlab-ssh.te to allow scripts executed from the SSH daemon to run the ssh binary.
  3. Copy 99-gitlab-proxy.conf to /etc/ssh/sshd_config.d/
Create the git user on the host
sudo useradd -m git
Create a new SSH key-pair
sudo su - git -c "ssh-keygen -t ed25519"
Assuming the GitLab container was started with --volume /srv/gitlab/ssh:/gitlab-data/ssh:Z, copy and rename the public key to /srv/gitlab/ssh/authorized_keys.
sudo cp /home/git/.ssh/id_ed25519.pub /srv/gitlab/ssh/authorized_keys
Fix the permission/ownership of the authorized_keys file to ensure that is only readable by the git user within the container. Otherwise SSH won't use the file.
# If you are using Docker, substitute podman with docker
podman exec -it gitlab /bin/sh -c \
"chmod 600 /gitlab-data/ssh/authorized_keys; chown git:git /gitlab-data/ssh/authorized_keys"
Reload the SSH Service
sudo systemctl reload sshd
You're good to go!
Configuration
By default the scripts assumes that the GitLab SSH service is accessible at git@localhost port 2222. If your setup is different, you can override this by creating a file named gitlab-ssh.conf in /home/git/.config or /etc.
In this file you can define the following environment variables:
GITLAB_HOST=git@localhost
GITLAB_PORT=2222
Uninstall
This will remove all the script files and the SE Linux proxy module.
sudo ./setup.sh remove

How Does it Work
First we would need to have a git user in the host machine. When a user connects via SSH, it should be able to somehow redirect/forward the request as the git user in the container.
GitLab authenticates users based on their SSH keys. This is traditionally done by adding the user's public key into an authorized_keys file. Recently GitLab foregoes this file and uses a database instead. To do this GitLab uses a feature in the Open SSH server called AuthorizedKeysCommand which allows it to execute a program to query its keys database and return the relevant key data.
In the host, we do the same thing. We configure the AuthorizedKeysCommand to call our gitlab-keys-check script when someone tries to login as git. This script runs ssh to the container (via port 2222) and execute the actual tool, gitlab-shell-authorized-keys-check. It would return an authorized_keys entry which looks like this:
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The command option at the beginning forces the SSH server to execute /opt/.../bin/gitlab-shell when the key is used to login. This command does not exist in the host machine. Therefore before we return it we must replace this with /usr/local/bin/gitlab-shell-proxy.
command="/usr/local/bin/gitlab-shell-proxy key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The SSH server will see the updated command and execute gitlab-shell-proxy. This script will ssh to the container and execute the actual binary /opt/.../bin/gitlab-shell, effectively creating a proxy to the GitLab container.
For this to work, the git user in the host would need to have an authorized_key in the GitLab container. Therefore copy its public key file into /gitlab-data/ssh/authorized_keys in the container. We also need to adjust the file permission as Open SSH is quite strict about it.
There is one complication. In machines with SE Linux enabled, we are unable to execute ssh from the AuthorizedKeysCommand. To workaround this, we would need to install a custom policy file gitlab-ssh.te to enable this.
References
About
SSH Proxy for Dockerized GitLab Container
Topics
gitlabgitlab-cegitlab-dockerssh-config
Resources
Readme
Activity
Stars
27 stars
Watchers
1 watching
Forks
8 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
GitLab SSH Proxy
One if the issue with running a GitLab instance in a container is to expose the GitLab SSH in the host machine without conflicting with the existing SSH port (22) on the host.
What usually happens:
git://git@hostname:2222/username/project.git 
We want them to look like this instead:
git://git@hostname/username/project.git 
There are several alternatives online (see References below). But I would like to avoid:
  • Hardcoding the UID and GID of any account in the host machine
  • Running additional services/daemon in the host machine
  • Providing Docker access to a special account in the host machine
  • Duplicating GitLab's authorized_keys files in the host machine
For a detailed explanation, see the How Does It Work section below.
Step by Step
Build and install.
sudo ./setup.sh install

It will do the following things:
  1. Copy the follwoing scripts to /usr/local/bin
  2. Build and install an SE Linux policy module: gitlab-ssh.te to allow scripts executed from the SSH daemon to run the ssh binary.
  3. Copy 99-gitlab-proxy.conf to /etc/ssh/sshd_config.d/
Create the git user on the host
sudo useradd -m git
Create a new SSH key-pair
sudo su - git -c "ssh-keygen -t ed25519"
Assuming the GitLab container was started with --volume /srv/gitlab/ssh:/gitlab-data/ssh:Z, copy and rename the public key to /srv/gitlab/ssh/authorized_keys.
sudo cp /home/git/.ssh/id_ed25519.pub /srv/gitlab/ssh/authorized_keys
Fix the permission/ownership of the authorized_keys file to ensure that is only readable by the git user within the container. Otherwise SSH won't use the file.
# If you are using Docker, substitute podman with docker
podman exec -it gitlab /bin/sh -c \
"chmod 600 /gitlab-data/ssh/authorized_keys; chown git:git /gitlab-data/ssh/authorized_keys"
Reload the SSH Service
sudo systemctl reload sshd
You're good to go!
Configuration
By default the scripts assumes that the GitLab SSH service is accessible at git@localhost port 2222. If your setup is different, you can override this by creating a file named gitlab-ssh.conf in /home/git/.config or /etc.
In this file you can define the following environment variables:
GITLAB_HOST=git@localhost
GITLAB_PORT=2222
Uninstall
This will remove all the script files and the SE Linux proxy module.
sudo ./setup.sh remove

How Does it Work
First we would need to have a git user in the host machine. When a user connects via SSH, it should be able to somehow redirect/forward the request as the git user in the container.
GitLab authenticates users based on their SSH keys. This is traditionally done by adding the user's public key into an authorized_keys file. Recently GitLab foregoes this file and uses a database instead. To do this GitLab uses a feature in the Open SSH server called AuthorizedKeysCommand which allows it to execute a program to query its keys database and return the relevant key data.
In the host, we do the same thing. We configure the AuthorizedKeysCommand to call our gitlab-keys-check script when someone tries to login as git. This script runs ssh to the container (via port 2222) and execute the actual tool, gitlab-shell-authorized-keys-check. It would return an authorized_keys entry which looks like this:
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The command option at the beginning forces the SSH server to execute /opt/.../bin/gitlab-shell when the key is used to login. This command does not exist in the host machine. Therefore before we return it we must replace this with /usr/local/bin/gitlab-shell-proxy.
command="/usr/local/bin/gitlab-shell-proxy key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The SSH server will see the updated command and execute gitlab-shell-proxy. This script will ssh to the container and execute the actual binary /opt/.../bin/gitlab-shell, effectively creating a proxy to the GitLab container.
For this to work, the git user in the host would need to have an authorized_key in the GitLab container. Therefore copy its public key file into /gitlab-data/ssh/authorized_keys in the container. We also need to adjust the file permission as Open SSH is quite strict about it.
There is one complication. In machines with SE Linux enabled, we are unable to execute ssh from the AuthorizedKeysCommand. To workaround this, we would need to install a custom policy file gitlab-ssh.te to enable this.
References
About
SSH Proxy for Dockerized GitLab Container
Topics
gitlabgitlab-cegitlab-dockerssh-config
Resources
Readme
Activity
Stars
27 stars
Watchers
1 watching
Forks
8 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
GitLab SSH Proxy
One if the issue with running a GitLab instance in a container is to expose the GitLab SSH in the host machine without conflicting with the existing SSH port (22) on the host.
What usually happens:
git://git@hostname:2222/username/project.git 
We want them to look like this instead:
git://git@hostname/username/project.git 
There are several alternatives online (see References below). But I would like to avoid:
  • Hardcoding the UID and GID of any account in the host machine
  • Running additional services/daemon in the host machine
  • Providing Docker access to a special account in the host machine
  • Duplicating GitLab's authorized_keys files in the host machine
For a detailed explanation, see the How Does It Work section below.
Step by Step
Build and install.
sudo ./setup.sh install

It will do the following things:
  1. Copy the follwoing scripts to /usr/local/bin
  2. Build and install an SE Linux policy module: gitlab-ssh.te to allow scripts executed from the SSH daemon to run the ssh binary.
  3. Copy 99-gitlab-proxy.conf to /etc/ssh/sshd_config.d/
Create the git user on the host
sudo useradd -m git
Create a new SSH key-pair
sudo su - git -c "ssh-keygen -t ed25519"
Assuming the GitLab container was started with --volume /srv/gitlab/ssh:/gitlab-data/ssh:Z, copy and rename the public key to /srv/gitlab/ssh/authorized_keys.
sudo cp /home/git/.ssh/id_ed25519.pub /srv/gitlab/ssh/authorized_keys
Fix the permission/ownership of the authorized_keys file to ensure that is only readable by the git user within the container. Otherwise SSH won't use the file.
# If you are using Docker, substitute podman with docker
podman exec -it gitlab /bin/sh -c \
"chmod 600 /gitlab-data/ssh/authorized_keys; chown git:git /gitlab-data/ssh/authorized_keys"
Reload the SSH Service
sudo systemctl reload sshd
You're good to go!
Configuration
By default the scripts assumes that the GitLab SSH service is accessible at git@localhost port 2222. If your setup is different, you can override this by creating a file named gitlab-ssh.conf in /home/git/.config or /etc.
In this file you can define the following environment variables:
GITLAB_HOST=git@localhost
GITLAB_PORT=2222
Uninstall
This will remove all the script files and the SE Linux proxy module.
sudo ./setup.sh remove

How Does it Work
First we would need to have a git user in the host machine. When a user connects via SSH, it should be able to somehow redirect/forward the request as the git user in the container.
GitLab authenticates users based on their SSH keys. This is traditionally done by adding the user's public key into an authorized_keys file. Recently GitLab foregoes this file and uses a database instead. To do this GitLab uses a feature in the Open SSH server called AuthorizedKeysCommand which allows it to execute a program to query its keys database and return the relevant key data.
In the host, we do the same thing. We configure the AuthorizedKeysCommand to call our gitlab-keys-check script when someone tries to login as git. This script runs ssh to the container (via port 2222) and execute the actual tool, gitlab-shell-authorized-keys-check. It would return an authorized_keys entry which looks like this:
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The command option at the beginning forces the SSH server to execute /opt/.../bin/gitlab-shell when the key is used to login. This command does not exist in the host machine. Therefore before we return it we must replace this with /usr/local/bin/gitlab-shell-proxy.
command="/usr/local/bin/gitlab-shell-proxy key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The SSH server will see the updated command and execute gitlab-shell-proxy. This script will ssh to the container and execute the actual binary /opt/.../bin/gitlab-shell, effectively creating a proxy to the GitLab container.
For this to work, the git user in the host would need to have an authorized_key in the GitLab container. Therefore copy its public key file into /gitlab-data/ssh/authorized_keys in the container. We also need to adjust the file permission as Open SSH is quite strict about it.
There is one complication. In machines with SE Linux enabled, we are unable to execute ssh from the AuthorizedKeysCommand. To workaround this, we would need to install a custom policy file gitlab-ssh.te to enable this.
References
About
SSH Proxy for Dockerized GitLab Container
Topics
gitlabgitlab-cegitlab-dockerssh-config
Resources
Readme
Activity
Stars
27 stars
Watchers
1 watching
Forks
8 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
BranchesTags
Repository files navigation
GitLab SSH Proxy
One if the issue with running a GitLab instance in a container is to expose the GitLab SSH in the host machine without conflicting with the existing SSH port (22) on the host.
What usually happens:
git://git@hostname:2222/username/project.git 
We want them to look like this instead:
git://git@hostname/username/project.git 
There are several alternatives online (see References below). But I would like to avoid:
  • Hardcoding the UID and GID of any account in the host machine
  • Running additional services/daemon in the host machine
  • Providing Docker access to a special account in the host machine
  • Duplicating GitLab's authorized_keys files in the host machine
For a detailed explanation, see the How Does It Work section below.
Step by Step
Build and install.
sudo ./setup.sh install

It will do the following things:
  1. Copy the follwoing scripts to /usr/local/bin
  2. Build and install an SE Linux policy module: gitlab-ssh.te to allow scripts executed from the SSH daemon to run the ssh binary.
  3. Copy 99-gitlab-proxy.conf to /etc/ssh/sshd_config.d/
Create the git user on the host
sudo useradd -m git
Create a new SSH key-pair
sudo su - git -c "ssh-keygen -t ed25519"
Assuming the GitLab container was started with --volume /srv/gitlab/ssh:/gitlab-data/ssh:Z, copy and rename the public key to /srv/gitlab/ssh/authorized_keys.
sudo cp /home/git/.ssh/id_ed25519.pub /srv/gitlab/ssh/authorized_keys
Fix the permission/ownership of the authorized_keys file to ensure that is only readable by the git user within the container. Otherwise SSH won't use the file.
# If you are using Docker, substitute podman with docker
podman exec -it gitlab /bin/sh -c \
"chmod 600 /gitlab-data/ssh/authorized_keys; chown git:git /gitlab-data/ssh/authorized_keys"
Reload the SSH Service
sudo systemctl reload sshd
You're good to go!
Configuration
By default the scripts assumes that the GitLab SSH service is accessible at git@localhost port 2222. If your setup is different, you can override this by creating a file named gitlab-ssh.conf in /home/git/.config or /etc.
In this file you can define the following environment variables:
GITLAB_HOST=git@localhost
GITLAB_PORT=2222
Uninstall
This will remove all the script files and the SE Linux proxy module.
sudo ./setup.sh remove

How Does it Work
First we would need to have a git user in the host machine. When a user connects via SSH, it should be able to somehow redirect/forward the request as the git user in the container.
GitLab authenticates users based on their SSH keys. This is traditionally done by adding the user's public key into an authorized_keys file. Recently GitLab foregoes this file and uses a database instead. To do this GitLab uses a feature in the Open SSH server called AuthorizedKeysCommand which allows it to execute a program to query its keys database and return the relevant key data.
In the host, we do the same thing. We configure the AuthorizedKeysCommand to call our gitlab-keys-check script when someone tries to login as git. This script runs ssh to the container (via port 2222) and execute the actual tool, gitlab-shell-authorized-keys-check. It would return an authorized_keys entry which looks like this:
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The command option at the beginning forces the SSH server to execute /opt/.../bin/gitlab-shell when the key is used to login. This command does not exist in the host machine. Therefore before we return it we must replace this with /usr/local/bin/gitlab-shell-proxy.
command="/usr/local/bin/gitlab-shell-proxy key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The SSH server will see the updated command and execute gitlab-shell-proxy. This script will ssh to the container and execute the actual binary /opt/.../bin/gitlab-shell, effectively creating a proxy to the GitLab container.
For this to work, the git user in the host would need to have an authorized_key in the GitLab container. Therefore copy its public key file into /gitlab-data/ssh/authorized_keys in the container. We also need to adjust the file permission as Open SSH is quite strict about it.
There is one complication. In machines with SE Linux enabled, we are unable to execute ssh from the AuthorizedKeysCommand. To workaround this, we would need to install a custom policy file gitlab-ssh.te to enable this.
References
About
SSH Proxy for Dockerized GitLab Container
Topics
gitlabgitlab-cegitlab-dockerssh-config
Resources
Readme
Activity
Stars
27 stars
Watchers
1 watching
Forks
8 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
GitLab SSH Proxy
One if the issue with running a GitLab instance in a container is to expose the GitLab SSH in the host machine without conflicting with the existing SSH port (22) on the host.
What usually happens:
git://git@hostname:2222/username/project.git 
We want them to look like this instead:
git://git@hostname/username/project.git 
There are several alternatives online (see References below). But I would like to avoid:
  • Hardcoding the UID and GID of any account in the host machine
  • Running additional services/daemon in the host machine
  • Providing Docker access to a special account in the host machine
  • Duplicating GitLab's authorized_keys files in the host machine
For a detailed explanation, see the How Does It Work section below.
Step by Step
Build and install.
sudo ./setup.sh install

It will do the following things:
  1. Copy the follwoing scripts to /usr/local/bin
  2. Build and install an SE Linux policy module: gitlab-ssh.te to allow scripts executed from the SSH daemon to run the ssh binary.
  3. Copy 99-gitlab-proxy.conf to /etc/ssh/sshd_config.d/
Create the git user on the host
sudo useradd -m git
Create a new SSH key-pair
sudo su - git -c "ssh-keygen -t ed25519"
Assuming the GitLab container was started with --volume /srv/gitlab/ssh:/gitlab-data/ssh:Z, copy and rename the public key to /srv/gitlab/ssh/authorized_keys.
sudo cp /home/git/.ssh/id_ed25519.pub /srv/gitlab/ssh/authorized_keys
Fix the permission/ownership of the authorized_keys file to ensure that is only readable by the git user within the container. Otherwise SSH won't use the file.
# If you are using Docker, substitute podman with docker
podman exec -it gitlab /bin/sh -c \
"chmod 600 /gitlab-data/ssh/authorized_keys; chown git:git /gitlab-data/ssh/authorized_keys"
Reload the SSH Service
sudo systemctl reload sshd
You're good to go!
Configuration
By default the scripts assumes that the GitLab SSH service is accessible at git@localhost port 2222. If your setup is different, you can override this by creating a file named gitlab-ssh.conf in /home/git/.config or /etc.
In this file you can define the following environment variables:
GITLAB_HOST=git@localhost
GITLAB_PORT=2222
Uninstall
This will remove all the script files and the SE Linux proxy module.
sudo ./setup.sh remove

How Does it Work
First we would need to have a git user in the host machine. When a user connects via SSH, it should be able to somehow redirect/forward the request as the git user in the container.
GitLab authenticates users based on their SSH keys. This is traditionally done by adding the user's public key into an authorized_keys file. Recently GitLab foregoes this file and uses a database instead. To do this GitLab uses a feature in the Open SSH server called AuthorizedKeysCommand which allows it to execute a program to query its keys database and return the relevant key data.
In the host, we do the same thing. We configure the AuthorizedKeysCommand to call our gitlab-keys-check script when someone tries to login as git. This script runs ssh to the container (via port 2222) and execute the actual tool, gitlab-shell-authorized-keys-check. It would return an authorized_keys entry which looks like this:
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The command option at the beginning forces the SSH server to execute /opt/.../bin/gitlab-shell when the key is used to login. This command does not exist in the host machine. Therefore before we return it we must replace this with /usr/local/bin/gitlab-shell-proxy.
command="/usr/local/bin/gitlab-shell-proxy key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The SSH server will see the updated command and execute gitlab-shell-proxy. This script will ssh to the container and execute the actual binary /opt/.../bin/gitlab-shell, effectively creating a proxy to the GitLab container.
For this to work, the git user in the host would need to have an authorized_key in the GitLab container. Therefore copy its public key file into /gitlab-data/ssh/authorized_keys in the container. We also need to adjust the file permission as Open SSH is quite strict about it.
There is one complication. In machines with SE Linux enabled, we are unable to execute ssh from the AuthorizedKeysCommand. To workaround this, we would need to install a custom policy file gitlab-ssh.te to enable this.
References
About
SSH Proxy for Dockerized GitLab Container
Topics
gitlabgitlab-cegitlab-dockerssh-config
Resources
Readme
Activity
Stars
27 stars
Watchers
1 watching
Forks
8 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Repository files navigation
GitLab SSH Proxy
One if the issue with running a GitLab instance in a container is to expose the GitLab SSH in the host machine without conflicting with the existing SSH port (22) on the host.
What usually happens:
git://git@hostname:2222/username/project.git 
We want them to look like this instead:
git://git@hostname/username/project.git 
There are several alternatives online (see References below). But I would like to avoid:
  • Hardcoding the UID and GID of any account in the host machine
  • Running additional services/daemon in the host machine
  • Providing Docker access to a special account in the host machine
  • Duplicating GitLab's authorized_keys files in the host machine
For a detailed explanation, see the How Does It Work section below.
Step by Step
Build and install.
sudo ./setup.sh install

It will do the following things:
  1. Copy the follwoing scripts to /usr/local/bin
  2. Build and install an SE Linux policy module: gitlab-ssh.te to allow scripts executed from the SSH daemon to run the ssh binary.
  3. Copy 99-gitlab-proxy.conf to /etc/ssh/sshd_config.d/
Create the git user on the host
sudo useradd -m git
Create a new SSH key-pair
sudo su - git -c "ssh-keygen -t ed25519"
Assuming the GitLab container was started with --volume /srv/gitlab/ssh:/gitlab-data/ssh:Z, copy and rename the public key to /srv/gitlab/ssh/authorized_keys.
sudo cp /home/git/.ssh/id_ed25519.pub /srv/gitlab/ssh/authorized_keys
Fix the permission/ownership of the authorized_keys file to ensure that is only readable by the git user within the container. Otherwise SSH won't use the file.
# If you are using Docker, substitute podman with docker
podman exec -it gitlab /bin/sh -c \
"chmod 600 /gitlab-data/ssh/authorized_keys; chown git:git /gitlab-data/ssh/authorized_keys"
Reload the SSH Service
sudo systemctl reload sshd
You're good to go!
Configuration
By default the scripts assumes that the GitLab SSH service is accessible at git@localhost port 2222. If your setup is different, you can override this by creating a file named gitlab-ssh.conf in /home/git/.config or /etc.
In this file you can define the following environment variables:
GITLAB_HOST=git@localhost
GITLAB_PORT=2222
Uninstall
This will remove all the script files and the SE Linux proxy module.
sudo ./setup.sh remove

How Does it Work
First we would need to have a git user in the host machine. When a user connects via SSH, it should be able to somehow redirect/forward the request as the git user in the container.
GitLab authenticates users based on their SSH keys. This is traditionally done by adding the user's public key into an authorized_keys file. Recently GitLab foregoes this file and uses a database instead. To do this GitLab uses a feature in the Open SSH server called AuthorizedKeysCommand which allows it to execute a program to query its keys database and return the relevant key data.
In the host, we do the same thing. We configure the AuthorizedKeysCommand to call our gitlab-keys-check script when someone tries to login as git. This script runs ssh to the container (via port 2222) and execute the actual tool, gitlab-shell-authorized-keys-check. It would return an authorized_keys entry which looks like this:
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The command option at the beginning forces the SSH server to execute /opt/.../bin/gitlab-shell when the key is used to login. This command does not exist in the host machine. Therefore before we return it we must replace this with /usr/local/bin/gitlab-shell-proxy.
command="/usr/local/bin/gitlab-shell-proxy key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The SSH server will see the updated command and execute gitlab-shell-proxy. This script will ssh to the container and execute the actual binary /opt/.../bin/gitlab-shell, effectively creating a proxy to the GitLab container.
For this to work, the git user in the host would need to have an authorized_key in the GitLab container. Therefore copy its public key file into /gitlab-data/ssh/authorized_keys in the container. We also need to adjust the file permission as Open SSH is quite strict about it.
There is one complication. In machines with SE Linux enabled, we are unable to execute ssh from the AuthorizedKeysCommand. To workaround this, we would need to install a custom policy file gitlab-ssh.te to enable this.
References
About
SSH Proxy for Dockerized GitLab Container
Topics
gitlabgitlab-cegitlab-dockerssh-config
Resources
Readme
Activity
Stars
27 stars
Watchers
1 watching
Forks
8 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
BranchesTags
Repository files navigation
GitLab SSH Proxy
One if the issue with running a GitLab instance in a container is to expose the GitLab SSH in the host machine without conflicting with the existing SSH port (22) on the host.
What usually happens:
git://git@hostname:2222/username/project.git 
We want them to look like this instead:
git://git@hostname/username/project.git 
There are several alternatives online (see References below). But I would like to avoid:
  • Hardcoding the UID and GID of any account in the host machine
  • Running additional services/daemon in the host machine
  • Providing Docker access to a special account in the host machine
  • Duplicating GitLab's authorized_keys files in the host machine
For a detailed explanation, see the How Does It Work section below.
Step by Step
Build and install.
sudo ./setup.sh install

It will do the following things:
  1. Copy the follwoing scripts to /usr/local/bin
  2. Build and install an SE Linux policy module: gitlab-ssh.te to allow scripts executed from the SSH daemon to run the ssh binary.
  3. Copy 99-gitlab-proxy.conf to /etc/ssh/sshd_config.d/
Create the git user on the host
sudo useradd -m git
Create a new SSH key-pair
sudo su - git -c "ssh-keygen -t ed25519"
Assuming the GitLab container was started with --volume /srv/gitlab/ssh:/gitlab-data/ssh:Z, copy and rename the public key to /srv/gitlab/ssh/authorized_keys.
sudo cp /home/git/.ssh/id_ed25519.pub /srv/gitlab/ssh/authorized_keys
Fix the permission/ownership of the authorized_keys file to ensure that is only readable by the git user within the container. Otherwise SSH won't use the file.
# If you are using Docker, substitute podman with docker
podman exec -it gitlab /bin/sh -c \
"chmod 600 /gitlab-data/ssh/authorized_keys; chown git:git /gitlab-data/ssh/authorized_keys"
Reload the SSH Service
sudo systemctl reload sshd
You're good to go!
Configuration
By default the scripts assumes that the GitLab SSH service is accessible at git@localhost port 2222. If your setup is different, you can override this by creating a file named gitlab-ssh.conf in /home/git/.config or /etc.
In this file you can define the following environment variables:
GITLAB_HOST=git@localhost
GITLAB_PORT=2222
Uninstall
This will remove all the script files and the SE Linux proxy module.
sudo ./setup.sh remove

How Does it Work
First we would need to have a git user in the host machine. When a user connects via SSH, it should be able to somehow redirect/forward the request as the git user in the container.
GitLab authenticates users based on their SSH keys. This is traditionally done by adding the user's public key into an authorized_keys file. Recently GitLab foregoes this file and uses a database instead. To do this GitLab uses a feature in the Open SSH server called AuthorizedKeysCommand which allows it to execute a program to query its keys database and return the relevant key data.
In the host, we do the same thing. We configure the AuthorizedKeysCommand to call our gitlab-keys-check script when someone tries to login as git. This script runs ssh to the container (via port 2222) and execute the actual tool, gitlab-shell-authorized-keys-check. It would return an authorized_keys entry which looks like this:
command="/opt/gitlab/embedded/service/gitlab-shell/bin/gitlab-shell key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The command option at the beginning forces the SSH server to execute /opt/.../bin/gitlab-shell when the key is used to login. This command does not exist in the host machine. Therefore before we return it we must replace this with /usr/local/bin/gitlab-shell-proxy.
command="/usr/local/bin/gitlab-shell-proxy key-1",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDJEO... username@hostname

The SSH server will see the updated command and execute gitlab-shell-proxy. This script will ssh to the container and execute the actual binary /opt/.../bin/gitlab-shell, effectively creating a proxy to the GitLab container.
For this to work, the git user in the host would need to have an authorized_key in the GitLab container. Therefore copy its public key file into /gitlab-data/ssh/authorized_keys in the container. We also need to adjust the file permission as Open SSH is quite strict about it.
There is one complication. In machines with SE Linux enabled, we are unable to execute ssh from the AuthorizedKeysCommand. To workaround this, we would need to install a custom policy file gitlab-ssh.te to enable this.
References
About
SSH Proxy for Dockerized GitLab Container
Topics
gitlabgitlab-cegitlab-dockerssh-config
Resources
Readme
Activity
Stars
27 stars
Watchers
1 watching
Forks
8 forks
Report repository
Releases
Packages
Contributors
Languages