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:<\/p>\n\n\n\n
cat<\/code> the public SSH key of your workstation, which is normally located at ~\/.ssh\/id_rsa.pub<\/code><\/li>\n\n\n\n- Log into your GitLab server, click on your avatar (upper right corner), click Preferences<\/strong> in the drop down menu that appears<\/li>\n\n\n\n
- The navigation bar of the GitLab GUI on the RHS adapts to show User Settings<\/strong>, click on SSH keys<\/strong>.<\/li>\n\n\n\n
- Copy the output from the cat command in step 1 and paste it into the key box.<\/li>\n<\/ol>\n\n\n\n
Most of these tutorials demonstrate connecting to GitLab (either the SaaS version or your own server) from a freshly installed<\/strong> Ubuntu Desktop virtual machine<\/strong>. Your real life situation is different though:<\/p>\n\n\n\n\n- Unlike a virgin default Ubuntu Desktop Virtual Box machine or similar, your real life workstation already has an SSH key pair<\/strong>. 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.<\/li>\n\n\n\n
- 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.<\/strong><\/li>\n<\/ul>\n\n\n\n
Getting a public SSH key<\/h2>\n\n\n\nAllowed Ciphers and Standards<\/h3>\n\n\n\n
Generally speaking any SSH key pair is acceptable for GitLab as long as it is either RSA<\/strong> or ED25519<\/strong>. GitLab recommends the ED25519 standard pretending that it is more secure than RSA.<\/p>\n\n\n\nAs I already have a standard RSA key pair in place, I will stick with that RSA mechnanism.<\/p>\n\n\n\n
Should I build a dedicated pair for GitLab?<\/h3>\n\n\n\n
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.<\/p>\n\n\n\n
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<\/strong>.<\/p>\n\n\n\nPort redirection<\/h3>\n\n\n\n
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:<\/p>\n\n\n\n
version: '3.6'\nservices:\n web:\n image: 'gitlab\/gitlab-ee:latest'\n restart: always\n hostname: 'gitlab.example.com'\n environment:\n GITLAB_OMNIBUS_CONFIG: |\n external_url 'http:\/internal_router.box'\n ports:\n - '1080:80'\n - '1443:443'\n - '1022:22'\n volumes:\n - '\/srv\/gitlab\/config:\/etc\/gitlab'\n - '\/srv\/gitlab\/logs:\/var\/log\/gitlab'\n - '\/srv\/gitlab\/data:\/var\/opt\/gitlab'\n shm_size: '8g'\n<\/pre><\/div>\n\n\n\nIn my case, any incoming traffic on port 1022 is redirected to port 22 of the GitLab Docker container.<\/p>\n\n\n\n
Tricky question: Do we have to open port 1022 explicitly (e.g. by means of iptables<\/code> or ufw<\/code>) 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<\/code>
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 <\/code>