Add option to recover 2FA via SSH

Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/3765

Allow users to recover their own account if they lose their 2FA device or recovery codes.

To request new 2FA recovery codes, when you still have access to the SSH key associated with your account:

ssh git@gitlab.com 2fa_recovery_codes

#63 (closed) # Questions/Concerns

• Does this look secure? I think it is but we need to make sure no one can spoof a username or something and disable two factor.

Todo

• Working code
• Tests
• GitLab merge requests (including documentation)

cc/ @stanhu @DouweM @JobV What do you think about planning this for a release in the near future? It needs to be a bit more robust, but it's not too complex.

Related: https://gitlab.com/gitlab-com/support/issues/100

@dblessing I think that's a good idea, this is a really helpful feature.

@dblessing This is great, I am waiting for this to reach gitlab.com

Milestone changed to %8.11

Reassigned to @dblessing

Added 1 commit:

• 25952379 - Add option to recover 2FA via SSH

Added 1 commit:

• 8aa967ba - Add option to recover 2FA via SSH

Changed title: WIP: PoC SSH 2FA recovery → WIP: Add option to recover 2FA via SSH

Unmarked this merge request as a Work In Progress

Added 1 commit:

• 6158b541 - Add option to recover 2FA via SSH

Marked the task Tests as completed

The more I think about it, I think we should only do the recovery_codes command. Consider if the admin has 2FA enforced. Disabling two factor here would probably lock the person out of the account anyway. Recovery codes should work in all cases and would arguably be more secure since it won't leave the account without 2FA at any point.

Added 1 commit:

• ac79390d - Add option to recover 2FA via SSH

Added 1 commit:

• 11846fce - Add option to recover 2FA via SSH

This is a very interesting feature. What happens if we added 2FA support over SSH? I assume we'd want to use the same key used in the password login. Does this MR make sense in that context?

/cc: @jacobvosmaer-gitlab

@dblessing I agree with only recovery codes.

@stanhu what would 2FA over SSH mean? I know you can have PAM plugins on the server but those would make no sense for GitLab. They usually work by associating a system user with e.g. an instance of the Google Authenticator app. In GitLab's case the user would have to be 'git', but we do not want to link that to just one instance of Google Authenticator.

So I think that rules out 2FA for SSH via PAM. @stanhu were you thinking of something else?

@jacobvosmaer-gitlab Thanks for your input. I agree about SSH 2FA. In my mind, if the user is using a passphrase with their private key they essentially have 2FA. Plus, a private key is generally harder to lose/crack than a user's web password.

what would 2FA over SSH mean? I know you can have PAM plugins on the server but those would make no sense for GitLab. They usually work by associating a system user with e.g. an instance of the Google Authenticator app. In GitLab's case the user would have to be 'git', but we do not want to link that to just one instance of Google Authenticator.

@jacobvosmaer-gitlab I think that's what I was thinking. Yubikey has support for associating different users with a PAM module: https://developers.yubico.com/yubico-pam/Yubikey_and_SSH_via_PAM.html As you mention, I'm not sure if this works since we use only one user, but I could imagine a scenario where we make this work somehow.

In my mind, if the user is using a passphrase with their private key they essentially have 2FA. Plus, a private key is generally harder to lose/crack than a user's web password.

Many people don't use a passphrase with their SSH private key, so my concern is that this would be a mechanism to bypass 2FA if you somehow got control of someone's computer.