企业官网建设流程全解析

GitHub 的账户安全需要拆成三层：网页登录的第二因素、账户恢复方式，以及 Git/API 使用的开发凭据。只配置验证器代码，不能自动解决恢复码、Passkey、Personal Access Token 或 SSH Key 的管理问题。

GitHub 2FA 的组成

GitHub 官方当前提供的账户安全选项包括验证器应用、短信（受地区等条件影响）、安全密钥与 Passkey，并要求用户妥善保存恢复方式。具体可用选项以账户设置页面为准。

配置时建议分开记录：

为什么开启 2FA 后 Git 命令仍可能报错

GitHub 早已不支持使用账户密码完成 Git over HTTPS 认证。HTTPS 场景通常使用 Personal Access Token 或凭据管理器；SSH 场景使用 SSH Key。网页登录时的 TOTP 不会在每次git push时弹出输入框。

排查时先执行：

git remote -v

• 地址以https://开头：检查凭据管理器和 Token；
• 地址以git@github.com:开头：检查 SSH Key、Agent 与权限；
• 使用 GitHub CLI：检查 CLI 的授权状态和权限范围。

不要把 PAT 写进远程 URL、脚本或仓库。Token 应设置必要权限和合理有效期，并按使用场景区分个人交互与自动化。

恢复码应该在什么时候保存

最合适的时间就是启用 2FA 的当下。恢复码不是验证器备份的同义词：

• 验证器备份解决“如何重新获得动态码条目”；
• GitHub 恢复码解决“主认证方式不可用时，如何通过平台认可的入口恢复访问”。

两者应分别保存。若手机、验证器备份和恢复码都放在同一设备，设备损坏会同时影响多个恢复路径。

Passkey 与 TOTP 如何组合

支持条件允许时，Passkey 或安全密钥可承担更强的抗钓鱼登录；验证器代码则可作为补充方式。配置多少种因素不是重点，重点是它们是否独立、是否能被撤销，以及恢复时是否清楚知道使用哪一种。

团队管理员还应检查组织是否要求成员启用 2FA，以及机器人、GitHub App、Deploy Key 等非人工身份是否被误放进个人凭据流程。

使用 Free2FA 配置 GitHub 验证器

在 GitHub 的 Password and authentication 页面选择 Authenticator App，再用「二次验证码 Free2FA」扫描页面生成的二维码。建议按下面的顺序完成：

1. 只扫描 GitHub 官方安全设置生成的二维码；
2. 输入 Free2FA小程序中显示的动态码完成绑定；
3. 下载并独立保存 GitHub 恢复码；
4. 退出 GitHub 后重新登录一次；
5. 确认无误后，再决定是否调整旧验证方式。

这套流程只负责网页登录验证。PAT、SSH Key 和 OAuth 仍要分别管理。

一次完整的 GitHub 安全检查

• 主登录因素可用；
• 恢复码已下载并独立保存；
• Passkey/安全密钥名称清楚，丢失设备可撤销；
• HTTPS 凭据不再使用账户密码；
• PAT 权限与有效期合理；
• SSH Key、OAuth App 和已登录会话已清理；
• 组织成员的 2FA 状态有明确政策。

下一步可从 GitHub 的 Password and authentication、Tokens、SSH and GPG keys 三个页面分别检查，不要把它们当成一个设置项。

相关阅读

GitHub+Codex统一 2FA管理：一个验证器覆盖全部开发工具链-CSDN博客

二维码不等于 TOTP：如何读懂 otpauth URI 与兼容参数-CSDN博客