SSH 登录诡异失败排查

在管理大型 Linux 集群或多用户环境时，SSH 登录故障是司空见惯的事情。但有时候，即便你配置了完善的 SSH Key Pair，系统依然会弹出密码输入提示；更诡异的是，当你输入了百分之百正确的密码后，系统依然报“访问拒绝”。

本文记录一个容易被忽视的细节：登录 Shell 的存在性检查。

一、 故障现象

用户在尝试 SSH 远程登录某台 Linux 服务器时，遇到了以下异常流程：

  1. Key 验证失效：明明本地配置了公钥，且服务端 authorized_keys 也正确，但连接时却直接跳过 Key 验证，提示输入密码。
  2. 正确密码被拒：手动输入正确的用户密码后，依然提示 Permission denied, please try again.。

这种现象通常会让人怀疑是公钥权限问题或 PAM 认证模块出了故障。

二、 日志追踪

通过查看远程主机的系统日志（通常在 /var/log/secure 或 /var/log/auth.log），我们可以精准定位问题：

1
2
3
4

Mar 17 02:20:50 rd-172-31-0-132 sshd[68460]: User wanlin.wang not allowed because shell /bin/csh does not exist
Mar 17 02:20:53 rd-172-31-0-132 sshd[68460]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.31.0.122 user=wanlin.wang
Mar 17 02:20:53 rd-172-31-0-132 sshd[68460]: pam_sss(sshd:auth): received for user wanlin.wang: 7 (Authentication failure)
Mar 17 02:20:54 rd-172-31-0-132 sshd[68460]: Failed password for invalid user wanlin.wang from 172.31.0.122 port 46614 ssh2

关键点分析：

  1. 首播报错：User wanlin.wang not allowed because shell /bin/csh does not exist。这是最关键的诱因。
  2. 后续连锁反应：由于 Shell 不存在，sshd 认为该用户是 invalid user（非法/无效用户）。
  3. 安全机制：为了防止信息泄露（不告诉攻击者哪个用户存在哪个不存在），即使是针对 invalid user，sshd 依然会继续走密码验证流程，但无论密码对错，最终都会报 Failed password。

三、 根本原因

在 Linux 系统中，登录认证不仅仅是校验密码或秘钥，还包含对“用户环境”的合法性检查。

  1. Shell 不存在：该用户在 /etc/passwd（或通过 LDAP/AD/SSS 同步）中配置的登录 Shell 是 /bin/csh。
  2. 环境缺失：目标机器上可能只安装了最小化系统，或者只有 bash，并没有安装 tcsh（提供 /bin/csh 符号链接）。
  3. SSH 策略：sshd 在处理连接请求时，如果发现用户的 Shell 不在 /etc/shells 列表中或物理上不存在，出于安全考虑，会将其标记为“不可登录”。

四、 解决方案

解决此问题非常简单，只需要确保用户所需的 Shell 存在于系统中：

方案 A：安装缺失的 Shell（推荐）

如果该用户习惯使用 csh/tcsh，直接安装即可：

1
2
3
4
5

# RHEL/CentOS
sudo yum install tcsh

# Ubuntu/Debian
sudo apt-get install tcsh

方案 B：更改用户的登录 Shell

如果该机器不需要 csh，可以将该用户的 Shell 改为默认的 bash：

1
2

sudo chsh -s /bin/bash wanlin.wang
# 或者修改 LDAP/AD 中的属性

五、 总结

排查 SSH 问题时，我们往往盯着 ~/.ssh/permissions 或者 sshd_config 不放。但正如日志所示，首行报错往往就是真相。看到 Failed password 不要只怀疑密码，先往上看几行，看看系统是否根本就没给这个用户“登录的资格”。