git配置多个SSH Key的方法【详解】

必须清空全局 user.name 和 user.email，因为 Git 提交时优先使用全局配置，若未为仓库单独配置，易导致身份混淆、跨域提交，甚至触发企业安全审计告警；清空后需为每个仓库手动配置。

记住一个核心原则：全局的 user.name 和 user.email 必须清空。否则，所有仓库都会默认使用这套身份信息提交，后果可大可小——轻则身份混淆，重则直接触发企业安全审计的告警。

为什么必须 unset 全局 user.name 和 user.email

这里有个关键机制需要理解：Git在确定提交者身份时，会优先读取全局配置。一旦你设置了全局值，哪怕事后为某个特定仓库单独配置了本地信息，也架不住偶尔的疏忽。比如，新克隆一个仓库后忘了配置，或者自动化脚本漏掉了这一步，提交记录就会“张冠李戴”——把个人账号推到公司仓库，或者反过来。

想象一下，同事在提交历史里看到“张三”修改了“李四”负责的私有项目，第一反应多半是权限系统出了漏洞。而在一些安全管控严格的企业环境里，持续集成（CI/CD）或审计系统甚至会直接拦截这类跨域提交行为，引发不必要的麻烦。

所以，最稳妥的做法是执行以下两条命令，彻底清除全局配置：

git config --global --unset user.name
git config --global --unset user.email

操作完成后，别忘了验证一下。运行 git config --global --list，输出列表里不应该再出现 user.name 或 user.email。从此以后，每个仓库都需要你手动进入并运行 git config user.name "xxx" 和 git config user.email "xxx" 来设置专属身份。

生成密钥时必须用 -f 指定文件名，别碰 id_rsa

接下来是密钥管理，这里有个常见的“坑”。无论是Windows下的Git Bash，还是macOS/Linux系统，SSH客户端通常都有默认的密钥查找路径（比如 ~/.ssh/id_rsa 或 ~/.ssh/id_ed25519）。问题在于，如果你先为GitHub生成密钥时没指定文件名，系统就会生成默认的 id_rsa。接着，你再为Gitee生成密钥时又忘了指定，第二次操作就会直接覆盖第一次的私钥文件。

结果就是，两个平台试图共用一把钥匙，但服务器只认各自绑定的那把公钥，连接失败几乎是必然的。

• 正确做法：每次生成密钥都使用 -f 参数显式指定路径。例如：ssh-keygen -t ed25519 -C "me@github.com" -f ~/.ssh/id_ed25519_github
• 算法选择：推荐统一使用 ed25519 算法，它比传统的 rsa 更快、更安全。当然，如果你需要连接一些老旧的GitLab实例（部分12.x以下版本），可能还需要兼容RSA。
• 密码设置：生成过程中的密码（passphrase）可以按回车跳过。但如果是在共享或公共电脑上操作，建议设置一个强密码以增加一层安全保障。

~/.ssh/config 里的 Host 必须是别名，不能是域名

配置SSH连接时，另一个高频误区出现在 ~/.ssh/config 文件里。很多人会直接写 Host github.com，以为这样就能让所有指向 github.com 的连接自动使用对应的密钥。

这个想法逻辑上没错，但忽略了一个现实场景：如果你拥有多个GitHub账号呢？它们都对应同一个域名 github.com，SSH单靠域名根本无法区分你到底想用哪个身份登录。

因此，正确的写法是定义独特的别名（Alias）。例如：

# GitHub 个人账号
Host github-personal
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github

# GitHub 工作账号
Host github-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work

配置好后，克隆仓库时必须使用别名：git clone git@github-personal:me/repo.git。对于已有的仓库，则需要修改远程地址：git remote set-url origin git@github-work:org/repo.git。

测试连接失败？先跑 ssh -T，别猜

遇到连接问题，最有效的排查方法不是盲目猜测，而是直接使用 ssh -T 命令进行测试，比如 ssh -T git@github-personal。这个命令能帮你快速定位问题到底出在SSH层，还是其他环节。

下面是一些常见的错误提示及其对应的解决思路：

• Permission denied (publickey)：这通常意味着私钥未被成功加载。检查一下是否用 ssh-add 命令将私钥添加到了袋里（例如：ssh-add ~/.ssh/id_ed25519_github）。另一个可能是 config 文件中 IdentityFile 的路径写错了，注意检查路径中是否有空格，以及 ~ 符号在某些终端下是否能被正确解析。
• Could not resolve hostname github-personal：这往往指向 config 文件本身的问题。检查文件格式是否正确（比如每项配置是否换行），是否存在不可见字符。同时确认文件是否保存在正确的路径 ~/.ssh/config，并且文件权限是否设置为 600。
• 连接成功但提示 Hi xxx! You've successfully authenticated, but GitHub does not provide shell access.：恭喜，这说明SSH层的认证已经通过了。如果还有问题，那么症结一定出在Git配置（比如用户信息）或者仓库的远程（remote）URL上。

最后提一个容易被忽略的细节：Windows用户如果使用原生的CMD或PowerShell，ssh-agent 服务可能不会自动启动，导致 ssh-add 命令失效。要确保SSH配置正常工作，建议在Git Bash或WSL（Windows Subsystem for Linux）环境下执行相关操作。