当 SSH、Git 或云平台访问提示认证失败时，问题经常不在密钥内容，而在密钥路径与权限配置。客户端可能加载了错误文件，服务端可能因为目录权限过宽拒绝公钥，操作系统也可能把密钥视为不安全对象。解决这类故障需要先区分是路径未命中、文件属主异常、权限位过宽，还是服务进程运行身份与访问控制策略不一致。
先确认认证失败发生在客户端还是服务端
排查第一步不要盲目换密钥，也不要先删除公钥再重新生成。客户端和服务端都可能拒绝认证，但两者的判断逻辑不同。客户端负责找到私钥、提交公钥、处理配置文件和主机指纹；服务端负责校验用户是否存在、家目录是否可访问、authorized_keys 是否安全、sshd 是否允许公钥登录。只有先确认失败点，才能避免把时间浪费在错误的方向上。
客户端侧最常用的方式是开启详细日志。执行 ssh -vvv 后，可以看到加载了哪些配置文件、尝试了哪些密钥、是否进入公钥认证阶段、服务端是否返回了拒绝原因。若日志显示密钥文件不存在或无法打开，问题通常在路径；若日志显示服务端拒绝 publickey，问题通常在服务端权限、authorized_keys 内容或用户目录状态。
ssh -vvv -i ~/.ssh/id_ed25519 user@host
服务端侧则需要查看 sshd 日志。不同发行版日志位置可能不同，systemd 环境通常使用 journalctl，旧系统可能查看 auth.log 或 secure。服务端日志比客户端日志更接近真实拒绝原因，例如会提示 bad ownership or modes、Authentication refused、user not allowed 等信息。只要拿到这些关键词，就能快速判断是权限问题、路径问题，还是配置策略问题。
sudo journalctl -u sshd -n 50 --no-pager sudo tail -n 50 /var/log/auth.log
错误信息本身也值得单独归类。Permission denied (publickey) 通常表示公钥认证流程被服务端拒绝；Could not open key file 更偏向客户端路径或文件不可读；bad ownership or modes for file 则几乎可以直接定位到权限或属主问题；Host key verification failed 与密钥路径无关，而是 known_hosts 或主机指纹变化导致。把错误信息分类后，修复动作会清晰很多。
密钥路径配置错误的定位方法
客户端密钥路径通常有三个来源：命令行参数 -i、SSH 配置文件 ~/.ssh/config、以及默认密钥文件。很多人以为只要密钥放在 ~/.ssh 下就能自动使用，但实际不一定。默认密钥通常只有 id_rsa、id_ed25519 等固定名称，一旦使用自定义名称，或者同一个用户下存在多套密钥，就必须显式指定路径。否则客户端可能尝试了错误密钥，最终被服务端拒绝。
更稳妥的方式是在 SSH 配置中为不同主机绑定不同密钥。配置文件中的 IdentityFile 支持绝对路径和波浪号路径，但某些程序调用 ssh 时可能不会正确展开波浪号，尤其是容器、CI 环境或自定义启动脚本。遇到这种情况，把路径写成绝对路径往往能立刻排除问题。对于 Git 这类会间接调用 ssh 的工具，还要确认它使用的是哪个 ssh 可执行文件，以及是否通过 core.sshCommand 覆盖了默认行为。
Host github-work HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work IdentitiesOnly yes
服务端侧的密钥路径同样容易出错。默认情况下，sshd 会读取用户家目录下的 .ssh/authorized_keys，但这个路径可以由 /etc/ssh/sshd_config 中的 AuthorizedKeysFile 修改。有些环境会把公钥集中存放在 /etc/ssh/authorized_keys/%u，有些会同时支持 .ssh/authorized_keys2。如果只检查默认路径，很容易误判为公钥不存在。使用 sshd -T 查看最终生效配置，比直接查看配置文件更可靠。
sudo sshd -T | grep -i authorizedkeysfile
路径问题还会出现在跨平台环境中。Windows 用户目录通常位于 C:\Users\用户名\.ssh，而 Git Bash 或 WSL 可能使用另一套 HOME 路径。同一个密钥在 PowerShell 中能找到，在 Git Bash 中却找不到，往往不是文件损坏，而是两个环境解析出的家目录不同。此时应该先确认当前环境中的 HOME、USERPROFILE 和 ssh 实际读取的配置路径，再决定把密钥放在哪里。
权限配置不当为什么会被拒绝
SSH 对权限的严格要求不是多此一举，而是为了防止密钥被其他用户读取或篡改。如果用户家目录、.ssh 目录或私钥文件被同组用户或所有用户写入，攻击者就可能替换 authorized_keys、修改私钥内容或窃取密钥。sshd 在这种风险下会直接拒绝认证，而不是继续尝试。Linux 和 macOS 通常要求 .ssh 目录为七零零，私钥为六零零，authorized_keys 为六零零或六四四，具体取决于策略和发行版默认值。
修复权限时，不要只改私钥文件本身，还要检查父目录。很多认证失败表面上是 authorized_keys 权限错误，实际上是家目录或 .ssh 目录权限过宽。比如 .ssh 是七五零但家目录被同组用户写入，sshd 仍然可能拒绝。推荐先统一属主，再设置目录和文件权限。若用户目录被其他用户拥有，仅修改权限位并不能解决问题，必须修正属主。
chmod 700 ~/.ssh chmod 600 ~/.ssh/id_ed25519 chmod 644 ~/.ssh/id_ed25519.pub chmod 600 ~/.ssh/authorized_keys chown -R user:user ~/.ssh
属主问题在容器、NFS、共享服务器和自动化部署环境中尤其常见。容器内运行的进程可能不是预期用户，挂载卷中的文件可能属于 root，NFS 的 root_squash 可能改变文件可见权限。此时 ls -l 看起来正常，但实际访问身份已经变化。排查时不要只看权限位，还要看 uid、gid、挂载选项和文件是否位于网络文件系统上。
ls -ld ~/.ssh ~/.ssh/authorized_keys ~/.ssh/id_ed25519 id stat -c '%U %G %a' ~/.ssh/authorized_keys
Windows OpenSSH 的权限模型与 Linux 不完全相同。Linux 依赖文件权限位，Windows 依赖访问控制列表。若密钥文件继承了过宽的 ACL，例如所有用户都有读取权限，sshd 客户端或服务端可能拒绝使用。修复时应移除继承，并只授予当前用户必要权限。使用 icacls 可以精确控制文件访问权，避免通过图形界面误改目录权限。
icacls $env:USERPROFILE\.ssh\id_ed25519 /inheritance:r /grant:r "$($env:USERNAME):(R)"
常见修复示例与验证流程
Linux 或 macOS 下最典型的修复流程是先确认路径，再修正权限，最后验证。先使用 ssh -vvv 看客户端是否加载了正确密钥，再登录目标机器查看服务端日志，确认是否出现 bad permissions 或 Authentication refused。如果问题在服务端，应检查用户家目录、.ssh 目录、authorized_keys 的属主与权限。修复后不要立即使用复杂工具测试，先用裸 ssh 命令验证，避免 Git、IDE、CI 环境引入额外变量。
ssh -vvv -i ~/.ssh/id_ed25519 user@host chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys sudo journalctl -u sshd -n 30 --no-pager
Git 认证失败经常让人误以为仓库权限有问题，实际上可能是本地使用了错误密钥。Git 默认会调用 ssh，但不会自动知道每个仓库应该用哪把密钥。若同一台机器上有工作账号和个人账号，建议通过 SSH config 分离身份，并用 IdentitiesOnly yes 限制只使用指定密钥。这样客户端不会把多把密钥全部提交给服务端，也能避免服务端因为尝试顺序或密钥不匹配而拒绝。
git config --global core.sshCommand 'ssh -i ~/.ssh/id_ed25519_github -o IdentitiesOnly=yes'
云主机和跳板机场景还要关注 known_hosts 与主机指纹。认证失败有时并不是密钥路径错误，而是目标主机密钥变化后客户端拒绝连接。重建实例、更换 IP、使用负载均衡或容器漂移，都可能触发 Host key verification failed。此时需要确认是否接受新指纹，或者在自动化环境中使用可预期的 known_hosts 策略。不要为了方便直接关闭主机密钥校验，这会带来中间人风险。
ssh-keygen -R host ssh -o StrictHostKeyChecking=accept-new user@host
长期维护密钥路径与权限的最佳做法
长期来看，密钥管理不能只靠临时修复，而要有明确规范。建议为不同用途使用不同密钥，例如个人开发、公司服务器、CI 流水线、运维跳板机分别使用独立密钥，并在文件名中体现用途。所有密钥统一存放在用户目录下的 .ssh 目录，避免放到临时目录、桌面、下载目录或共享挂载目录。目录结构清晰后，配置路径和权限检查都会简单很多。
自动化环境应把权限检查纳入部署流程。可以使用脚本或配置管理工具定期检查 .ssh 目录、私钥、authorized_keys 的属主和权限。对于服务器集群，Ansible 比手工命令更适合长期维护，因为可以把权限策略固化到代码中，并在新机器初始化时自动应用。这样即使有人误改权限，也能通过再次执行 playbook 恢复标准状态。
- name: enforce ssh directory permissions
ansible.builtin.file:
path: /home/alice/.ssh
state: directory
owner: alice
group: alice
mode: '0700'日志监控同样重要。认证失败如果只偶尔出现，可能是用户误操作；如果集中出现，可能意味着密钥轮换、目录迁移、系统升级或权限策略变更影响了大量主机。服务端应保留 sshd 日志，客户端在 CI 或运维脚本中应记录失败原因。长期维护的目标不是每次故障都手动救火，而是让路径、权限、属主和日志状态始终可预测，从根源上减少认证失败。