Arch Linux密钥SSH连Fedora Server：user1正常user2权限被拒求助

先从Fedora最容易踩坑的点说起——SELinux！Fedora Server默认运行在强制模式下，很多SSH密钥登录失败的问题都和它有关，尤其是不同用户间的权限上下文差异。

第一步：检查SELinux上下文标签 #

SSH相关的文件需要有正确的SELinux标签才能被sshd识别。对比user1和user2的authorized_keys文件标签：

# 查看user1的文件标签
ls -Z ~user1/.ssh/authorized_keys
# 查看user2的文件标签
ls -Z ~user2/.ssh/authorized_keys

正常情况下，输出应该包含system_u:object_r:ssh_home_t:s0。如果user2的文件标签不一样（比如是unconfined_u:object_r:user_home_t:s0），说明SELinux上下文不正确，修复命令：

restorecon -Rv ~user2/.ssh/

这个命令会自动恢复.ssh目录及文件的默认SELinux上下文。

第二步：确认用户主目录和.ssh目录权限 #

sshd对用户目录权限有严格要求，哪怕密钥文件权限对，主目录或.ssh目录权限过松也会拒绝登录：

• 用户主目录权限不能高于755（不能让其他用户有写权限）：

  chmod 755 /home/user2
  

• .ssh目录权限必须是700：

  chmod 700 /home/user2/.ssh/
  

• authorized_keys文件权限必须是600：

  chmod 600 /home/user2/.ssh/authorized_keys
  

第三步：查看user2登录时的sshd详细日志 #

你只提供了user1的成功日志，现在需要看user2连接时的错误日志。在远程Fedora主机上实时监控sshd日志：

journalctl -u sshd -f

然后从Arch主机尝试用user2登录，观察日志里的报错信息。常见的报错比如：

• Permission denied (publickey)：结合前面的权限/SELinux检查
• SELinux avc: denied ...：直接指向SELinux上下文问题

第四步：验证sshd_config的AllowUsers配置 #

虽然你配置里写了Allowusers user1 user2，但要注意大小写敏感！确认user2的用户名拼写完全正确，没有大小写错误（比如User2和user2是不同的用户）。如果有拼写错误，修改后重启sshd：

systemctl restart sshd

按上面的步骤排查，大概率能解决问题——毕竟同一密钥、相同authorized_keys配置，差异基本就在SELinux或目录权限上。

内容的提问来源于stack exchange，提问作者gabx