GitLab 2026 MFA 变化：OTP、WebAuthn、Email OTP 与 Token 的边界
GitLab 的 MFA 变化不只影响网页登录。GitLab 官方文档说明，从 2026 年 4 月起，GitLab.com 对用户名和密码认证的登录或 API 请求要求 MFA；未配置其他方式时，Email OTP 可作为强制第二因素。对开发者而言，更需要检查 Git over HTTPS、API 和自动化是否仍在使用账户密码。
先区分四类凭据
| 场景 | 常见凭据 | MFA 开启后的关注点 |
|---|---|---|
| 网页登录 | 密码 + OTP/WebAuthn/Email OTP | 第二因素和恢复码是否可用 |
| Git over HTTPS | Personal Access Token 等 | 不应继续把账户密码当作 Git 凭据 |
| Git over SSH | SSH Key | 与网页 TOTP 是不同认证链路 |
| API / 自动化 | PAT、Project/Group Access Token、Deploy Token 等 | 权限、有效期、轮换与密钥泄露风险 |
网页端填过一次六位码，并不意味着命令行会自动继承 MFA 状态。
GitLab 当前列出的主要方式
官方文档列出 OTP authenticator、WebAuthn 设备和恢复码。GitLab.com 还在特定强制场景中使用 Email OTP。它们的定位不同：
- OTP authenticator：使用验证器产生一次性密码；
- WebAuthn：可使用支持的安全密钥或设备凭据，抗钓鱼能力更强；
- Email OTP：通过邮箱接收第二因素，安全性也依赖邮箱本身；
- 恢复码：主因素不可用时的紧急入口，应独立保存。
如果组织管理员强制 2FA，成员还要关注宽限期、账户恢复与离职交接策略。
开启 2FA 后 Git 为什么失败
典型报错发生在 HTTPS 远程地址仍缓存旧密码时。排查顺序可以是：
- 查看远程地址：
git remote -v 确认使用 HTTPS 还是 SSH；
HTTPS 场景检查凭据管理器中是否仍保存账户密码；
按组织政策创建最小权限、有限有效期的 Token；
自动化任务不要复用个人长期 Token；
若改用 SSH，单独检查 SSH Key 与主机指纹。
不要通过关闭 MFA 来“修复”命令行认证。真正的问题通常是 Git 凭据类型没有随账户安全策略升级。
Email OTP 不是验证器兼容证明
Email OTP 是平台通过邮件发送的代码，不是 TOTP 共享密钥，也不能导入验证器。看到 GitLab 登录页面出现六位码输入框，仍需判断它要求的是邮箱代码、验证器代码还是恢复码。
配置前先做一次低风险验收
GitLab.com、自托管实例、密码登录和 SSO 环境的设置可能不同。准备使用「二次验证码 Free2FA」时，先选择非唯一管理员账号，记录账户类型、平台入口、连续两个验证码周期、重新登录结果和恢复码状态。确认整个流程可用后，再处理高权限账号。
团队迁移检查表
- 管理员是否已确认强制 MFA 范围与宽限期；
- 成员是否保存恢复码；
- Git over HTTPS 是否改用合适 Token；
- CI/CD 是否使用项目级或部署凭据，而非个人密码；
- 离职人员的 Token、SSH Key 和会话是否撤销；
- 紧急恢复责任人是否明确。
GitLab MFA 的正确落点，是把“网页第二因素”和“开发凭据治理”一起处理。下一步可直接盘点仓库远程地址与 CI 变量，找出仍依赖个人密码或长期 Token 的位置。