Permission denied (publickey) 表明ssh服务端拒绝公钥认证，主因是服务端未加载或不信任客户端提供的公钥，需依次检查私钥路径、sshd_config配置、~/.ssh及authorized_keys权限与格式、SElinux上下文、authorized_keys内容规范、sshd服务重载状态、端口一致性、私钥完整性及密码输入正确性。
SSH 客户端提示 Permission denied (publickey)
这是最典型的密钥认证失败表现，说明服务端拒绝了你提供的公钥。常见原因不是私钥没发过去，而是服务端压根没加载或不信任它。
检查步骤：
- 确认客户端用的是正确的私钥：
ssh -i /path/to/id_rsa user@host；没加-i时默认只试~/.ssh/id_rsa、id_ecdsa等有限几个名字 - 服务端
/etc/ssh/sshd_config中必须有PubkeyAuthentication yes，且未被注释或覆盖 - 用户家目录（
/home/user）和~/.ssh的权限不能太宽松：目录需700，authorized_keys文件需600；chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys - SELinux 启用时可能拦截访问，临时禁用验证：
sudo setenforce 0；若恢复后仍失败，需修复上下文：restorecon -Rv ~/.ssh
authorized_keys 文件内容格式错误
哪怕只多一个空格、换行或用了 windows 换行符（rn），OpenSSH 都会静默忽略整行公钥。
实操建议：
- 用
ssh-keygen -l -f ~/.ssh/id_rsa.pub确认公钥本身有效 - 追加公钥务必用
ssh-copy-id或手动echo "公钥内容" >> ~/.ssh/authorized_keys，避免复制粘贴引入不可见字符 - 检查文件编码和换行：
file ~/.ssh/authorized_keys应显示ASCII text；cat -A ~/.ssh/authorized_keys查看是否含$（行尾）以外的^M - 每行只能有一把公钥，开头是
ssh-rsa/ecdsa-sha2-nistp256等类型标识，结尾是邮箱或注释（可选），中间不能断行
服务端 SSH 进程未重载配置或监听变更
改完 /etc/ssh/sshd_config 或 authorized_keys 后，很多人忘了让服务生效。
注意点：
-
sudo systemctl restart sshd是最稳妥的方式；仅reload可能不生效（尤其在旧版 OpenSSH 或某些发行版中） - 重启前先用
sudo sshd -t检查配置语法，避免启动失败锁死连接 - 确认
sshd实际监听的端口与你连接的一致：sudo ss -tlnp | grep :22（或对应端口） - 如果使用非标准端口，客户端必须显式指定：
ssh -p 2222 user@host，否则默认走 22
私钥密码错误或已损坏
当私钥设置了 passphrase，但输入错误或终端未正确传递时，会直接 fallback 到密码认证（若启用），或报 Enter passphrase for key 后卡住甚至失败。
排查方法：
- 用
ssh-keygen -y -f /path/to/private_key测试能否读出对应公钥；失败则私钥损坏或密码不对 - 如果私钥是
openssh格式（OpenSSH 7.8+ 默认），旧版客户端可能不支持，需转成兼容格式：ssh-keygen -p -m PEM -f id_rsa - 某些终端（如 windows Terminal + WSL）在粘贴 passphrase 时可能吞掉首字符，建议手动输入；也可临时去掉密码测试：
ssh-keygen -p -f id_rsa（仅调试用） - 确认私钥文件未被文本编辑器“自动转码”或意外修改，
ls -l查看大小是否异常（比如从 1.7KB 变成 2KB）
密钥认证看着简单，实际卡在权限、格式、服务状态这三个环节的概率远高于算法或协议问题。尤其是 ~/.ssh 目录权限和 authorized_keys 的换行符，几乎每次部署都要重新核对一遍。