收到 SSH 报错 Permission denied 时，先不要急着改配置文件。这个提示只是 OpenSSH 在认证失败后给出的统一结果，背后可能对应密码错误、用户被限制、密钥权限不对、sshd 配置禁止密码登录，甚至 PAM 账户状态异常。下面按排查顺序记录处理路径，每一步都会说明什么时候该做、做完怎么确认，以及需要注意的边界。

先确认登录方式和用户是否有效

密码登录失败时，先确认是否真的使用了正确用户。很多服务器默认禁止root远程登录，若用root连接会直接报Permission denied。可改用普通用户测试，或者检查/etc/ssh/sshd_config中PermitRootLogin的值。若为no或prohibit-password，则root只能通过密钥登录。临时修改后要重启sshd服务，但生产环境建议保持默认，避免留下安全风险。

如果普通用户也登录失败，下一步要确认密码本身是否被锁定或过期。可以查看系统里是否有 fail2ban 或 denyhosts 这类工具临时封禁了来源 IP，这类情况往往也会表现为 Permission denied，而且不会立刻出现在 /var/log/secure 的认证失败记录里，需要同时看防火墙或者相关拦截日志。

密钥登录时报错，优先检查权限

密钥登录时报错，最常见是~/.ssh目录或authorized_keys文件权限过大。OpenSSH要求私钥文件权限不能超过600，公钥和authorized_keys不能超过644。用ls -l检查，若权限不对，用chmod 700 ~/.ssh和chmod 600 ~/.ssh/authorized_keys修正。修改后立即重新测试，无需重启sshd，因为权限在每次连接时都会校验。

这里要补一个容易忽略的点：客户端本机的私钥权限也需要确认。比如 Linux 或 macOS 上执行 chmod 600 ~/.ssh/id_rsa，否则 SSH 客户端会拒绝使用该私钥。另外，authorized_keys 文件的所有者必须是登录用户自己，不能是 root 或其他用户，否则服务端同样会拒绝。用 ls -l ~/.ssh/authorized_keys 能看到属主，如果不对，用 chown 用户:用户 ~/.ssh/authorized_keys 修正。

sshd 配置是否允许密码认证

sshd_config中PasswordAuthentication参数直接决定是否允许密码登录。若为no，则密码登录必然被拒绝。可用ssh -v连接查看debug输出，会明确显示“Permission denied (publickey,password)”等。排查时先执行grep -v '^#' /etc/ssh/sshd_config | grep -i password，确认当前值。修改后需要systemctl restart sshd才能生效，注意别漏掉include子配置。

这里需要特别提醒：sshd_config 支持 Include 指令，比如 CentOS 7 上常见的 /etc/ssh/sshd_config.d/*.conf。如果只改了主配置文件，而子配置里仍存在 PasswordAuthentication no，最终生效值仍然可能是不允许。判断生效值最直接的办法是执行 sshd -T | grep passwordauthentication，这个命令会输出最终解析结果，不需要重启服务，也不会影响现有连接。

通过日志区分密码错误还是账户状态异常

密码和配置都检查过之后，如果仍然报错，就需要看服务端日志。在大多数发行版上，可以执行 journalctl -u sshd 或者 tail -f /var/log/secure。如果看到类似 Failed password 的条目，说明客户端确实发起了密码认证，只是密码不对；如果出现 PAM 相关的 account 错误，比如 authentication failure 或 Account locked，则可能是密码过期、账户被锁定或 PAM 规则干预。

此时用 chage -l username 查看密码有效期，用 passwd -S username 查看账户状态。如果显示 Password locked 或 Password expired，需要先解锁或重置密码。注意账户锁定和密码错误在日志里的表现不同：锁定通常带着 pam_unix(sshd:auth) authentication failure 之外还会有 locked 字样，而普通密码错误只会记录 Failed password。学会分辨能省去很多无效修改。

家目录和 SELinux 的兜底检查

前面的步骤都正常，仍然报 Permission denied，就要检查两个容易被忽略的地方。第一个是家目录权限：OpenSSH 会要求用户家目录以及 ~/.ssh 不能被其他用户写。如果家目录属于错误用户，或者权限过于宽松，建议先执行 ls -ld ~ ~/.ssh 查看所有者和权限，一般家目录不能有 group 或 other 的写权限，可以临时用 chmod 755 ~ 修正，但要注意如果原来家目录里存在需要私密的文件，这个操作可能改变访问范围，需要结合环境确认。

第二个是 SELinux。如果系统启用了 SELinux，并且之前有人手动搬移过家目录或修改过文件上下文，restorecon -R -v ~/.ssh 可以恢复默认上下文。也可以用 getenforce 看当前状态，临时用 setenforce 0 验证是否与 SELinux 有关，但生产环境不能长期关闭，验证后要立刻恢复，且正确做法是修复文件上下文而不是关掉 SELinux。

以上排查顺序基本覆盖了常见的 Permission denied 原因。实际环境中还可能遇到 TCP Wrappers、防火墙或公钥未被服务端识别等情况。修改任何配置前，建议先复制一份原始文件做备份，并且保持当前已建立的连接不要断开，防止修改后无法再次登录。如果问题始终无法定位，优先检查 /var/log/secure 或 journalctl -u sshd 的完整连续日志，那里面通常能看到认证失败的具体阶段。