“permission denied (publickey)”的根本原因是公钥未被服务器授权，需双向排查：客户端用ssh -v确认是否发送并被接受公钥，服务器端核对authorized_keys内容完整性、权限（755/700/600）、selinux上下文及sshd_config配置。
遇到“Permission denied (publickey)”且确认私钥权限正确、服务端也启用了公钥认证，大概率是公钥未被服务器真正接受——也就是“公钥未授权”。这不是权限问题，而是服务器压根没读到或不认你的公钥。排查要从客户端行为和服务器端状态双向验证。
确认客户端是否真的发送了正确的公钥
运行 ssh -v user@host（加一个 -v 即可），观察输出中是否有类似：
Offering public key: /home/you/.ssh/id_rsa-
Server accepts key—— 表示服务端在authorized_keys里找到了匹配的公钥 -
Server refused our key或直接跳过该密钥 —— 说明公钥未被识别，大概率没配对或格式错误
如果连 “Offering” 都没出现，检查客户端是否指定了密钥：ssh -i ~/.ssh/your_key user@host；否则默认只尝试 id_rsa、id_ecdsa 等标准名。
检查服务器端 authorized_keys 内容是否准确
登录服务器（用密码、控制台或其他可用方式），定位到目标用户的 ~/.ssh/authorized_keys 文件：
- 用
cat ~/.ssh/authorized_keys查看内容，确认里面确实有你本地id_rsa.pub的**完整一行**（开头是ssh-rsa或ssh-ed25519，结尾是邮箱或注释，中间无换行、无多余空格） - 常见错误：复制时漏了最后几个字符；粘贴进编辑器后自动折行；用 Windows 编辑器保存带
\r\n换行符；手动添加时多了一个空格或 tab - 安全做法：在客户端执行
ssh-keygen -l -f ~/.ssh/id_rsa.pub得到指纹，再在服务器上运行ssh-keygen -l -f ~/.ssh/authorized_keys，比对是否一致
验证用户主目录和 SSH 目录是否被 SSH 服务跳过
即使公钥内容正确，OpenSSH 在读取前会先做权限校验。只要以下任一条件不满足，它就**静默跳过整个 authorized_keys 文件**，不会报错，也不会记录“公钥不匹配”，只会回退到其他认证方式：
- 用户家目录（如
/home/user）权限不能含“组写”或“其他写”，推荐755或750；775、777会被拒绝 -
~/.ssh目录必须是700（drwx------） -
~/.ssh/authorized_keys必须是600（-rw-------）
修复命令（以 user 用户为例）：
chmod 755 /home/user<br>chmod 700 /home/user/.ssh<br>chmod 600 /home/user/.ssh/authorized_keys
留意 SELinux 和 sshd_config 的隐藏限制
在 RHEL/CentOS/Fedora 等系统上，即使权限全对，SELinux 可能阻止 sshd 访问 .ssh 目录：
- 运行
ls -Z ~/.ssh，确认上下文为ssh_home_t；如果不是，执行restorecon -Rv ~/.ssh - 检查
/etc/ssh/sshd_config中：
–PubkeyAuthentication yes（必须启用）
–AuthorizedKeysFile .ssh/authorized_keys（路径是否被改过？默认值不能错）
–StrictModes yes（默认开启，不可禁用，它正是触发上述权限检查的开关）
