终端研发部相信不少人都遇到过这种尴尬时刻：同一台电脑上，肩上压着个人 GitHub 账号、公司 GitLab 账号，偶尔还要从 Gitee 拉一份开源代码，结果每次 git clone 都像在开盲盒——要么 Permission denied (publickey)，要么提交记录里显示的名字根本不是自己，严重一点，clone 半天忽然断流，报个 broken pipe 就傻眼了。
这篇文章要解决的正是这套“多 GitHub 账号 + 多平台 Git 使用”的配置问题，尤其是标题里那个附加场景：我就想用指定账号 clone，怎么办？ 我会从 SSH 多 key 的生成与注册讲起，到 ~/.ssh/config 的别名映射，再到 HTTPS 凭证冲突和几条真实报错的完整排查链路，内容偏实战，适合已经会基本 Git 操作、但被多账号身份搞到头疼的人。你不需要一次性看完，遇到问题按章节查就行，但建议前四章连起来读一遍，那才是这篇文章的核心。
1. 多账号时代的第一个坑：Git 根本不知道你是谁
很多人第一次遇到“多账号混乱”，症状往往不是 clone 失败，而是提交记录里的作者变了。昨天还是自己的名字，今天 commit 上去一看，显示的是公司同事或者某个已经完全忘掉的旧邮箱。这个问题的根源在于，Git 的身份信息默认是“全局一份”的，而不是“每个仓库一份”的。
1.1 认证身份与提交身份，两者经常被搞混
先说一个很容易被忽略的概念：Git 身份其实分成两层，认证身份和提交身份。
- 认证身份：决定你能不能访问远程仓库，也就是 clone 和 push 时对面认不认你。它靠的是 SSH key、HTTPS 密码或 token。
- 提交身份：决定 commit 里显示的作者名字和邮箱，写在每次提交的元数据里。它只跟
user.name和user.email这两个配置项有关。
这两者没有绑定关系。哪怕你认证用的是 A 账号的 SSH key，只要本机 user.email 写的是 B 邮箱，提交记录就会显示成 B。这也是为什么很多教程只说“配置 SSH key”还不够，你还要把每个仓库的提交身份搞定。
1.2 全局配置的“就近覆盖”规则
Git 的配置存在三个层级：系统级（--system）、全局级（--global）、仓库级（--local）。读取时仓库级优先于全局级，全局级优先于系统级。用命令验证一下：
bash复制git config --list --show-origin
这条命令会列出当前仓库所有生效配置以及它们来自哪个文件。执行之后你会发现，原来自己的 user.name 和 user.email 被全局配置覆盖着，仓库里压根没有单独设置。这就是为什么在不同平台、不同项目之间切换时，提交身份会“漂移”。
1.3 多平台多账号的本质：每个远端都要有独立钥匙
我在实际项目中见过一种特别常见的配置方式：一个人把公司电脑的全局 user.email 设成了公司邮箱，然后所有个人项目的提交也全顶成了公司身份；还有人图省事，把 ~/.ssh/id_ed25519 这一把 key 同时添加到 GitHub 和 Gitee 上。一开始能用，后面换账号就崩——因为 GitHub、Gitee、GitLab 这些平台都规定一把 SSH key 只能绑定一个账号。你想让同一台电脑同时使用两个 GitHub 账号，就必须准备两把不同的 key，并在使用时明确告诉 Git“这次用哪一把”。
把这层逻辑想清楚，后面所有配置就有方向了：认证层，按平台按账号拆 key；提交层，按仓库按目录拆身份。 两者都理顺了，多账号才会真正安静下来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 先把手里的钥匙理顺：SSH 多 key 生成与注册
在动手改任何配置之前，先把钥匙准备好。你最终的目标是：个人 GitHub 一把 key，公司 GitLab 一把 key，Gitee 一把 key，如果有多个 GitHub 账号，就再拆一把。每把 key 都是一个独立的身份凭证。
2.1 生成带明确命名的 key
很多人当初安装 Git 时一路回车，生成了默认的 id_ed25519，后面也没再管。到了多账号场景，建议按平台命名，避免后面彻底分不清。
bash复制# 个人 GitHub
ssh-keygen -t ed25519 -C "personal@example.com" -f ~/.ssh/id_ed25519_github_personal
# 公司 GitLab
ssh-keygen -t ed25519 -C "work@company.com" -f ~/.ssh/id_ed25519_gitlab_work
# Gitee
ssh-keygen -t ed25519 -C "gitee@example.com" -f ~/.ssh/id_ed25519_gitee
-f 参数指定了私钥文件的路径和名字，这样 ~/.ssh 目录下就不会只有孤零零一个默认 key。私钥文件生成后，对应的 .pub 公钥文件内容就是需要填到平台后台的内容。
2.2 注册公钥到对应平台
复制公钥内容，各平台入口不同：
- GitHub：Settings -> SSH and GPG keys -> New SSH key
- Gitee：设置 -> SSH 公钥
- GitLab：Preferences -> SSH Keys
粘贴的是 .pub 文件里的完整内容，不是私钥。私钥永远留在本机，这是一条铁律，任何时候都不要把私钥内容贴到网页上。
2.3 ssh-agent 的默认行为和残留 key 的坑
注册完公钥之后，很多人习惯把私钥加入 ssh-agent：
bash复制eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519_github_personal
ssh-add ~/.ssh/id_ed25519_gitlab_work
这在一把 key 的情况下非常好用，自动免密。但多账号场景下，ssh-agent 里同时存在多把 key 恰恰是很多诡异问题的来源。OpenSSH 客户端连接远程服务器时，会依次尝试 agent 里所有可用的 key，而服务器端出于安全考虑，只会容忍有限次认证尝试（MaxAuthTries），试到后面服务器直接断开连接，你看到的就是 Permission denied (publickey)。
所以多账号场景需要引入下面要讲的 ~/.ssh/config，并配合 IdentitiesOnly 参数，明确告诉 SSH“这个域名只用这一把 key，别拿 agent 里的其他钥匙瞎试”。
3. ~/.ssh/config 别名映射：多平台自动选账号的根基
~/.ssh/config 是 OpenSSH 的客户端配置文件，它的作用是把“连接目标”和“使用哪个 key”绑定起来。很多人知道这个文件，但没意识到它的核心是 Host 别名机制：你可以给某个真实域名起一个别名，然后在别名条目里指定这把连接要用的 key 和用户名。
3.1 Host 别名机制的运行逻辑
先看一个最小示例：
code复制Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_github_personal
这个配置的意思是：当 SSH 连接的地址是 github.com 时，使用 User git 和 ~/.ssh/id_ed25519_github_personal 这把私钥。注意这里的 User git 是 Git 平台统一的 SSH 用户名，GitHub、Gitee、GitLab 全部都是 git，不是你的 GitHub 登录名。真实身份完全由 key 决定。
有了这个文件，ssh -T git@github.com 就能自动匹配到 Host github.com，加载对应的 key。
3.2 多账号实例：让两个 GitHub 账号共存
现在关键问题来了：如果同一台电脑上有两个 GitHub 账号，它们都要连到真实的 github.com，而 ~/.ssh/config 里 HostName github.com 只能写一次，怎么区分？
答案是给第二个账号起一个别名。比如：
code复制Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_github_personal
IdentitiesOnly yes
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_github_work
IdentitiesOnly yes
这里 github-work 就是这个配置块的“别名”，它也是一种 Host 名称。当你执行 ssh -T git@github-work 时，实际上 SSH 连接的还是 github.com（因为 HostName 指向真实域名），但使用的 key 变成了 id_ed25519_github_work。GitHub 服务器看到这把 key，就识别为工作账号。
对应到 clone 命令上，你不能再写 git@github.com:owner/repo.git，而要写：
bash复制git clone git@github-work:owner/repo.git
URL 里 @ 后面跟的“主机名”换成了别名，SSH 客户端会拿这个别名去 ~/.ssh/config 里匹配对应条目，从而使用指定 key。这就是多 GitHub 账号一起工作的关键。
3.3 IdentitiesOnly 为什么必须开
上面配置里我写了 IdentitiesOnly yes，这一行在多 key 环境下非常重要。它的意思是：只使用这里列出的 IdentityFile 去认证，忽略 ssh-agent 里的其他 key。
不加这行时，OpenSSH 会先把你指定的 key 发给服务器，如果被拒绝，它会继续尝试 agent 里的所有 key。服务器如果开启了严格认证次数限制，就会直接断开，报 permission denied。加了之后，行为就变得确定：这个 Host 只用这把 key，匹配不上就失败，不会浪费认证次数，报错也更容易定位。
3.4 完整配置模板与权限注意
一份覆盖多个平台的配置模板长这样：
code复制Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_github_personal
IdentitiesOnly yes
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_github_work
IdentitiesOnly yes
Host gitee.com
HostName gitee.com
User git
IdentityFile ~/.ssh/id_ed25519_gitee
IdentitiesOnly yes
Host gitlab.company.com
HostName gitlab.company.com
User git
Port 22
IdentityFile ~/.ssh/id_ed25519_gitlab_work
IdentitiesOnly yes
Host gitlab-alt
HostName gitlab.company.com
User git
Port 2222
IdentityFile ~/.ssh/id_ed25519_gitlab_work
IdentitiesOnly yes
最后那个 gitlab-alt 条目是给使用了非 22 端口的内网 GitLab 用的。很多公司内网 GitLab 的 SSH 端口不是默认 22，比如 2222，这时候如果不写 Port 字段，连接就会失败。这也是“多平台”场景里很常见的一个坑。
配置完成后，记得 ~/.ssh 目录权限要是 700，私钥文件权限要是 600。Linux 和 macOS 上 OpenSSH 对权限很敏感，权限过宽会直接忽略这个 key。Windows 上如果用的是 Git for Windows 自带的 OpenSSH，一般没问题，但偶尔也要检查用户目录的权限设置。
4. 附加场景实战：用指定账号 clone 的四种姿势
铺垫了这么多，终于到标题里说的“附加场景”了。假设现在有这样一个需求：我要 clone 一个 GitHub 私有仓库，必须使用公司 GitHub 账号，而不是个人账号。这里有四种可落地的做法，从最推荐到最临时，我按实际使用频率排个序。
4.1 姿势一：SSH Host 别名 + 改造后的 URL（最推荐）
这是最正规、最“一劳永逸”的方案，前提是你已经按第 3 章配好了 ~/.ssh/config。以 github-work 这个别名为例：
bash复制git clone git@github-work:company-org/private-repo.git
这里的 github-work 是配置里的 Host 别名，Git 底层调用 SSH 连接时，SSH 会读取 ~/.ssh/config 找到 Host github-work 对应的条目，使用 id_ed25519_github_work 这把 key。clone 完成后，这个仓库的 origin 地址就是带别名的 SSH 地址，后续 push 也自动走这把 key。
这种方式的优点很直接：你的仓库和 key 的对应关系是“写死在 remote 地址里”的，不需要每次操作前想到底用哪个账号，非常符合“我就想用指定账号 clone”的心智。
4.2 姿势二：命令级 core.sshCommand 临时指定 key
有些场景不想大动干戈，只在这一条命令里指定 key。可以用 -c 参数临时覆盖 SSH 命令：
bash复制git -c core.sshCommand="ssh -i ~/.ssh/id_ed25519_github_work -o IdentitiesOnly=yes" clone git@github.com:company-org/private-repo.git
解释一下这条命令：-c core.sshCommand=... 是为这次 Git 执行临时设置一个配置项，后面 clone 时的 SSH 调用会用你指定的私钥。-o IdentitiesOnly=yes 依然是防止 ssh-agent 里的其他 key 干扰。
这个方式的坑有两个：一是 URL 里写的还是真实的 github.com，不是别名，所以 clone 出来的 remote 地址保持原样；二是 core.sshCommand 这个配置只对当前这一次命令生效，下一次 push 如果不带同样参数，又会退回默认身份。所以这个姿势适合临时验证、应急操作，不适合长期依赖。
4.3 姿势三：HTTPS + 个人访问令牌，但别把令牌写进 URL
如果项目走的是 HTTPS 而非 SSH，指定账号的方式就变成“提供指定账号的访问令牌”。很多网上的教程会让你这么做：
bash复制git clone https://your-token@github.com/company-org/private-repo.git
这条命令能跑通，但我强烈不建议这么干。因为 token 会直接出现在 git remote -v 输出中，还会留在 shell 历史里，一个不小心就泄露了。GitHub 的 token 相当于账号的完整访问权，泄露后果很严重。
更稳妥的做法是先把凭据写入 Git 的凭据助手，再正常 clone：
bash复制git credential approve <<EOF
protocol=https
host=github.com
username=your-github-username
password=your-token
EOF
这样 Git 的凭据助手会记住这组用户名和 token，之后 git clone https://github.com/company-org/private-repo.git 会使用这组凭据。但要注意，HTTPS 方式的凭据是基于 host 存储的，同一个 github.com 只能存一套用户名和 token，如果你想在同一台电脑上用 HTTPS 方式同时操作两个 GitHub 账号，这条路走不通。多账号场景下，SSH 才是更合理的方案。
4.4 姿势四：环境变量 GIT_SSH_COMMAND 与 CI 场景
在写脚本、CI 流水线或者临时测试时，环境变量是最顺手的方式：
bash复制GIT_SSH_COMMAND="ssh -i ~/.ssh/id_ed25519_github_work -o IdentitiesOnly=yes" git clone git@github.com:company-org/private-repo.git
这本质上和 core.sshCommand 是一样的，只是换成了环境变量。CI 里如果需要在多个任务中克隆不同账号的仓库，建议把 key 提前写入 runner 的 ~/.ssh 目录，然后通过环境变量指定。注意 CI 环境下要确保 ~/.ssh/config 权限正确，不然 OpenSSH 会拒绝加载 key。
4.5 各姿势对比
| 方案 | 适用场景 | 持久性 | 坑点 |
|---|---|---|---|
| SSH Host 别名 | 日常开发，多账号长期共存 | 持久，配置一次永久生效 | 需要用别名改写 remote URL |
| 命令级 core.sshCommand | 临时应急、单次克隆 | 仅当前命令有效 | 忘记带参数就退回默认 |
| HTTPS + token | 单账号 HTTPS 环境 | 凭据助手记住后持久 | token 勿写 URL，多账号不适用 |
| GIT_SSH_COMMAND 环境变量 | 脚本、CI、自动任务 | 随环境变量有效 | 每处调用都要设置 |
实际选型我的建议很简单：本地多账号，一律用 SSH Host 别名；脚本和 CI，用环境变量或 actions 里的专用密钥；HTTPS 只留给确实没有多账号需求的单一身份场景。
5. HTTPS 凭证冲突：同一台电脑上的“换账号”难题
把 SSH 方案讲完，再回头聊聊 HTTPS 的坑，因为现实中确实有不少项目只能走 HTTPS。比如某些公司内网 Git 服务器只开放了 HTTP 端口，SSH 根本连不通，这时候避不开凭据管理问题。
5.1 凭据助手的存储机制
Git 的 HTTPS 认证支持多种“凭据助手”：
- macOS 上默认用
osxkeychain，存到系统钥匙串 - Windows 上常用
manager-core，也就是 Git Credential Manager，存到 Windows 凭据管理器 - Linux 上常见
cache（内存中缓存一段时间的密码）和store（明文存在文件里）
它们的共同点是：凭据和 host 一一对应。同一个 github.com，只能存一组用户名和密码（或 token）。这带来一个问题——如果两个 GitHub 账号都想走 HTTPS，后写入的凭据会覆盖先前的，然后 clone 时你怎么都认证不对，因为 Git 永远掏出来的是最后一组。
5.2 残留错误凭证是怎么让 clone 一直失败的
我处理过不少类似问题：同事说“我明明在 GitHub 上生成的新 token，怎么 clone 还是报认证失败”。一查，发现 Windows 凭据管理器里存的是三个月前的一个旧 token，那 token 早就被删了或者权限改了，Git 却不问青红皂白直接调用。
大多数时候 Git 凭据助手不会主动弹窗让你重新输入，而是优先用已存储的凭据。所以排查 HTTPS 认证问题时，第一个动作应该是清掉旧凭据：
- Windows：控制面板 -> 凭据管理器 -> Windows 凭据，找到
git:https://github.com，删除后重新 clone - macOS：钥匙串访问，搜索
github.com，删除相关条目 - Linux：如果用的是
store，直接编辑~/.git-credentials
清完以后再 clone，Git 才会重新弹出认证输入。
5.3 怎么让 HTTPS 按仓库分别走不同 token
既然凭据助手按 host 存储，同 host 多账号无解，那有没有变通办法？如果确实无法切换到 SSH，可以尝试给不同仓库手动设置一个“仓库级”的 remote URL，把用户名内嵌进去，但不内嵌 token：
bash复制git remote set-url origin https://your-username@github.com/company-org/private-repo.git
这样 clone 时 Git 会预填用户名，但仍需要凭据助手提供密码或 token。它只能解决“用户名选择”的问题，token 依然只能存一套。所以我的结论不变：同一平台多账号，最彻底的办法永远是 SSH。
5.4 为什么多账号平台最终都绕回 SSH
SSH 和 HTTPS 的本质区别在于：SSH 认证靠 key 文件，可以按 Host 别名把不同的 key 绑定到不同的连接；而 HTTPS 认证靠用户名密码/token，在现代 Git 实现里凭据是 host 维度绑定的。SSH 在“连接维度”上天然支持精细区分，所以凡是涉及多账号多平台，社区里的经验基本都指向同一件事——~/.ssh/config 早点配好。
6. 真实报错排查：从 broken pipe 到 did not exit cleanly
配置多账号时，报错信息是最让人头疼的。Git 的错误提示经常很简陋，但每一条背后都有它的原因。我把这几年遇到频率最高的几条整理出来，按排查链路讲。
6.1 Permission denied (publickey) 排查链路
这是多账号场景的“国民级报错”。看到它，按下面的顺序查：
- 先用
ssh -vT git@github.com看 verbose 输出，重点看Offering public key后面对应的 key 文件路径。如果展示的路径不是你期望的那把 key，说明配置里 Host 匹配错了。 - 检查
~/.ssh/config里的缩进。该文件对格式很敏感，指令名必须顶格或统一用空格缩进，不要用 Tab。 - 检查 key 是否真的添加到平台后台了。
ssh -T成功后会有欢迎信息，失败会直接提示权限不足。 - 检查
IdentitiesOnly是否缺失。如果 agent 里有太多 key，服务器会拒绝继续尝试。
6.2 packet_write_wait: broken pipe 的完整排查过程
这个报错在热词里出现过，具体形式是：
bash复制git clone packet_write_wait: connection to 192.168.1.138 port 22: broken pipe
我遇到的一个真实案例是，用户在内网 GitLab 上 clone 一个大仓库，网络环境不太稳定，SSH 连接传了一会儿就断了。这种 broken pipe 本质是TCP 连接在传输过程中被中断，不一定是 Git 配置问题。排查步骤：
- 确认服务器是否可达：
ping 192.168.1.138，能通说明二层三层没问题。 - 确认 SSH 端口是否可达：
nc -vz 192.168.1.138 22，如果端口不通，考虑防火墙或端口变更。 - 用 verbose 模式测试认证能否完成：
ssh -vT git@192.168.1.138。如果认证阶段就断，结合第 6.1 节查 key；如果认证通过后传数据时断，更像是网络链路问题。 - 尝试调整 SSH 的保持连接参数：
bash复制ssh -o ServerAliveInterval=30 -o ServerAliveCountMax=10 git@192.168.1.138
如果这样能稳定，可以在 ~/.ssh/config 里给对应 Host 加上这两个参数。它们的作用是定期发心跳包，防止中间设备因为空闲超时掐断连接。
6.3 gitee clone 报错 git did not exit cleanly
这个报错常见于 Windows 的 TortoiseGit 图形界面，弹窗提示信息很笼统。它往往是底层命令行 Git 执行失败，但 GUI 只负责展示一个“退出码不干净”。我在实际协助排查中，最后定位到都是下面几个原因：
- TortoiseGit 的 SSH 客户端设置成了 PuTTY 的 Plink，而不是 Git 自带的 OpenSSH。公钥格式不匹配，导致认证失败。解决方法是：TortoiseGit -> Settings -> Network -> SSH client，指向 Git 安装目录下的
usr/bin/ssh.exe。 - 命令行
git clone能成功，但 TortoiseGit 失败。这种几乎可以断定是 GUI 配置问题，先解决上面那一步。 - 命令行也失败。那就剥掉壳，直接看命令行报的原始错误，很可能是第 6.1 节的公钥问题，或者凭据管理器里的旧密码。
这个案子的核心经验是：GUI 报的错只是表象，所有问题都要下沉到命令行去复现和定位。 在 GUI 里反复点按钮没有任何意义，打开一个终端跑一遍 git clone，错误信息会清楚得多。
6.4 SSH 走 443 端口的兜底方案
如果你遇到的是完全连不上 22 端口，但能正常访问 HTTPS，还有一个官方支持的兜底方案：让 SSH 走 443 端口。GitHub 官方提供 ssh.github.com 这个接入点，配置后 SSH 连接通过 443 端口转发。
bash复制git clone ssh://git@ssh.github.com:443/company-org/private-repo.git
如果希望长期使用，可以在 ~/.ssh/config 里单独加一个条目：
code复制Host github-443
HostName ssh.github.com
Port 443
User git
IdentityFile ~/.ssh/id_ed25519_github_work
IdentitiesOnly yes
然后 clone 命令：
bash复制git clone git@github-443:company-org/private-repo.git
这个方案相当于绕开 22 端口被限制的问题，用 HTTPS 端口承载 SSH 流量。注意 HostName 写的是 ssh.github.com，不是 github.com，这个接入点只处理 SSH 转发，所以别名要单独设置，别和常规的 GitHub 连接混在一起。
7. 多平台混用时的防呆习惯
配置本身不复杂，复杂的是日常使用中永远保持“身份正确”。我自己吃过几次亏之后，养成了几个小习惯，分享出来供参考。
7.1 仓库级 user.name / user.email 与 includeIf 按目录自动切换
很多人在 clone 之后不会特意再去 git config user.name，以为全局配置就够了。多账号场景下，强烈建议给每个仓库设置独立的提交身份：
bash复制git config user.name "Your Work Name"
git config user.email "your.name@company.com"
如果觉得每个仓库手动设置太麻烦，可以用 includeIf 按目录自动切换身份。在 ~/.gitconfig 里加：
code复制[includeIf "gitdir:~/work/"]
path = ~/.gitconfig-work
然后在 ~/.gitconfig-work 里写：
code复制[user]
name = Your Work Name
email = your.name@company.com
这样只要仓库路径在 ~/work/ 目录下，Git 就会自动套用公司身份，其他目录保持个人身份。这个方案对目录规划有要求，适合从源头避免身份漂移。
7.2 开 user.useConfigOnly 避免误提交
还有一个非常推荐的防呆设置：
bash复制git config --global user.useConfigOnly true
这个设置的意思是，如果某个仓库既没有局部的 user.name 和 user.email，也没有匹配到任何 includeIf 配置，Git 会直接拒绝提交并提示你设置，而不是默默使用全局值或者猜测主机名当作者。这样能确保你永远不会用错身份提交。
7.3 每次 clone 后先跑两个命令确认身份
我的习惯是，每次 clone 完一个新仓库，第一时间执行：
bash复制git remote -v
git config user.name && git config user.email
第一句确认 remote 地址对不对，第二句确认当前仓库的提交身份是否符合预期。确认完再开始干活，基本不会出“push 上去才发现作者不对”的事故。另外可以用 ssh -T git@github.com 验证认证身份，确认当前 SSH 连的是哪把 key。
7.4 换电脑后的迁移思路
最后说一句换电脑时的经验。多账号配置迁移时，不要直接把整个 ~/.ssh 目录拷走——重点迁移你保存的 config 文件和私钥文件，然后到新机器上重新生成公钥并添加到各平台，或者把原公钥内容也一并拷过去注册。~/.ssh/config 里的绝对路径如果变了，记得同步修改。为了不重蹈覆辙，我会把 ~/.ssh/config 纳入自己的 dotfiles 仓库做版本管理，换机器之后直接拉一份再微调即可。
我在实际配置中的体会是，多账号最难的不是某一条命令，而是“每次操作时都能确定当前身份”。把 ~/.ssh/config 配好之后，这个问题就变成了一次性的工程；仓库级身份配合 includeIf，后续基本不需要再操心。建议你在配置时每一步都用 ssh -T 验证一次，看到那个 Hi username 的欢迎语，再往下走。