“permission denied (publickey)”表明公钥认证流程启动但被拒绝，常见原因依次为：客户端私钥未正确加载或权限不符（需chmod 600）、服务端authorized_keys权限错误（目录700、文件600）、sshd_config中pubkeyauthentication未启用或strictmodes触发校验失败、selinux拦截或日志显示具体拒绝原因。
SSH 密钥登录失败，最常见提示是 “Permission denied (publickey)”。这不是密钥“没生成”，而是某个环节被拒绝——可能是客户端没发对、服务端没认到、或中间被拦住了。排查要按顺序聚焦关键点，避免盲目重试。
一、先确认客户端私钥是否被正确加载和使用
客户端是否真在用你认为的那把私钥？很多失败其实卡在这一步：
- 显式指定私钥路径：用
ssh -i ~/.ssh/id_rsa user@host测试，避免依赖默认查找逻辑 - 检查私钥权限：必须为
600（chmod 600 ~/.ssh/id_rsa），OpenSSH 客户端会静默拒绝权限过宽的私钥 - MobaXterm 等图形工具不支持 .ppk 格式：若用 PuTTYgen 生成的私钥，需导出为 OpenSSH 格式（PEM 或 OPENSSH v1/v2），否则工具完全不加载、也不报错
- 验证私钥有效性：运行
ssh-keygen -l -f ~/.ssh/id_rsa，能正常输出指纹说明私钥格式完好
二、检查服务端 authorized_keys 是否可信可用
服务器上那行公钥，看着存在，未必真有效：
- 文件权限：~/.ssh 目录必须
700，authorized_keys文件建议设为600（chmod 600 ~/.ssh/authorized_keys） - 内容规范：每行一条公钥，开头是
ssh-rsa、ecdsa-sha2-nistp256或ssh-ed25519，中间不能换行、不能有空格或不可见字符（如 Windows 的\r\n） - 部署方式优先用
ssh-copy-id -i ~/.ssh/id_rsa.pub user@host，它自动处理目录创建、权限设置和追加逻辑，比手动复制粘贴更可靠 - 检查编码：运行
file ~/.ssh/authorized_keys应显示ASCII text；用cat -A ~/.ssh/authorized_keys查看是否有多余^M
三、验证服务端 SSH 配置与运行状态
即使密钥全对，服务端也可能“假装看不见”：
- 确认
/etc/ssh/sshd_config中启用密钥认证：PubkeyAuthentication yes（未被注释且值为 yes） - 检查
AuthorizedKeysFile路径是否匹配实际位置（默认.ssh/authorized_keys） - 确认
StrictModes yes开启时，家目录（/home/user）不能被组或其他用户写入（即不能是 775、777） - 修改配置后务必执行
sudo sshd -t校验语法，再sudo systemctl restart sshd生效 - SELinux 启用时可能拦截访问：临时禁用测试
sudo setenforce 0；若恢复后仍失败，修复上下文：restorecon -Rv ~/.ssh
四、用日志快速定位卡点在哪
不要猜，让日志说话：
- 客户端加三级调试：
ssh -vvv -i ~/.ssh/id_rsa user@host，重点看：-
Offering public key→ 客户端发出密钥 -
Server accepts key→ 服务端找到匹配公钥 -
Authentication succeeded或Permission denied (publickey)前的最后几行
-
- 服务端临时开 DEBUG3 日志：在
sshd_config加LogLevel DEBUG3，重启后查journalctl -u sshd -n 50 --no-pager，能明确看到拒绝原因（如“bad ownership”、“invalid format”等）
