TechPrufer
Get started
GitLab
GitLab logoGitLab · Feature trail

SSH Key Management and Authentication

14 posts · Feb 2016 – Feb 2026

What this trail covers

GitLab has focused on simplifying user authentication and access management. This includes enhancing SSH key usage by providing screencasts to demonstrate ease of use and introducing an alternate `git+ssh` port (443) on GitLab.com to circumvent network restrictions. This post details a coordinated effort with Yubico to integrate hardware security keys (YubiKeys) for two-factor authentication, enhancing security beyond SMS or push notifications by leveraging the U2F protocol for phishing and Man-in-the-Middle attack resistance. Passkeys are now available for passwordless sign-in or as a phishing-resistant two-factor authentication (2FA) method, utilizing WebAuthn technology and public-key cryptography. They work across desktop browsers, mobile devices, and FIDO2 hardware security keys.

All GitLab trails
  1. Passkeys now available for passwordless sign-in and 2FA on GitLabIntroduces passkeys as a new authentication method for passwordless sign-in and as a phishing-resistant 2FA option. Passkeys leverage WebAuthn and public-key cryptography, with private keys stored on the device and public keys on GitLab. They are supported across various browsers, mobile devices, and hardware security keys. This aligns with the CISA Secure by Design Pledge to increase MFA usage.
  2. Secure and safe login and commits with GitLab + YubicoThis post details the integration of YubiKeys for multi-factor authentication (MFA) with GitLab, leveraging FIDO Universal 2nd Factor (U2F) and FIDO2/WebAuthn protocols. It provides step-by-step instructions for setting up YubiKeys for login and for configuring GPG keys on YubiKeys to enable verified commits. The technical details include the cryptographic challenge-response mechanism for authentication and the process of generating and exporting GPG keys for GitLab integration.
  3. FAQ: The RegreSSHion vulnerability and GitLabThis post details the RegreSSHion vulnerability (CVE-2024-6387), a remote unauthenticated code execution flaw in OpenSSH server. It explains how GitLab.com and GitLab Dedicated are not impacted due to the use of `gitlab-sshd`, which is not vulnerable. For self-managed customers, it advises applying OS patches or configuring `gitlab-sshd` for mitigation, and emphasizes general security best practices like regular patching and MFA. It also notes the low real-world success rate of the exploit.
  4. GitLab account security: Verify your information for enhanced protectionIntroduces a new security measure requiring email verification for users without 2FA, especially during high-risk logins. Allows a one-time email update for users to confirm a valid email address. This adds an extra layer of protection against unauthorized access and credential stuffing attacks.
  5. Why we implemented our own SSHD solutionThis post details the implementation of a custom SSH daemon (`gitlab-sshd`) to replace the previous OpenSSH Server and GitLab Shell setup. Key technical contributions include: enabling PROXY protocol support for Group IP address restriction, implementing graceful shutdown for Kubernetes compatibility, adding Prometheus metrics and profiling, reducing resource usage and attack surface, and simplifying the overall architecture. The post also highlights challenges encountered, such as memory consumption issues, limitations in the `golang.org/x/crypto` library (leading to a fork), and the need to re-implement OpenSSH options. The incremental rollout strategy is emphasized as a key lesson learned.
  7. How to protect GitLab-connected SSH key with YubikeyThis post details the integration of FIDO/U2F hardware security keys (YubiKeys) for SSH key authentication, enabling two-factor authentication for Git operations via SSH. It covers generating `ecdsa-sk` and `ed25519-sk` key types, updating OpenSSH to version 8.2+, and adding the public key to GitLab's SSH settings. It also highlights the use of resident keys for easier sharing across devices.
  8. Notice for GitKraken users with GitLabThis post details a vulnerability in GitKraken's key generation (versions 7.6.0 to 8.0.0) that could produce weak or duplicate SSH keys, potentially allowing unauthorized access to GitLab accounts and repositories. GitLab has responded by emailing affected users, blocking known weak keys on GitLab.com, and providing instructions for self-managed customers to revoke and regenerate their SSH keys, and for all users to update GitKraken.
  9. GitLab instance: security best practicesThis post details security best practices for self-managed GitLab instances, focusing on hardening configurations. It covers strong password management for root and users, enabling Let's Encrypt for SSL/TLS, securing SSH access with support for RSA (2048-bit+) and ED25519 keys, and recommending passwordless SSH. It also outlines sign-up restrictions (disabling open sign-up, requiring email confirmation, domain whitelisting, minimum password length of 12), sign-in restrictions (requiring 2FA, disabling password authentication for Git over HTTP(S)), and visibility/privacy settings (defaulting projects to private). Additionally, it addresses network performance and stability by recommending user and IP rate limits, restricting webhook outbound requests to public services, and enabling protected paths rate limits.
  10. Zero Trust at GitLab: Implementation challenges (and a few solutions)This post details challenges in implementing Zero Trust Networking (ZTN), specifically around user identity and device management. It highlights the difficulties in provisioning users quickly in a growing company and the unique challenge of managing devices in a BYOD-rooted culture with a standardized Linux/Mac infrastructure. The post also discusses the complexities of managing sprawling infrastructure with SSH access and the lack of two-factor authentication enforcement for SSH. Wins include the implementation of Okta for user identity management, which significantly reduced provisioning times, and the use of Chef/Knife for infrastructure changes. The team is exploring Okta's Advanced Server Access (ASA) to integrate SSH accounts and enforce multi-factor authentication, GeoIP, and other security measures for server administration.
  11. 6 Lessons we learned when debugging a scaling problem on GitLab.comThis post details debugging a scaling problem on GitLab.com related to intermittent SSH connection errors during Git pulls. The investigation involved packet captures, log analysis (HAProxy and SSHD), and identifying a pattern of errors clustering around the top of the minute, attributed to scheduled jobs hitting the `MaxStartups` limit on SSHD. The solution involved increasing the `MaxStartups` value and exploring HAProxy's rate-limiting capabilities to gracefully handle connection spikes.
  12. Repositories held for ransom by using valid credentialsThis post details a security incident where repositories were compromised due to the use of plaintext passwords. It emphasizes the importance of strong, unique passwords, password managers, and enabling two-factor authentication. Mitigation steps using Git commands to restore repositories are provided, along with an analysis of the attacker's methods and the scope of the incident. The post also highlights the use of SSH keys as a stronger authentication method and the enforcement of 2FA for group members.
  13. This is what happens if you lose access to your 2FA GitLab.com accountThis post details a new, more secure process for resetting two-factor authentication (2FA) for GitLab.com accounts. The process moves away from relying on government-issued IDs to a risk-based approach involving classification of data access risk and a series of authentication challenges. The challenges are scored, and a minimum score is required for 2FA reset, depending on the account's risk classification. This process was developed collaboratively between the Support and Security teams.
  14. Axosoft launches GitKraken integration with GitLabThis post details the integration of GitKraken with GitLab, enabling users to manage SSH keys, initialize new repositories, clone existing repositories, and view remote avatars directly within the GitKraken GUI. This enhances the user experience for managing GitLab repositories through a third-party client.
  15. Security Webcast with YubicoThis post details the integration of YubiKeys for two-factor authentication with GitLab, highlighting the security benefits over SMS-based 2FA, including protection against phishing and man-in-the-middle attacks through the U2F protocol. It also outlines additional GitLab security capabilities like access control, workflow management, and audit trails, and provides nine security best practices for Git users.
  16. Support for Universal 2nd Factor AuthenticationThis post announces the addition of FIDO Universal 2nd Factor (U2F) protocol support for user authentication, integrating with YubiKey hardware security devices. It highlights U2F's use of public key cryptography and phishing prevention capabilities, enhancing account security for users logging in from multiple devices. The post also reminds users that GitLab has supported two-factor authentication since version 7.11 and directs them to documentation for enabling U2F.
  17. GitLab.com now supports an alternate git+ssh portThis post details the implementation of an alternate `git+ssh` port (443) on GitLab.com to circumvent network firewalls that block the default SSH port (22). It explains the problem of network restrictions, the solution of using port 443, and the specific infrastructure setup involving HAProxy nodes and a separate Azure load balancer to forward TCP connections from port 443 to port 22. Instructions are provided on how to update the `~/.ssh/config` file to use this alternate connection.