SSH access to your GitLab server – Aus dem Hobbykeller…

The most common way of pulling and pushing code between your development machine and your GitLab server is by means of SSH keys. Most tutorials on GitLab tell you something along the following lines:

cat the public SSH key of your workstation, which is normally located at ~/.ssh/id_rsa.pub
Log into your GitLab server, click on your avatar (upper right corner), click Preferences in the drop down menu that appears
The navigation bar of the GitLab GUI on the RHS adapts to show User Settings, click on SSH keys.
Copy the output from the cat command in step 1 and paste it into the key box.

Most of these tutorials demonstrate connecting to GitLab (either the SaaS version or your own server) from a freshly installed Ubuntu Desktop virtual machine. Your real life situation is different though:

Unlike a virgin default Ubuntu Desktop Virtual Box machine or similar, your real life workstation already has an SSH key pair. The question therefore is: Do I need to create another pair that is dedicated to connect to GitLab or can/should I use the existing key pair.
In my case, GitLab runs in a Docker stack on a (physically) different host machine. To gain access to the host machine’s OS, I can ssh into the host machine through the standard port 22. This however means, that the GitLab Docker stack which has another independent SSH daemon for pulling/pushing code cannot use the same default port 22.

Getting a public SSH key

Allowed Ciphers and Standards

Generally speaking any SSH key pair is acceptable for GitLab as long as it is either RSA or ED25519. GitLab recommends the ED25519 standard pretending that it is more secure than RSA.

As I already have a standard RSA key pair in place, I will stick with that RSA mechnanism.

Should I build a dedicated pair for GitLab?

As most GitLab tutorials start with a ‘naked’ Ubuntu machine or similar, most of these machines don’t have any SSH key pair at all, and so by default, a pair must be created for GitLab.

If you already have a key pair which you use for logging into remote servers, you can keep things simple by not creating a second pair on top of the existing one: no need to backup two key pairs, remember two passwords, tell your workstation when to use which key etc. Just stick with your existing key pair.

Port redirection

If you run GitLab from a docker stack, port forwarding is easy: Just edit the ports section of your docker-compose.yml file as shown below:

version: '3.6'
services:
  web:
    image: 'gitlab/gitlab-ee:latest'
    restart: always
    hostname: 'gitlab.example.com'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'http:/internal_router.box'
    ports:
      - '1080:80'
      - '1443:443'
      - '1022:22'
    volumes:
      - '/srv/gitlab/config:/etc/gitlab'
      - '/srv/gitlab/logs:/var/log/gitlab'
      - '/srv/gitlab/data:/var/opt/gitlab'
    shm_size: '8g'

version: '3.6'

services:

web:

image: 'gitlab/gitlab-ee:latest'

restart: always

hostname: 'gitlab.example.com'

environment:

GITLAB_OMNIBUS_CONFIG: |

external_url 'http:/internal_router.box'

ports:

- '1080:80'

- '1443:443'

- '1022:22'

volumes:

- '/srv/gitlab/config:/etc/gitlab'

- '/srv/gitlab/logs:/var/log/gitlab'

- '/srv/gitlab/data:/var/opt/gitlab'

shm_size: '8g'

In my case, any incoming traffic on port 1022 is redirected to port 22 of the GitLab Docker container.

Tricky question: Do we have to open port 1022 explicitly (e.g. by means of iptables or ufw) or will Docker take care of opening port 1022 for listening automatically on the host machine?
The answer (at least in my case) is that port 1022 is opened automatically by Docker, which we can check with the following command on the host: netstat -an | grep 1022 | grep -i listen
The response confirming that the host is actually listening on that port should look like:

tcp        0      0 0.0.0.0:1022            0.0.0.0:*               LISTEN     
tcp6       0      0 :::1022                 :::*                    LISTEN

If you want to allow access to your GitLab from outside and sit behind a NAT wall (vulgo: your router), you also have to instruct your router to forward incoming traffic on port 1022 to port 1022 of your GitLab host machine.

Final Note on ‘alternatives’ for SSH port forwarding: There has been some discussion if port forwarding can also be achieved by Traefik or Nginx Proxy Manager. As these instruments are intended to forward HTTP traffic, it is not possible to forward the SSH port. You can set up NPM to redirect external https (not ssh!) enquiries to your GitLab domain to be forwarded to port 1080 of your host machine where GitLab will happily listen to redirect any HTTP traffic to the internal port 80 of its container.

Checking if the key is working

After having pasted your public SSH key into GitLab’s GUI (see step 4 above), you can test if your SSH key is working properly. On your workstation, issue the following command:

ilek@i7:~$ ssh -T git@yourgitserverurl.com -p 1022
Welcome to GitLab, @ilek!

1 2	ilek@i7:~$ ssh -T git@yourgitserverurl.com -p 1022 Welcome to GitLab, @ilek!

Although you have a different user name (ilek), you must always connect to git@<GitLab-URL>, not to ilek@<GitLab URL>. (This is just like in gitolite where all connections have to log into a restricted SSH environment through a central user. Authorization and authentication are then performed on the basis of the SSH key presented.)