为什么 SSH 密钥权限会影响登录
很多人在配置 SSH 免密登录时，会把注意力放在公钥内容有没有复制完整、服务器地址和端口有没有写错，却忽略了一个很常见的细节：SSH 对密钥文件和用户目录权限非常敏感。权限过宽时，客户端或服务端会认为密钥存在泄露风险，直接拒绝使用。
这类问题的表现通常不是“密码错误”，而是免密登录突然失效、仍然要求输入密码，或者日志里出现 bad permissions、Authentication refused、unprotected private key file 等提示。它看起来像账号问题，实际常常只是权限不符合 SSH 的安全要求。
客户端私钥权限怎么检查
如果问题发生在本地电脑或运维跳板机上，先检查私钥文件。常见私钥路径是 ~/.ssh/id_rsa、~/.ssh/id_ed25519，也可能是你在 ssh -i 参数里指定的自定义文件。
可以用下面的命令查看权限：
ls -l ~/.ssh
ls -l ~/.ssh/id_ed25519私钥文件通常应设置为仅当前用户可读写：
chmod 600 ~/.ssh/id_ed25519
chmod 700 ~/.ssh如果私钥文件被设置成 644、666，或者所在目录允许其他用户写入，OpenSSH 客户端可能会拒绝加载它。修正权限后，再用 ssh -v user@server 观察调试输出，确认客户端是否已经尝试使用对应密钥。
服务器端 authorized_keys 要看哪里
如果客户端私钥权限没问题，下一步要看服务器上的用户目录、.ssh 目录和 authorized_keys 文件。服务端同样不喜欢权限过宽，尤其是用户家目录或 .ssh 目录被其他用户可写时，SSH 服务可能直接忽略公钥。
登录服务器后，可以检查：
ls -ld ~
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys常见修正方式如下：
chmod 755 ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R 当前用户:当前用户 ~/.ssh这里要特别注意用户身份。如果你是在 root 下操作普通用户的家目录，不要顺手把文件 owner 改成 root。很多免密登录失败，就是因为 authorized_keys 文件内容对了，但属主不对。
日志比反复试密码更有用
SSH 登录失败时，不建议一直重复尝试。更有效的办法是同时看客户端调试输出和服务器认证日志。客户端可以使用：
ssh -vvv user@server服务器端则根据系统不同查看日志。Debian、Ubuntu 常见位置是：
sudo tail -f /var/log/auth.logCentOS、Rocky Linux、AlmaLinux 常见位置是：
sudo tail -f /var/log/secure如果日志里明确写着 bad ownership or modes，就优先回到权限和属主检查；如果日志显示根本没有匹配到公钥，再检查公钥内容是否复制完整、是否放到了正确用户的 authorized_keys 里，以及 sshd_config 是否改过公钥认证路径。
配置文件也可能让公钥失效
有些服务器经过安全加固后，会调整 /etc/ssh/sshd_config。如果配置中关闭了公钥认证，或者修改了 AuthorizedKeysFile，即使权限完全正确也无法免密登录。
可以重点检查这些项：
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes修改 SSH 配置前要谨慎，尤其是远程服务器。建议先保留一个已登录窗口，再新开窗口测试连接，确认无误后再关闭旧会话。对生产业务服务器来说，改 SSH、改防火墙、重启服务都应先确认当前环境和回滚方式。
排障顺序建议
遇到 SSH 密钥登录失败，可以按这个顺序排查：先确认连接的用户、IP、端口无误；再确认客户端私钥路径和权限；然后检查服务器端用户家目录、.ssh、authorized_keys 的权限与属主；最后看日志和 sshd_config。
如果服务器承载网站或业务系统，排障时不要把登录问题和业务问题混在一起。比如需要临时迁移、重装或更换服务器时，建议提前备份站点文件、数据库和 SSH 配置。像 速维云云服务器 这类按需开通的环境，适合先搭建测试机验证登录、安全组和部署流程，再切换正式业务，能减少远程配置失误带来的停机风险。
总结一下，SSH 免密失败不一定是密钥错了。权限过宽、属主错误、放错用户目录、配置项被改，都可能导致公钥认证被忽略。按权限、路径、日志、配置这四步排查，通常能很快定位问题。
