SSH配置故障：同一服务器主SSH与Gitea服务的密钥匹配异常解决需求

我太懂这种糟心的感觉了——同一台服务器上跑着两个SSH服务，明明在~/.ssh/config里分别指定了不同的密钥，结果SSH客户端偏偏拎错钥匙，手动敲临时命令不仅容易忘，自动化脚本里还得反复调整，完全是治标不治本。咱们直接从根上修复配置文件，彻底解决这个问题。

问题根源分析 #

从你贴的verbose日志能看出来，SSH客户端在处理gitea这个Host配置时，还是优先尝试了id_rsa_server的密钥，根本没用到你指定的id_rsa_gitea。这大概率是ssh-agent密钥代理在搞鬼：它会把你之前加载过的所有密钥都缓存起来，连接时按顺序挨个尝试，哪怕你在config里指定了IdentityFile，代理也会跳过这个配置，优先用自己缓存的密钥列表。

一劳永逸的配置修复方案 #

只需要给gitea的Host配置块加一行IdentitiesOnly yes，就能强制SSH严格遵守你指定的密钥，忽略ssh-agent里的其他密钥。修改后的完整配置如下：

Host server
    hostname 1.2.3.4
    port 22
    user foo
    identityfile ~/.ssh/id_rsa_server

Host gitea
    hostname 1.2.3.4
    port 2222
    user git
    identityfile ~/.ssh/id_rsa_gitea
    IdentitiesOnly yes

为什么这行配置管用？

IdentitiesOnly yes的作用就是告诉SSH：只使用我在这个Host块里明确指定的密钥，不要去碰ssh-agent里的其他密钥。这样就彻底切断了代理的“自主选择”，让配置文件的规则成为唯一准则。

额外优化建议 #

如果你平时ssh-agent里加载了很多密钥，也可以给server的Host块也加上IdentitiesOnly yes，这样连接主服务器时也只会用指定的密钥，避免不必要的密钥尝试，还能提升连接速度：

Host server
    hostname 1.2.3.4
    port 22
    user foo
    identityfile ~/.ssh/id_rsa_server
    IdentitiesOnly yes

验证方法 #

修改完配置后，用ssh -v gitea测试连接，看日志里是不是只尝试id_rsa_gitea这一个密钥。成功认证后，不管是直接ssh还是git操作，都不用再加额外参数了——直接用git clone gitea:your-username/your-repo.git这类命令就能正常工作，自动化脚本也能直接调用，再也不用记那些临时命令了。

备注：内容来源于stack exchange，提问作者lonix