如何为 GitHub、GitLab 和开发者账户开启 2FA
为 GitHub、GitLab 及其他开发者账户启用双因素认证的实用指南，涵盖身份验证器应用、通行密钥、SSH 密钥和令牌。
为什么开发者账户是首要攻击目标
对攻击者而言，你的 GitHub 或 GitLab 账户远比普通邮箱登录更有价值。它可能拥有私有仓库的推送权限、部署密钥、软件包发布权限，以及直通生产基础设施的途径。账户一旦被攻破，攻击者便继承你的全部权限。
这就是为什么单个泄露的密码可能造成如此严重的损害。私有仓库中可能包含配置文件、API 密钥和数据库凭据。CI 流水线通常携带可创建资源或向构建中注入恶意代码的云令牌。攻击者曾利用窃取的维护者账户向下游用户推送带后门的更新。一次成功的入侵，影响范围远超你的个人资料：所有依赖你代码的项目都会暴露在风险之中。
开发者账户还面临独特的攻击面。代码托管平台上的仓库名称和贡献者信息是公开的，攻击者可以据此判断你的价值，并定制钓鱼邮件——例如伪装成“CI 失败通知”或“安全警报”，诱导你点击虚假登录页面。这类针对开发者的定向钓鱼，比普通的大规模垃圾邮件更难识别。
业界深知这一点。GitHub 已要求许多活跃贡献者启用双因素认证（2FA），GitLab 及其他平台也强烈建议启用。主动启用让你走在行业前列，而非受制于强制要求——强制启用往往发生在平台检测到异常时，或在你最不方便的时候弹出限期提示。
最后，开发者安全很少只是个人事务。雇主的源代码以及你维护的开源项目都依赖于你的凭据。开启 2FA，一步即可保护同事、用户和你自己的声誉。
选择你的第二重验证因素
身份验证器应用（TOTP）
Google Authenticator、Authy 或 1Password 等应用会每 30 秒在手机上生成一个六位数字代码。它们可以离线工作，分文不花，而且比短信难截获得多。对大多数开发者来说，这是最合理的基准选择。
设置时用手机扫描网站显示的二维码即可。常见错误：换手机前忘记转移应用。Authy 和 1Password 支持加密备份，换机后代码自动恢复；部分应用则不备份，换机即失效。另外，把同一个 TOTP 密钥注册到两台设备上是可行的，等于免费冗余。
通行密钥与安全密钥
通行密钥（Passkey）和硬件安全密钥使用与网站自身域名绑定的加密技术，因此钓鱼页面无法诱骗它们完成登录。GitHub 和 GitLab 都支持这两种方式。如果你的代码仓库具有实际价值，请注册通行密钥或硬件密钥作为主要验证因素，并保留一个 TOTP 应用作为备用。
硬件密钥（如 YubiKey）多插一个备用，丢一个不至于锁死自己。注意：密钥丢了无法远程补发，只能靠恢复代码。
短信验证码
短信可能通过 SIM 卡调换被劫持，并且完全依赖运营商的安全措施。只有在别无选择时才使用短信，并尽快改用其他方式。出国旅行时短信还可能收不到，导致临时锁在门外。
恢复代码
启用 2FA 时，网站会提供一组一次性恢复代码。生成后请离线保存：打印在纸上，或存入密码管理器的安全笔记中。如果没有这些代码就丢了手机，找回账户将变成一场漫长的客服拉锯战。每个代码只能用一次，用过就划掉；全部用完前记得重新生成一批。
启用 GitHub 2FA
登录后，前往 设置 > 密码和身份验证 > 双重身份验证，点击 启用双重身份验证。GitHub 可能会先要求你重新输入密码，这是为了防止他人在盗用你的登录会话后擅自改动安全设置。
注册 TOTP 应用
GitHub 会显示一个二维码。用你的验证器应用（Aegis、1Password、Google Authenticator 等均可）扫描，然后输入应用中的六位数字代码以确认。此后该应用每 30 秒生成一个新代码。注意：代码有时效，接近过期时输入往往会提示无效，等下一组代码再试即可。若无法扫码，点击“输入设置密钥”手动录入字符密钥——扫码失败多出在屏幕亮度或环境光不足。
添加通行密钥或安全密钥
TOTP 代码可能被网络钓鱼窃取。设置完成后，在同一设置页面注册通行密钥或硬件安全密钥作为第二种验证方式。将 TOTP 作为备用手段，而非唯一验证因素。建议注册两把密钥：一把日常随身，一把离线备份，避免单点故障。
下载恢复代码
GitHub 会在设置过程中提供恢复代码。请下载并离线保存——打印出来或存入加密硬盘，切勿放在代码仓库或云端笔记中。每个代码只能使用一次；若所有第二验证因素全部丢失，它们是你重新登录的唯一途径。换新手机或重新安装验证器应用后，务必重新生成一批恢复代码并替换旧文件。
之后的令牌与 SSH 密钥
现有的 SSH 密钥和个人访问令牌继续照常工作。HTTPS 推送此后将要求浏览器身份验证或令牌，而不是密码。团队中若有人仍用账号密码做 HTTPS 认证，CI 和旧脚本会开始失败，提前通知并改用令牌。
启用 GitLab 2FA
在 GitLab 中，点击你的头像，选择偏好设置，在左侧边栏打开账户，然后点击启用双因素认证。
配对你的应用
使用你的 TOTP 应用（如 Aegis、1Password、Google Authenticator 或类似应用）扫描二维码，并输入其生成的六位数字代码以确认配对。如果你更倾向于硬件方式，可以在同一个账户页面注册安全密钥或通行密钥等 WebAuthn 设备作为第二因素。注意：TOTP 应用会随时间生成新代码，输入时务必使用当前显示的那一组——过期或尚未生效的代码是最常见的配对失败原因。如果手机时间不准，TOTP 代码也会全部报错，请先确认设备时钟已自动同步。
保存恢复代码
随后 GitLab 会显示一组一次性恢复代码。如果你无法访问验证器，每个代码可使用一次。请下载、复制或打印这些代码，并将其存放在安全的地方，例如密码管理器。之后你可以在同一页面生成新的一组，但请妥善保管这第一组代码。常见的错误是随手截图后换手机丢失，或把代码存在与验证器同一台设备上——手机丢失时两者会一起失效。换新验证器应用（例如从 Google Authenticator 迁移到 Aegis）后，记得验证新应用能生成正确代码，再删除旧应用。
对 Git 操作的影响
启用 2FA 后，你的账户密码将不再适用于通过 HTTPS 进行的 Git 操作。请改用个人访问令牌进行推送和拉取，或改用 SSH 密钥。建议在启用 2FA 之前先创建令牌，以免在工作流程中途被锁定。创建令牌时只勾选实际需要的权限范围（如 write_repository），并设置合理的有效期；把令牌当作密码对待，不要提交进代码仓库。若使用 CI/CD 流水线通过 HTTPS 拉取代码，也要同步更新其中的凭据，否则流水线会在启用 2FA 后立即失败。
2FA 启用后的 SSH 密钥与令牌
2FA 开启后，基于密码的 git 推送将失效。将远程仓库切换为 SSH，日常操作便完全无需输入密码：
git remote set-url origin [email protected]:owner/repo.git
注意 URL 格式：SSH 地址以 git@ 开头而非 https://。切换后先运行一次 git fetch 确认连接正常，避免下次推送才发现配置有误。
生成 SSH 密钥
创建一个现代类型的密钥，并设置口令（passphrase）保护：
ssh-keygen -t ed25519 -C "[email protected]"
将 .pub 文件的内容复制到账户的 SSH 密钥设置中（GitHub：Settings → SSH and GPG keys；GitLab：Preferences → SSH Keys）。口令会被 SSH agent 缓存，因此很少需要输入。私钥文件本身绝不能离开本机——任何要求你粘贴私钥的页面都是钓鱼。
若在旧系统上 ed25519 不受支持，可退回 rsa 并指定至少 4096 位长度。同一台机器只需一把密钥；不要为每个服务重复生成，那只会增加管理负担。
用于脚本和 CI 的令牌
个人访问令牌（personal access token）在 API 调用和流水线中替代密码。为每个令牌分配能满足需求的最小权限范围 —— 只能读取公开仓库的令牌无法推送恶意提交。同时设置较短的过期时间，并按用途命名（如 ci-deploy），以便日后识别和撤销无用的令牌。
限制影响范围
优先使用限定到特定仓库和权限的细粒度令牌（GitHub）；服务器上的单个仓库则使用部署密钥（deploy key）。部署密钥默认只读，需要推送时再单独开启写权限。权限范围窄的凭据一旦泄露，攻击者能获取的远少于你的完整账户。定期检查已授权的密钥与令牌，删除不再使用的条目——它们是无人看守的后门。
其他值得锁定的开发者账户
软件包注册表值得获得与你的 Git 托管平台同等的保护。npm、PyPI 和 Docker Hub 均支持 2FA，npm 在某些情况下还强制要求。注册表账户一旦被攻破，攻击者就能发布被篡改的软件包版本，随后它会进入每一台安装该软件包的机器。PyPI 还支持“可信发布”（Trusted Publishing），让 CI 流水线直接以工作流身份发布，无需长期保存 API 令牌；能用就优先用它，令牌泄露风险随之消失。
云控制台与 CI 提供商
AWS、Google Cloud、Azure 以及 GitHub Actions secrets 或 GitLab CI 变量等 CI 服务通常保存着部署凭据、数据库访问权限和支付卡。在控制台账户上启用 2FA，然后审计哪些 CI 任务可以读取机密（secrets）。常见疏漏：给所有流水线统一授予整个组织的作用域（scope），结果一个低权限项目的构建脚本被注入，也能读走生产密钥。按项目最小化授权，并定期清理长期未用的令牌。
信任的根基
有两个账户比其他都更重要：
- 电子邮箱 — 几乎所有密码重置都经由这里
- 密码管理器 — 掌管着其他所有账户的钥匙
如果其中任何一个失守，攻击者往往就能通过重置密码进入其他所有账户，无论是否启用 2FA。用你拥有的最强第二因素保护这两个账户，最好是硬件密钥或身份验证器应用而非短信，并且切勿在其他任何地方重复使用它们的密码。额外一步：为这两个账户单独保存一份恢复码，放在密码管理器之外。若你把恢复码存进密码管理器、而密码管理器本身又绑定该邮箱，一次故障就会把你锁在所有账户之外。
日常使用 2FA
2FA 开启后，养成几个习惯就能让它不再麻烦。
保管好你的恢复代码。 将它们存入密码管理器，或打印一份放在安全的地方。切勿将它们提交到代码仓库——即使是私有仓库，也可能通过令牌、Fork 或配置错误而泄露。也不要只存在手机截图里：换机或清空相册时最容易丢。GitHub 和 GitLab 都允许重新生成恢复代码，用掉一套或怀疑泄露后，立即生成新的一套，旧代码随之作废。
注册备用第二验证因素。 趁一切正常时，再添加一个 TOTP 应用或备用安全密钥。手机丢了才去设置的备份，等于没有备份。理想组合是“手机上的 TOTP 应用 + 放在抽屉里的实体安全密钥”：两者同时丢失的概率很低。注意 TOTP 绑定的是设备而非手机号，换新手机前先在旧设备导出密钥，或提前用恢复代码重新绑定。
定期审计。 每隔几个月，检查活跃会话并移除不再使用的设备。吊销过期的 SSH 密钥、个人访问令牌和部署密钥——旧凭据的寿命往往比创建它们的项目还长。设个日历提醒会有帮助。审计时顺手确认每条会话的 IP 和时间是否眼熟，陌生条目直接吊销。
**如果全部丢失，**请联系平台支持。恢复可能需要数天，且需要证明你是账户所有者，因此请将这条路视为最后手段，而非计划。GitHub 的恢复流程通常要求验证账户关联信息，期间仓库可能无法推送——这正是备用因素值得提前配置的原因。
现在花两分钟设置，胜过日后被锁在门外一周。启用 2FA，保存好代码，然后继续。