Are SSH keys in GitLab real alternatives for HTTPS and simple password procedures?

Thales: Schlüsselverwaltung nach Umzug in die Cloud ist essenziell

By Christine Schönig, Regional Director Security Engineering CER, Office of the CTO, at Check Point Software Technologies GmbH

Again and again there are problems, as recently with Cisco Umbrella, with poorly protected SSH keys.

Christine Schönig, Regional Director Security Engineering CER, Office of the CTO at Check Point

In order to be able to transmit data encrypted and authenticated – and thus secure – over a network to the server of a website, HTTPS is usually used. In the case of the transfer of Git data to GitLab, this communication protocol is used. The problem: HTTPS is not very user-friendly when it comes to sending Git commands to GitLab. Because here, users must first answer a username and password request for each individual action – for each transfer from the local Git to the GitLab repository. Every time again, for every little change in the local repository. A time-consuming – but above all actually unnecessary – workload.

GitLab users have a much more user-friendly option for their data transfers: SSH keys. This variant is also more secure than HTTPS. Because username-password combinations are no longer a real obstacle for cybercriminals today. Social engineering, phishing and spear phishing attacks have been greatly perfected by them in recent years. They are now able to manipulate employees of a victim institution relatively easily and thus persuade them to hand over access data. Once you have these in your hand, you can gain undisturbed – and undetected – access to the websites of your victims – including GitLab.

The use of SSH key pairs offers a way out here – as far as you know how to use them correctly. There are two key formats for GitLab to choose from: RSA SSH and ED25519 SSH keys. The advantage: In contrast to the username-password combination, an SSH key pair cannot be captured simply by manipulating the employees. Cybercriminals have a much harder time here. You already have to gain direct access to the victim system and the private SSH keys stored there – and this unnoticed by the IT security of your target. Another advantage: SSH keys can also be secured against unauthorized third-party access via systematic key management.

Central management for SSH keys needed

Key management is used to locate, identify and manage all existing keys. This is often still the case with many companies. They underestimate the need to continuously monitor SSH keys. But this is the only way to ensure that the once generated and locally stored private key is never copied, moved or provided with a backup copy. All this would only lead to an unnecessary increase in security risks.

In addition, old key pairs must be regularly replaced with new ones. On the GitLab administrator side, expiration policies can be set up to ensure that SSH keys are only valid for a certain period of time. If the expiration date is exceeded, the user is forced to replace them with new keys. Automatic management solutions are now also available for this purpose, which can handle the regular creation and deletion of SSH key pairs completely single-handedly. In this way, the user-friendliness of SSH keys can be significantly increased again.


Equipped with effective key management, SSH keys in GitLab are currently the most user-friendly and secure way to transfer data encrypted, authenticated – and thus secured.

Development Outsourcing | Unreal Outsourcing

Ready to see us in action:

More To Explore
Enable registration in settings - general
Have any project in mind?

Contact us: