问题原因解析 #

这个现象其实是由SSH的密钥认证逻辑和可能的Agent缓存机制共同导致的，咱们一步步拆解：

1. SSH的密钥尝试顺序规则
   当你给同一个Host配置多个IdentityFile时，SSH客户端会严格按照配置里的顺序依次尝试密钥——只要某一个密钥通过了GitHub的认证，就会立即返回对应的用户信息，并且终止后续的密钥尝试，不会继续往下试。

2. 为什么调整顺序还是连到vanshamagg？
   最常见的原因是SSH Agent优先使用了缓存的密钥：
   如果你之前通过ssh-add命令把id_rsa_github（对应vanshamagg）添加到了SSH Agent中，那么SSH会优先尝试Agent里缓存的密钥，完全跳过你在ssh-config里指定的顺序。这是SSH的默认行为——Agent提供的密钥优先级高于配置文件里的IdentityFile。

   另一种可能是第一个密钥的认证被GitHub拒绝：比如id_rsa_gortnm没有正确绑定到vansham-gortnm账户，或者密钥文件权限设置不正确（比如权限太开放，SSH会拒绝使用），导致SSH自动 fallback 到第二个密钥并成功认证。而你单独配置时能正常使用，是因为此时SSH没有其他备选，只能强制使用该密钥，而该密钥本身是有效的。

验证与解决办法 #

1. 检查SSH Agent的缓存情况 #

执行以下命令查看Agent中已加载的密钥：

ssh-add -l

如果看到id_rsa_github的指纹，说明Agent在优先使用它。你可以用下面的命令移除该密钥，再重新测试：

ssh-add -d ~/.ssh/id_rsa_github

此时再运行ssh -N github.com，应该会按你配置的顺序尝试密钥了。

2. 强制SSH仅使用配置文件中的密钥 #

在ssh-config的github.com配置块中添加IdentitiesOnly yes选项，这样SSH就会严格只使用你指定的密钥，忽略Agent中的其他缓存。修改后的配置如下：

Host github.com
HostName github.com
User git
IdentitiesOnly yes
IdentityFile ~/.ssh/id_rsa_gortnm # vansham-gortnm
IdentityFile ~/.ssh/id_rsa_github # vanshamagg

这时候再测试，SSH会按顺序尝试两个密钥，第一个成功就返回vansham-gortnm，失败才会尝试第二个。

3. 确认密钥与GitHub账户的绑定关系 #

分别单独配置每个IdentityFile，执行ssh -T github.com（用-T比-N更直观，会直接返回用户名）确认每个密钥对应的账户是否正确。如果某个密钥单独使用时无法对应到预期账户，登录GitHub后去「Settings → SSH and GPG keys」检查该密钥是否已正确添加到对应账户中。

内容的提问来源于stack exchange，提问作者Vansham Aggarwal