当我们站在 2026 年的视角回望软件开发历程，会发现“Support for password authentication was removed”这个报错不仅是一个简单的错误提示，更是一个分水岭。它标志着传统的、依赖单一凭据的开发时代彻底结束，迎来了基于零信任、硬件级安全以及 AI 辅助开发的新纪元。在这篇文章中，我们将深入探讨这一错误背后的深层原因，并不仅仅是教你如何绕过它，而是如何以此为契机，构建一套符合未来 10 年标准的安全开发工作流。
目录
为什么我们需要做出改变？
在深入解决方案之前，让我们先理解“为什么”。很多开发者习惯于使用 HTTPS 协议配合 GitHub 账户密码进行操作，这种方式虽然简单，但存在明显的安全隐患。密码往往容易被泄露或在网络传输中被截获。为了增强安全性并保护用户账户免受未经授权的访问，GitHub 强制要求我们采用更复杂的令牌或加密密钥机制。
但这仅仅是表面原因。在我们最近的一个企业级项目中，我们发现现代化的 CI/CD 流水线根本无法容忍“人工输入密码”这一环节。我们需要一种能够无缝集成到云端 IDE、Agentic AI（自主 AI 代理）以及容器化部署中的身份验证机制。这不仅仅是关于 git push，更是关于如何在 AI 时代，安全地将代码库的权限授权给我们的编程伙伴——AI。
当我们使用 INLINECODEd99f6eb6、INLINECODE055b20cd 或 git pull 等命令时，如果是传统的 HTTPS 链接，现在必须提供一种称为 Personal Access Token (PAT) 的动态生成的字符串，或者改用 SSH 协议进行非对称加密认证。让我们来看看具体如何操作。
方案一：使用个人访问令牌 (PATs) —— 灵活性与细粒度控制
个人访问令牌（Personal Access Tokens，简称 PATs）是一种身份验证的替代方案，它的功能类似于你的密码，但更安全、更灵活。你可以把它看作是赋予特定应用程序（比如你电脑上的 Git）的一把“临时通行证”，你可以随时撤销它，而不需要改动你的主账户密码。
在 2026 年，随着 AI 编程工具的普及，PAT 的使用场景发生了微妙的变化。我们通常不建议为 AI 工具直接开启完全控制权限，而是根据“最小权限原则”来配置。
如何生成个人访问令牌
让我们从零开始，生成一个属于你的令牌。这个过程就像是在为你的一台新设备配置门禁卡。
- 登录与设置：首先，登录你的 GitHub 账户。点击右上角的个人资料图片，在下拉菜单中找到并进入 “Settings” (设置)。
- 开发者设置：在设置页面的左侧边栏中，通常在底部位置，你能看到 “Developer settings” (开发者设置)，点击它。
- 访问令牌选项：在开发者设置页面中，点击左侧菜单的 “Personal access tokens” (个人访问令牌)，然后选择 “Tokens (classic)” (经典版令牌)。虽然 GitHub 推出了更细粒度的 Fine-grained tokens，但大多数情况下，Classic tokens 依然是最通用的选择。
- 生成新令牌：点击 “Generate new token” (生成新令牌) 按钮（通常选择 Generate new token (classic)）。
- 配置权限：这是关键的一步。你需要给这个令牌起一个名字，比如“My MacBook Pro Git Token”，以便你在未来管理时能认出它。在下方的权限列表中，你需要根据实际需求勾选。
* repo：这是最核心的权限，它允许完全控制私有仓库。如果你想对代码进行读写操作，务必勾选 repo 下的所有子选项（repo:status, repodeployment, publicrepo, repo:invite, security_events）。
* workflow：如果你的仓库包含 GitHub Actions，并且你需要通过 Git 触发或更新它们，请勾选 workflow 权限。
- 生成并保存：点击页面底部的 “Generate token” (生成令牌) 按钮。重要提示：屏幕上会出现一串长长的字符，这就是你的 Token。请务必立刻将其复制并粘贴到安全的密码管理器中。一旦你离开了这个页面，你就再也看不到它了，GitHub 为了安全不会显示第二次。
在实战中使用 PAT
现在我们有了令牌，让我们看看如何在代码中实际使用它。
场景 A：HTTPS 链接下的直接操作
当你执行 git push 命令时：
# 克隆仓库示例
git clone https://github.com/username/your-repository.git
# 当你尝试推送代码时
git push
终端会提示你输入用户名和密码。这里有一个容易混淆的细节：
- Username (用户名)：输入你的 GitHub 用户名（或者是你的 ID，如果启用了 SSO 可能会不同）。
- Password (密码)：这里不要输入你的账户密码！ 你需要粘贴刚才生成的 Personal Access Token。
如果你在输入 Token 后看到“Authentication Succeeded”或类似的进度条，恭喜你，你已经成功通过了验证。
场景 B：在 URL 中直接嵌入令牌（不推荐用于共享脚本，但适合个人快速测试）
有时，为了避免频繁输入，我们可以在克隆 URL 中直接包含凭据（注意：这会将密码保存在历史记录中，有安全风险，仅供了解）：
# 格式：https://[email protected]/username/repo.git
git clone https://[email protected]/username/your-repository.git
持久化存储凭据：避免每次都输入
每次 Push 都要复制粘贴 Token 显然太繁琐了。我们可以利用 Git 自带的凭据助手来记住它。
我们可以运行以下命令来设置凭据存储：
# 配置 Git 使用凭据存储
git config --global credential.helper store
工作原理解析：
当你运行这条命令后，Git 会在你下次成功输入 Token 后，将其以明文形式保存在你本地磁盘的 ~/.git-credentials 文件中。下一次进行 Git 操作时，Git 会自动读取这个文件，从而跳过输入密码的步骤。
安全建议：虽然这很方便，但如果你的电脑是多人共用的，或者被病毒感染，明文存储的 Token 可能会被窃取。请确保你的开发环境是相对私密的。对于 Windows 用户，如果你使用的是 Windows Credential Manager，也可以选择 INLINECODE7e67fd9a 模式，它比 INLINECODE504395cc 模式更安全。
方案二：使用 SSH 密钥（专业开发者的首选）
虽然 PAT 解决了 HTTPS 认证的问题，但作为追求极致体验的开发者，我们更推荐使用 SSH (Secure Shell) 协议。SSH 采用了公钥加密技术，这意味着你不需要在本地存储任何敏感的字符串，也不需要每次输入密码。一旦配置完成，你的电脑和 GitHub 之间就建立了一种基于信任的“握手”关系。
第一步：检查并生成 SSH 密钥
首先，让我们打开终端，检查一下我们是否已经拥有 SSH 密钥。通常，SSH 密钥存储在用户目录的 .ssh 文件夹下。
# 列出 .ssh 目录下的文件
ls -al ~/.ssh
输出解读：
- 如果你看到类似 INLINECODEcdfb2972 和 INLINECODEc4d2465b，或者 INLINECODEea55c4e4 和 INLINECODE96b5bbc4 的文件，说明你已经有了密钥。你可以跳过生成步骤，直接进入添加步骤。
- 如果目录不存在，或者里面没有文件，那么我们需要生成一个新的密钥对。
生成新密钥：
目前，GitHub 最推荐使用 Ed25519 算法，因为它既安全又高效。如果你的系统较老，也可以使用 RSA。
# 生成 Ed25519 类型的 SSH 密钥，-C 参数添加注释（通常填邮箱）
ssh-keygen -t ed25519 -C "[email protected]"
交互过程详解：
- 保存文件：系统会提示你输入保存文件的位置（默认是
/home/you/.ssh/id_ed25519）。直接按 回车键 接受默认值通常是最佳选择。
- 设置密码短语：系统会提示你输入 passphrase（密码短语）。这是一个可选的额外安全层。如果你设置了，每次使用 SSH 密钥时（比如重启电脑后第一次 push）都需要输入这个短语。如果你不希望被打扰，可以直接按回车留空（即不设置 passphrase）。
第二步：将私钥添加到 SSH 代理
为了确保 SSH 密钥在后台顺利工作，我们需要将其添加到 SSH 代理中。SSH 代理是一个管理密钥的后台程序。
# 启动 ssh-agent 并将其作为后台进程运行
eval "$(ssh-agent -s)"
接着，我们将私钥添加进去。如果你刚才生成的是 Ed25519 密钥，命令如下：
# 将私钥添加到代理
ssh-add ~/.ssh/id_ed25519
如果你使用的是 RSA（旧版），则应该是 ~/.ssh/id_rsa。
第三步：将公钥部署到 GitHub
现在，我们的电脑手里拿着“钥匙”，但我们还需要把“锁”的信息给 GitHub，也就是我们的公钥。公钥是可以公开的，它用来验证你的私钥签名。
1. 复制公钥内容：
在 macOS 或 Linux 上，我们可以使用 INLINECODEd2ce2f6a 或 INLINECODEea690779 命令配合 clip 工具。
# 读取并复制公钥内容 (macOS)
pbcopy < ~/.ssh/id_ed25519.pub
# 或者仅打印出来，手动复制 (Linux/WSL)
cat ~/.ssh/id_ed25519.pub
请确保复制的是 .pub 结尾的文件内容，通常以 ssh-ed25519 开头，后面跟着你的邮箱。
2. 在 GitHub 上添加：
- 回到 GitHub，点击右上角头像 -> Settings。
- 在左侧栏中找到 “SSH and GPG keys” (SSH 和 GPG 密钥)。
- 点击绿色的 “New SSH key” (新建 SSH 密钥) 按钮。
- Title (标题)：给你的钥匙起个名，例如 "My MacBook at Home"，这样当你有多台设备时能分得清。
- Key (密钥)：将刚才复制的公钥字符串粘贴到这个大文本框中。
- 点击 “Add SSH key” (添加 SSH 密钥)。
第四步：实战与配置切换
配置完成后，是见证奇迹的时刻。以后我们在操作仓库时，应该使用 SSH URL 而不是 HTTPS URL。
URL 格式对比：
- HTTPS:
https://github.com/username/repository.git - SSH:
[email protected]:username/repository.git
实战操作：
# 克隆一个使用 SSH 的仓库
git clone [email protected]:username/repository.git
# 如果你已经用 HTTPS 克隆了一个仓库，可以手动切换远程地址
cd existing-repo
# 查看当前的远程源
git remote -v
# 将远程源从 HTTPS 修改为 SSH
git remote set-url origin [email protected]:username/repository.git
# 再次验证，应该看到 URL 变成了 [email protected] 开头
git remote -v
现在，当你执行 INLINECODE9898d7d4 或 INLINECODE3b7345f5 时，如果一切正常，Git 将利用你的私钥与 GitHub 服务器进行静默验证，不再提示输入密码或用户名。这种流畅的体验是专业开发者所追求的。
2026 前瞻：AI 时代的身份验证与安全左移
当我们解决了眼前的认证问题后，作为技术专家，我们需要把目光放得更长远一些。在 2026 年，随着“Agentic AI”（自主 AI 代理）进入主流工作流，我们不仅要解决人类的身份验证，还要解决 AI 的身份验证问题。
当 AI 成为开发者：如何安全地授权？
想象一下，你正在使用 Cursor 或 GitHub Copilot Workspace。这些 AI 工具不仅建议代码，甚至能够直接执行 Git 操作。如果你使用的是传统的 PAT，一旦这个 Token 泄露，后果不堪设想。这就是为什么我们在 2026 年更倾向于使用 短期凭证 和 细粒度权限。
最佳实践建议：
- 独立服务账号：不要使用你个人的 GitHub Token 给 AI 工具（如 JetBrains 中的 AI 插件或自动化脚本）使用。创建一个专门的 GitHub 账号或机器用户，仅授予其特定仓库的“只读”或“仅 Issue 管理”权限。
- 环境变量隔离：在生产环境或 CI/CD 流水线中，绝对不要将 Token 硬编码在代码里。使用
.env文件或云服务商的密钥管理服务（如 AWS Secrets Manager 或 GitHub Encrypted Secrets）。
多模态开发与身份验证的未来
随着“氛围编程” 的兴起，我们可能不再只是通过终端输入命令，而是通过自然语言与 IDE 交互。例如，在未来的 VS Code 中，你可能会说：“帮我把这个项目推送到 GitHub 并创建一个 PR。”
为了支持这种无缝体验，我们需要确保底层的 Git 配置是完美的。如果每次都要弹出密码框，这种“氛围”瞬间就会被打断。因此，SSH 密钥配合本地代理 是实现这种零摩擦 AI 开发体验的基石。
常见问题排查与最佳实践
在配置过程中，你可能会遇到一些坎坷。让我们来看看如何解决这些常见的小麻烦。
1. 使用 PAT 时仍然报错
- 原因：通常是权限不足。如果你生成的 Token 没有勾选
repo权限，或者你试图操作一个你没有访问权限的仓库，就会失败。 - 解决：回到 GitHub Developer settings，检查 Token 的 Scope 是否包含了所需的权限。
2. SSH 测试连接失败
- 测试命令：我们可以使用
ssh -T命令来诊断连接问题。
# 测试与 GitHub 的 SSH 连接
ssh -T [email protected]
如果你看到 INLINECODE3ea60cf8 的字样，说明配置成功。如果看到 INLINECODE668e5929，说明你的公钥没加上，或者私钥没加载。
3. 最佳实践建议
- 优先选择 SSH：对于个人开发机和长期维护的项目，SSH 省去了令牌过期的烦恼（Token 通常有有效期限制，如 90 天）。
- 定期轮换 Token：如果你使用 Token，建议定期去 GitHub 检查并删除不再使用的 Token，只保留活跃的。
- 启用双重认证 (2FA)：无论你选择哪种方式，为你的 GitHub 账户开启 2FA 都是必不可少的防线。
结语
从简单的密码验证过渡到 PAT 或 SSH 密钥，虽然是被迫的一步，但这实际上是让我们成为了更负责任的开发者。通过今天的探索，我们不仅修复了“Support for password authentication was removed”的错误，更重要的是，我们掌握了两种核心的身份验证机制。
现在，你可以自信地回到终端，尝试推送你的代码，享受既安全又流畅的 Git 操作体验。如果你在配置过程中遇到任何其他问题，不妨静下心来检查一下每一步的输出日志，通常答案就隐藏在细节之中。祝你的开发之旅顺畅无阻！