Linux SSH 报 Bad owner or permissions on ~/.ssh/config

执行 ssh，还没进入远程主机的认证过程，就看到下面的错误：

Bad owner or permissions on /home/alice/.ssh/config

即使文件属于自己且可读写，OpenSSH 仍可能拒绝它。例如下面的权限中，组用户也有写权限：

-rw-rw-r-- 1 alice alice 31 Oct 4 10:00 config

本文针对 Linux 上 OpenSSH 客户端读取个人配置时的这个错误。报错指向的是本地客户端配置文件，不是远程主机的 authorized_keys，也不是私钥权限告警。Windows 原生 OpenSSH 的 ACL 处理方式不同，不能直接照搬这里的模式位操作。

自己能读写，不等于配置文件可信

SSH 配置可以指定连接目标、身份文件和代理命令。如果其他账户能够修改它，下一次连接的行为就可能被改变。客户端不仅检查能否读取配置，也会检查文件所有者和写权限。

OpenSSH portable 的相关检查接受当前用户或 root 拥有的文件，并拒绝组写或其他用户写权限。对于自己维护的个人配置，设置为 600 是直接的处理方式：文件所有者可读写，组用户和其他用户没有权限。

不要把“必须是 600”当成错误的精确定义。是否被拒绝取决于所有者与写权限，单纯存在其他用户读权限并不等于触发同一个检查。也不要认为组名与用户名相同就能保留组写权限；在这里移除组写更明确。

对照错误路径检查本地文件

先确认当前执行身份、文件所有者和权限。以下命令检查当前用户的默认个人配置；如果报错列出另一个路径，应改查那个实际文件。

id
ls -ld "$HOME/.ssh"
ls -l "$HOME/.ssh/config"

如果文件显示为 -rw-rw-r--，其中第二组的 w 就是组写权限。-rw-r--rw- 则包含其他用户写权限。将文件改得更开放，例如 chmod 777，会扩大问题，不能帮助 SSH 信任它。

如果 ls -l 显示它是符号链接，继续查看链接指向的文件。OpenSSH 打开配置后检查实际文件的状态，仅看链接本身常见的 lrwxrwxrwx 无法判断是否合格。不要因为链接显示全权限就删除它，也不要直接修改它指向的共享配置或配置管理系统生成文件。

对普通文件可继续处理；对链接、挂载文件或自动生成配置，应先确认实际归属和维护入口。否则即使这次手工改好，下一次生成或同步时也可能恢复成错误状态。

只修正自己的个人配置

修改前把配置内容备份到只有自己可以访问的位置，并记录原所有者和权限。配置中可能有内网地址、用户名及代理参数，备份不要放进公开仓库或共享目录。

若该文件确实由当前用户维护，所有者也已经正确，只需调整这个文件：

chmod 600 "$HOME/.ssh/config"
ls -l "$HOME/.ssh/config"

确认结果中不再有组写和其他用户写权限，同时配置内容没有改变。不要把命令扩展为对整个家目录或 .ssh 目录树递归执行；目录需要搜索权限，公钥、私钥和配置也不是同一类文件。

如果所有者是另一个普通账户，先确认这份文件是不是本来就属于你。对于确认误归属的个人配置，可以由管理员只更正这一个文件的所有者。下面的 alice 和路径都是占位示例，必须换成实际本地账户和它的配置路径：

sudo chown alice /home/alice/.ssh/config
sudo chmod 600 /home/alice/.ssh/config

不要把 root 管理的系统配置统一改成自己的所有权。对于 root 拥有、由管理员管理的配置，root 本身并不会被上述所有者检查拒绝；是否需要修改，应按该文件的管理方式处理。把组名改成用户名也不是这里必需的步骤，更不能用它代替移除组写权限。

同样，不要用 sudo ssh 绕开当前用户的报错。换一个执行身份会改变使用的个人配置与密钥，得到的结果不能证明原用户的配置已经修好。

验证配置被读取，再验证连接

先用同一套 SSH 客户端解析配置。下面的 my-server 是你的 Host 别名占位值：

ssh -G my-server

-G 会在计算 Host 和 Match 配置后打印结果并退出。核对输出中的主机、用户、端口和身份文件是否符合预期；输出含有本地路径或内部地址时，不要直接贴到公开日志。配置中的 Match exec 可能执行本地命令，因此只对自己信任的配置进行这项检查。

如果当前客户端不支持 -G，不要把“不认识选项”当成配置权限修复失败。可以在允许连接目标主机的前提下，使用普通连接命令配合详细日志：

ssh -v my-server

验收分两步看：原来的 Bad owner or permissions 消失、日志或配置输出显示读取了预期配置，说明这一处本地配置检查已经通过；随后还需完成原来要做的连接。若出现主机密钥核验、网络或 Permission denied (publickey)，应按新的错误继续定位，不能再一律归因于配置文件模式。

不要通过 ssh -F /dev/null 得出“已经修好”的结论。显式指定另一份配置会改变加载路径，还会忽略系统级配置；绕过原文件后能连接，并不代表原文件已经可用。

权限改完仍然报错的情况

先重新看错误中的完整路径，确认修改的是同一文件。终端、IDE、Git 子进程、容器和服务可能以不同身份、调用不同 SSH 客户端运行。要在原来失败的调用环境中复查，不能拿另一个用户的成功替代验证。

如果刚执行完 chmod，查看权限却没有变化，或很快又被恢复，应检查文件系统是否支持这些权限，以及是否有挂载、同步或配置生成流程在接管文件。这里的普通 Linux 文件处理方法不覆盖 Windows 挂载盘的权限映射，也不覆盖额外的访问控制策略。

若误改了并非自己维护的文件，按事先记录让管理员恢复正确归属；配置内容受损则从安全备份恢复。不要为了回到原状就主动恢复会再次触发拒绝的组写权限。最终应保留可用的原配置内容，并让文件的维护身份与权限都符合预期。