Skip to content

GitLab

Enforce two-factor authentication (FREE SELF)

Two-factor authentication (2FA) provides an additional level of security to your users' GitLab account. When enabled, users are prompted for a code generated by an application in addition to supplying their username and password to sign in.

Read more about two-factor authentication (2FA)

Enforce 2FA for all users

Users on GitLab can enable it without any administrator's intervention. If you want to enforce everyone to set up 2FA, you can choose from two different ways:

  • Enforce on next login.
  • Suggest on next login, but allow a grace period before enforcing.

After the configured grace period has elapsed, users can sign in but cannot leave the 2FA configuration area at /-/profile/two_factor_auth.

To enable 2FA for all users:

  1. On the top bar, select Menu > Admin.
  2. On the left sidebar, select Settings > General (/admin/application_settings/general).
  3. Expand the Sign-in restrictions section, where you can configure both.

If you want 2FA enforcement to take effect during the next sign-in attempt, change the grace period to 0.

Disable 2FA enforcement through rails console

Using the rails console, enforcing 2FA for all user can be disabled. Connect to the rails console and run:

Gitlab::CurrentSettings.update!('require_two_factor_authentication': false)

Enforce 2FA for all users in a group (FREE)

Introduced in GitLab 12.0, 2FA settings for a group are also applied to subgroups.

To enforce 2FA only for certain groups:

  1. Go to the group's Settings > General page.
  2. Expand the Permissions, LFS, 2FA section.
  3. Select the Require all users in this group to set up two-factor authentication option.

You can also specify a grace period in the Time before enforced option.

To change this setting, you must be an administrator or owner of the group.

If you want to enforce 2FA only for certain groups, you can enable it in the group settings and specify a grace period as above. To change this setting you must be administrator or owner of the group.

The following are important notes about 2FA:

  • Projects belonging to a 2FA-enabled group that is shared with a 2FA-disabled group will not require members of the 2FA-disabled group to use 2FA for the project. For example, if project P belongs to 2FA-enabled group A and is shared with 2FA-disabled group B, members of group B can access project P without 2FA. To ensure this scenario doesn't occur, prevent sharing of projects for the 2FA-enabled group.

  • If you add additional members to a project within a group or subgroup that has 2FA enabled, 2FA is not required for those individually added members.

  • If there are multiple 2FA requirements (for example, group + all users, or multiple groups) the shortest grace period is used.

  • It is possible to disallow subgroups from setting up their own 2FA requirements:

    1. Go to the top-level group's Settings > General.
    2. Expand the Permissions, LFS, 2FA section.
    3. Uncheck the Allow subgroups to set up their own two-factor authentication rule field.

    This action causes all subgroups with 2FA requirements to stop requiring that from their members.

Disable 2FA for everyone

WARNING: Disabling 2FA for everyone does not disable the enforce 2FA for all users or enforce 2FA for all users in a group settings. You must also disable any enforced 2FA settings so users aren't asked to set up 2FA again when they next sign in to GitLab.

There may be some special situations where you want to disable 2FA for everyone even when forced 2FA is disabled. There is a Rake task for that:

# Omnibus installations
sudo gitlab-rake gitlab:two_factor:disable_for_all_users

# Installations from source
sudo -u git -H bundle exec rake gitlab:two_factor:disable_for_all_users RAILS_ENV=production

WARNING: This is a permanent and irreversible action. Users have to reactivate 2FA from scratch if they want to use it again.

2FA for Git over SSH operations (PREMIUM)

  • Introduced in GitLab 13.7.
  • Moved from GitLab Free to GitLab Premium in 13.9.
  • It's deployed behind a feature flag, disabled by default.
  • It's disabled on GitLab.com.
  • It's not recommended for production use.
  • To use it in GitLab self-managed instances, ask a GitLab administrator to enable it.

WARNING: This feature might not be available to you. Check the version history note above for details.

Two-factor authentication can be enforced for Git over SSH operations. The one-time password (OTP) verification can be done via a GitLab Shell command:

ssh git@<hostname> 2fa_verify

After the OTP is verified, Git over SSH operations can be used for a session duration of 15 minutes (default) with the associated SSH key.

Security limitation

2FA does not protect users with compromised private SSH keys.

Once an OTP is verified, anyone can run Git over SSH with that private SSH key for the configured session duration.

Enable or disable 2FA for Git operations

2FA for Git operations is under development and not ready for production use. It is deployed behind a feature flag that is disabled by default. GitLab administrators with access to the GitLab Rails console can enable it.

To enable it:

Feature.enable(:two_factor_for_cli)

To disable it:

Feature.disable(:two_factor_for_cli)

The feature flag affects these features: