SSH配置文件为何总是应用*规则？求解析SSH配置工作机制

我来帮你理清这个问题——核心原因是你没搞明白SSH配置文件的匹配逻辑和优先级规则，咱们一步步拆解：

首先，SSH读取配置文件的核心机制是这样的：

• 它会从上到下逐个检查每个Host块，找出所有和你要连接的主机匹配的条目（Host支持通配符，*就是匹配所有主机）。
• 所有匹配的配置会被合并，但后出现的配置项会直接覆盖前面的同名配置——这就是你遇到问题的关键！

回到你的配置来看：
当你运行ssh gitlab_perso时，有两个Host块会被匹配：

1. 第一个是Host gitlab_perso，明确指定了要用~/.ssh/perso/id_rsa密钥；
2. 最后一个是Host *，它匹配所有主机，又重新指定了IdentityFile ~/.ssh/id_rsa。

因为Host *在配置文件的最后，它的IdentityFile设置直接覆盖了前面gitlab_perso块里的密钥配置，所以SSH最终只会用默认密钥，完全忽略了你为个人GitLab设置的密钥。

同样，当你直接连接gitlab.com时，Host gitlab.com和Host *都会匹配，后者的配置也会覆盖前者，导致默认密钥被持续使用。

有两种简单且常用的解决方案，你可以选适合自己的：

方案1：给通配符块加排除规则 #

修改Host *块，用Match条件排除已经有专门配置的主机，这样它就不会干扰特定主机的设置了：

Host gitlab_perso
HostName gitlab.com
User git
PreferredAuthentications publickey
IdentitiesOnly yes
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/perso/id_rsa

Host gitlab.com
Hostname gitlab.com
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_rsa

Host *
# 排除已经有专门配置的主机，只对其他主机生效
Match originalhost !gitlab_perso !gitlab.com
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_rsa

方案2：调整配置顺序，把通用块放最前面 #

既然后出现的配置会覆盖前面的，那我们把通用的Host *块放在最顶部，然后再写特定主机的配置——这样特定主机的配置就会覆盖通用配置了：

# 通用配置：所有主机默认用这个，除非下面有专门设置
Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_rsa

# 个人GitLab配置：覆盖通用配置里的密钥等项
Host gitlab_perso
HostName gitlab.com
User git
PreferredAuthentications publickey
IdentitiesOnly yes
IdentityFile ~/.ssh/perso/id_rsa

# 官方GitLab配置：这里可以不用重复写AddKeysToAgent和UseKeychain，通用块已经设置了
Host gitlab.com
Hostname gitlab.com
IdentityFile ~/.ssh/id_rsa

你的gitlab_perso块里已经加了IdentitiesOnly yes，这个配置非常有用——它会告诉SSH只使用你明确指定的密钥，不要尝试SSH代理里的其他密钥，能避免SSH拿着默认密钥去碰个人GitLab账号导致权限问题，建议保留这个设置。

你可以运行ssh -v gitlab_perso看调试输出，找到类似下面的内容，确认加载的是你指定的个人密钥：

debug1: identity file /Users/xxx/.ssh/perso/id_rsa type 0
debug1: identity file /Users/xxx/.ssh/perso/id_rsa-cert type -1

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