根本原因是ssh服务端因权限过宽主动拒绝读取authorized_keys；需确保：~目录755、~/.ssh目录700、authorized_keys文件600，且selinux上下文为ssh_home_t，authorizedkeysfile路径配置正确。
ssh登录提示“Authentication refused: bad ownership or modes”
这是最常见的密钥认证失败现象，根本原因不是密钥本身有问题，而是SSH服务端主动拒绝读取authorized_keys——因为它检测到文件或目录权限太宽松。
典型错误日志在/var/log/secure里能看到：
Authentication refused: bad ownership or modes for directory /home/user/.ssh
或
Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys
解决只需三步：
-
chmod 700 ~/.ssh——.ssh目录不能被组或其他人写入 -
chmod 600 ~/.ssh/authorized_keys—— 公钥文件必须仅所有者可读写 -
chmod 755 ~（如果主目录是775或777）—— 用户主目录不能有组写权限，否则SSH直接跳过密钥验证
为什么chmod 644 authorized_keys会失效
SSH服务默认开启StrictModes yes，它会在每次认证前检查~/.ssh及其内容的权限。一旦发现authorized_keys是644（即组可读），就认为存在信息泄露风险，立即放弃该密钥，不报错、不提示，只默默回退到密码认证。
这不是bug，是OpenSSH的硬性安全策略。即使你确认“组里都是可信用户”，也不能绕过。
注意：chmod 600是唯一被广泛接受的权限值；640在部分老版本sshd中可能被接受，但不可靠，不建议用。
SELinux启用时restorecon -R ~/.ssh不可省略
在RHEL/CentOS/Fedora等系统上，即使chmod全对了，仍可能失败。因为SELinux会对.ssh目录施加额外约束：必须是ssh_home_t上下文。
检查当前上下文：
ls -Z ~/.ssh
若显示unconfined_u:object_r:user_home_t:s0之类非ssh_home_t的类型，就需修复：
-
restorecon -R ~/.ssh—— 恢复默认SELinux上下文 - 临时禁用SELinux测试：
setenforce 0，成功则基本确认是SELinux问题 - 不要长期用
setenforce 0，应修复上下文而非关防护
sshd_config里AuthorizedKeysFile路径写错
很多用户复制网上的配置，把AuthorizedKeysFile设成%h/.ssh/authorized_keys或.ssh/authorized_keys %h/.ssh/authorized_keys2，结果公钥放对位置却没被加载。
默认值就是.ssh/authorized_keys（相对用户主目录），绝大多数情况无需修改。改了就必须确保：
- 路径中不带
~，只用%h或纯相对路径 - 实际文件路径与配置完全一致，大小写、拼写、斜杠方向都不能错
- 修改后必须
systemctl restart sshd，reload不够
最稳妥的做法是别动这行，只确认PubkeyAuthentication yes已启用。
权限和SELinux上下文是两个独立维度，一个配错就失败；而路径和配置属于服务端逻辑控制，改错等于“钥匙放进了隔壁抽屉”。调试时优先查/var/log/secure，它永远比客户端-v输出更准。
