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 HTTPSPersonal Access Token 等不应继续把账户密码当作 Git 凭据Git over SSHSSH 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 还是 SSHHTTPS 场景检查凭据管理器中是否仍保存账户密码按组织政策创建最小权限、有限有效期的 Token自动化任务不要复用个人长期 Token若改用 SSH单独检查 SSH Key 与主机指纹。不要通过关闭 MFA 来“修复”命令行认证。真正的问题通常是 Git 凭据类型没有随账户安全策略升级。Email OTP 不是验证器兼容证明Email OTP 是平台通过邮件发送的代码不是 TOTP 共享密钥也不能导入验证器。看到 GitLab 登录页面出现六位码输入框仍需判断它要求的是邮箱代码、验证器代码还是恢复码。配置前先做一次低风险验收GitLab.com、自托管实例、密码登录和 SSO 环境的设置可能不同。准备使用「二次验证码 Free2FA」时先选择非唯一管理员账号记录账户类型、平台入口、连续两个验证码周期、重新登录结果和恢复码状态。确认整个流程可用后再处理高权限账号。团队迁移检查表管理员是否已确认强制 MFA 范围与宽限期成员是否保存恢复码Git over HTTPS 是否改用合适 TokenCI/CD 是否使用项目级或部署凭据而非个人密码离职人员的 Token、SSH Key 和会话是否撤销紧急恢复责任人是否明确。GitLab MFA 的正确落点是把“网页第二因素”和“开发凭据治理”一起处理。下一步可直接盘点仓库远程地址与 CI 变量找出仍依赖个人密码或长期 Token 的位置。