SSH 使用短别名时没有采用域名 Host 块里的 User

执行 ssh app1.example.com 使用的是配置中的远端账号，改成 ssh app1 却换成本机用户名，甚至因此出现 Permission denied。如果配置只是给短别名设置了 HostName，先确认域名通配符是否真的匹配了这次连接。

例如：

Host *.example.com
    User deploy

Host app1
    HostName app1.example.com

在没有启用主机名规范化、也没有额外最终解析规则的常见 OpenSSH 配置中，Host 通常匹配命令行提供的名字。app1 不符合 *.example.com，而 HostName 指定实际目标地址，并不意味着再自动套用全部域名块。

把别名明确纳入适用范围

可以把短别名和域名模式写在同一条 Host 中，用空格分隔：

Host app1
    HostName app1.example.com

Host app1 *.example.com
    User deploy

这样，ssh app1 从第一个块取得目标地址，也匹配第二个块的账号设置；ssh app1.example.com 则直接匹配第二个块。app1、域名和 deploy 都应替换为实际值。

只有确实需要同一账号的域名才应保留在通配符范围内。若这里只需要修一个短别名，直接在它自己的块中补充 User deploy 更容易控制影响，不必扩展其他主机的配置。

修改前保存 ~/.ssh/config 的副本，并保留原来的身份文件、端口、跳板机等必要配置。不要用上述片段整体覆盖已有文件。

用有效配置确认，别只看文件里写了什么

支持 -G 的 OpenSSH 客户端可以打印配置解析结果后退出：

ssh -G app1
ssh -G app1.example.com

分别查看 hostname 和 user。在这个例子中，两次结果都应指向 app1.example.com 与 deploy。输出还可能包含路径和其他连接信息，不要把完整结果直接公开。

-G 本身不会建立 SSH 会话，但配置中的 Match exec 可以在解析过程中运行本地命令，所以这不适合用来检查不可信配置。较旧客户端如果不支持 -G，不要照抄后假定已经验证；应先核对其本机手册，或者在允许实际连接的条件下用 ssh -v app1 查看目标账号和应用的配置块。

如果仍显示另一个账号，检查命令行是否带了 -l otheruser 或 otheruser@app1，以及前面是否已有匹配块设置 User。命令行选项优先；配置里的 User 等一般使用最先取得的值，后面的匹配块不会简单覆盖前面的值。因此具体设置通常放在前面，通用 Host * 默认值放在后面。

这条规则不能不加区分地套用到所有参数。例如 IdentityFile 可以累计多项。这里只是在判断 User 和目标地址，不是在重新设计全部身份配置。

已启用规范化时，要把再次解析考虑进去

CanonicalizeHostname 默认是 no。启用后，OpenSSH 会根据相关规范化规则处理名字，并再次读取配置，因此可能出现按新目标名匹配的行为。Match final 也能触发最终解析，不能把“Host 永远只认短别名”当作绝对规则。

只为修复一个别名的账号，显式列出该别名通常就足够。不要直接给全部连接启用规范化：它还会涉及域名后缀、DNS、CNAME 以及代理连接的适用条件，可能影响原本正常的目标。已有规范化策略则应保留，结合实际 ssh -G 结果检查，而不是强行关闭。

配置结果正确后，再用已授权账号进行一次连接，核对实际远端身份。选对用户名不等于密钥已获授权；若仍被拒绝，要继续按认证日志处理，不能删除主机密钥记录来解决账号选择问题。

回退时恢复本次修改前的配置或撤销新增的别名匹配行，再检查有效配置。修改客户端文件不需要重启服务器，也不会改变已经建立的 SSH 会话。