Let’s learn how to add SSH Key on GitLab. Git is a distributed version control system, indicating that you can operate locally and share or “push” your modifications to other servers.
Before you can push your modifications to a GitLab server, it would be better if you had a safe communication channel for sharing information. Let’s learn how to add SSH Key to your profile on Gitlab.
SSH, or secure shell, is a safe protocol and the most popular way of carefully managing remote servers. Using various encryption technologies, SSH gives:
- A tool for placing a cryptographically secured connection between two parties.
- Authenticating every side to the other.
- Giving commands and output back and forth.
The SSH protocol gives this protection and enables you to authenticate to the GitLab remote server without providing your username or password every time.
Finding an existing SSH key pair
Before creating a new SSH key pair, verify if your computer already has one at the default location by starting a shell or Command Prompt on Microsoft Windows and executing the command below:
Windows Command Prompt:
type %userprofile%\.ssh\id_rsa.pub
Linux / Mac OS:
cat ~/.ssh/id_rsa.pub
If you notice a string beginning with ssh-rsa, it means that you already have an SSH key pair on your computer, and you can jump to the following process to generate your key pairs in the next section. Only copy your key pair to the clipboard.
So, If you don’t see the string and would like to generate an SSH key pair with a custom name, proceed to the next step.
See that the Public SSH key may also be named id_dsa.pub, id_ecdsa.pub, or id_ed25519.pub.
Creating a new SSH key pair
To create a new SSH key pair, apply the following command:
On Windows, Linux, or macOS:
ssh-keygen -t rsa -C "[email protected]" -b 4096
Windows:
Alternatively, on Windows, you can use the PuttyGen
and attend this documentation article to generate an SSH key pair.
Subsequently, you will be prompted to enter a file path to store your SSH key pair.
Suppose you don’t already have an SSH key pair handle the suggested location by pushing enter. Then, doing the proposed path will usually support your SSH client to use the SSH key pair with no additional configuration automatically.
If you already have an SSH key pair with the proposed file path, you will be required to inform a different file path and indicate what host this SSH key pair will be adopted for in your ~/.ssh/config file.
Once you have defined a file path, you will be requested to inform a password to protect your SSH key pair. Although it is not required, it is the most excellent practice to adopt a password for an SSH key pair, and you can jump creating a password by hitting enter.
Notes:
If you need to modify the password of your SSH key pair, you can utilize
ssh-keygen -p
The following action is to copy the public SSH key, as we will require it later.
Gitlab Add SSH Key to Profile
The last step is to attach your public SSH key to Gitlab.
Go to the ‘SSH Keys’ tab in your ‘Profile Settings.’ You can navigate using your Preferences page.
So, select “SSH Keys”
Paste your key from your clipboard in the ‘Key’ section and provide it with a proper ‘Title.’
Utilize an identifiable title like ‘Ubuntu Computer Desktop‘ or ‘Office MacBook Pro.’
Also, If you manually copied your public SSH key, be sure you copied the whole key, beginning with ssh-rsa and finishing with your email.
Optionally you can experiment with your setup by executing ssh -T [email protected]. (changing gitlab.www.bitslovers.com by your GitLab server).
Speed up your connection with Gitlab
After you add SSH Key to Gitlab, another tip will improve your interaction speed with Gitlab.
Establishing a new SSH connection typically demands only a few seconds, but if you’re connecting to a server many times in sequence, the cost starts to add up. If you make a lot of Git pushing and pulling or constantly demand SSH to a dev server, you’ve presumably observed the pain of waiting for SSH to connect so you can get back to doing work.
One of SSH’s lesser-known characteristics is reusing an already-established connection when performing a new SSH session. This means you only have to handle the connection cost once, starting future sessions amazingly fast to begin.
One way to allow this feature is to attach the following to your ~/.ssh/config:
Host gitlab.example.com ControlMaster auto ControlPath ~/.ssh/sockets/%r@%h-%p ControlPersist 600
Here’s a step-by-step analysis of what this performs:
Host gitlab.example.com
This line instructs ssh to apply the following rules to the gitlab.example.com host you SSH to. Of course, if you’d love these rules to apply to all hosts you connect to, you can instead specify something like Host *.
ControlMaster auto
The ControlMaster option is one of SSH’s best-kept puzzles. It tells SSH to reuse the current connection to the server if it already exists. This suggests that if you execute ssh gitlab.example.com, start a new terminal and rerun ssh gitlab.example.com. Your connection will move the two sessions over the same underlying connection. So, the second session begins much more speedily because the SSH handshake has already been performed.
There are some gotchas to be conscious of with connection sharing. First, SSH employs lexical comparison to determine whether to reuse a connection. If the DNS record for gitlab.example.com shifts to references at a different server, you’ll still utilize the current socket to an old one. If you’re in an environment where hosts are regularly rebuilt, this behavior can be notably complicated.
Since you’re tunneling all of your transactions over the same TCP stream, another gotcha is that a bandwidth-constrained transaction such as a file transfer can block lighter-weight functions such as text editing.
ControlPath ~/.ssh/sockets/%r@%h-%p
ControlPath is a term of where to generate the control socket on your filesystem. If you apply the value provided here, make sure to manually mkdir ~/.ssh/sockets. Later, at any moment, you can manually switch the control socket (utilizing plain-old rm), and the following ssh invocation will set a new connection. This is particularly helpful if you’ve recently reopened your computer and your SSH connections haven’t yet figured out that the server closed them (particularly widespread if you’re connecting over a VPN connection).
ControlPersist 600
Without ControlPersist, once the first SSH session you establish is closed, all additional sessions on that connection are disconnected too. This can guide a diversity of unusual behavior: if you exit the first SSH shell while other sessions share the connection, the process will hang. But, on the other hand, if you perform a Ctrl-C, SSH will abruptly stop all of those other sessions.
In opposition, with the ControlPersist set, the master connection will persist open for the defined number of seconds after your latest SSH session on that connection has terminated. This is particularly beneficial for pushing to Gitlab, which happens often but where anyone’s session is brief.
Conclusion
Adding the SSH Key on Gitlab, it’s an easy task, and it takes only a few minutes. And the same time, we don’t need to enter the user and password, and also still secure.
Also, after adding the GitLab SSH Key, we can do more and speed up actions like clone and pushing.
Check also other articles related to DevOps:
How to use the Gitlab CI Variables
Effective Cache Management with Maven Projects on Gitlab.
Pipeline to build Docker in Docker on Gitlab.
How to Autoscaling the Gitlab Runner.
Execute Terraform on Gitlab CI.
