SSH服务器为什么拒绝了密码，登录失败如何解决？

ssh服务器拒绝密码的核心原因通常是服务端禁用了密码认证、账户被锁定、或PAM配置干扰，而不是密码本身输错了。排查思路应按“服务端配置是否正确开启密码登录”优先，其次检查账户状态和日志输出，最后再考虑网络与客户端因素，下面按照故障概率从高到低拆解。

ssh服务器为什么拒绝了密码：先看最常见的中断点

多数情况下,你输入密码后立刻看到“Permission denied (publickey,password)”，密码本身没有错，据行业共识，相当一部分故障并非密码错误，而是服务端压根没走密码验证流程。

密码认证被服务端强行关闭

这是排查顺序里最优先的检查项,OpenSSH服务端的/etc/ssh/sshd_config文件里，有两条关键指令：

• PasswordAuthentication yes：允许密码登录
• PermitRootLogin yes：允许root用密码登录（部分发行版默认是prohibit-password）

如果这两项被设置成no或prohibit-password，无论你输入的密码多正确，服务器都会拒绝，很多云厂商的安全基线默认会锁掉密码登录，只留密钥方式，导致用户误以为密码失效。

# 查看当前生效的配置，注意“-T”会输出实际运行参数
sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin'

如果输出显示passwordauthentication no，就找到原因了，修改时不要直接编辑sshd_config，更稳妥的做法是放到/etc/ssh/sshd_config.d/目录下的独立conf文件里，避免升级时被覆盖。

用户或IP被PAM直接拦截

即便sshd允许密码认证,系统层面的Pluggable Authentication Module（可插拔认证模块，PAM）仍可能拦下你，常见场景：

• 密码正确但账户被passwd -l锁定
• 登录尝试次数过多,被pam_faillock或fail2ban暂时封禁
• 账户过期,chage -E设置的期限到了

查看实时认证日志能直接定位,比猜原因高效得多。

用日志锁定ssh服务器拒绝了密码的真实原因

日志文件读法

不同发行版日志位置有区别,但这几条路径覆盖了主流系统：

筛选有用信息时,不要只看“Failed password”行，更关键的是它前面几行里PAM模块的判定结果。

从日志判断具体拦截者

假设你反复尝试密码,日志里出现：

sshd[12345]: Failed password for invalid user admin from 192.168.1.10

这里“invalid user”说明系统里根本没这个账号，那是用户名写错了，如果是：

sshd[12345]: pam_faillock(sshd:auth): Consecutive failure count reaches 3

就代表多次失败被锁定,按提示过几分钟再试，日志里如果有User root not allowed because not listed in AllowUsers，说明sshd配置里用AllowUsers白名单把账号排除了。

linux ssh密码正确但连接被拒绝：深挖配置细节

sshd_config里其他干扰项

当你确认密码没问题、日志也没报错时，以下配置项会直接造成假拒绝：

• Match User或Match Address条件块：在文件末尾出现时会覆盖全局设置，比如全局允许密码登录，但某个匹配块里关掉了
• AuthenticationMethods：如果指定了publickey，就完全不接受密码方式
• UsePAM设置为no：跳过系统的账户密码验证流程，导致正常密码无法通过

检查这些项时,用sshd -T输出的最终生效值来判断，别只看配置文件文本。

云服务器安全组和防火墙的伪装拒绝

有一种情况容易误判服务器本身没拒绝密码，但你的数据包根本没到sshd端口，部分云安全组策略或本地iptables规则在拦到非法IP时会发送RST包，表现就是“Connection closed”或“Connection refused”，和密码拒绝完全不一样。

排查方法：

# 在本机测试端口是否真实开放
telnet 你的服务器IP 22
# 如果通，再用密码登录仍然拒绝，问题在sshd
# 如果不通，检查安全组入方向规则和本地firewalld/iptables

深度排查方案：逐层剥离，避免重复踩坑

用verbose模式看到ssh客户端最详细的反馈

客户端连接时增加

-v参数（也可以加-vvv），会让你清楚看到认证过程停在哪一步，以下为观察顺序：

1. 先看是否打印Authenticating to host行，确认连接建立
2. 再关注Authentications that can continue，这里会列出服务端愿意接受的认证方式
3. 如果该行只显示publickey，说明密码认证在服务端是关闭状态，问题直指sshd配置
4. 如果显示publickey,password，但你仍然被拒绝，那就是密码验证环节本身出错，继续查看PAM设置

排除密钥文件带来的伪故障

有些用户之前配过SSH公钥,后来换了电脑或删了本地私钥，但服务端authorized_keys文件里还留着旧公钥，这种情况下，OpenSSH的认证顺序可能先尝试公钥，成功后就不再要求密码，这种情况不属于“密码被拒绝”，而是你根本没走到密码那一步。

# 查看实例上哪个用户当前启用了密码认证
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no 用户@主机

这样强制只使用密码方式,能快速避开公钥优先的干扰。

ssh登录不上怎么排查：给出具体操作路径

分步骤梳理,适合运维新手按顺序执行，大多数ssh服务器地址连接不上或密码被拒问题，都逃不出以下路径。

第一步：检查服务端监听与防火墙

# 确认sshd进程正常，并且监听在0.0.0.0:22
ss -tlnp | grep :22
# 查看防火墙放行状态
sudo firewall-cmd --list-ports   # CentOS/RHEL
sudo ufw status                  # Ubuntu/Debian

第二步：检查sshd配置语法并重载

# 重载前先验证语法
sudo sshd -t
# 如果没有输出错误，重载服务
sudo systemctl reload sshd

第三步：临时开启密码认证，验证故障是否消失

这是最直接的对照实验,能把问题锁定在配置层面还是账户层面。

sudo sed -i 's/^PasswordAuthentication./PasswordAuthentication yes/' /etc/ssh/sshd_config
sudo systemctl restart sshd

然后重新用密码登录,如果成功了，证明此前就是被配置拒掉，如果仍然失败，继续往下查PAM。

第四步：检查用户账户锁定状态

# 查看账户锁定状态，注意“L”表示锁定
sudo passwd -S 用户名
# 如果锁定，解除
sudo passwd -u 用户名
# 查看账户过期时间
sudo chage -l 用户名

解决ssh服务器拒绝密码的常见针对性方案

以下按概率排列的补救措施,都能在不重启服务的情况下生效：

• 修改密码认证开关：PasswordAuthentication yes后执行sudo systemctl reload sshd
• 清理失败计数：pam_faillock或faillock --reset可以让被临时封禁的账号立即解封
• 查看AllowUsers限制：如果sshd -T输出里有allowusers字段，确认当前登录用户是否在列表内
• 关闭SELinux干扰：部分强安全策略会阻止sshd读取用户家目录权限，执行getenforce查看状态，如果是Enforcing，尝试sudo setenforce 0临时验证（不推荐永久关闭）
• 重置用户密码：sudo passwd 用户名，重新设置一遍再登录

常见问题快速解答

为什么密码绝对正确，还是提示Permission denied？

服务端根本没用密码方式去验证你的输入,重点检查PasswordAuthentication以及AuthenticationMethods是否包含password，有些云服务器默认系统账户密码是禁用的，需要用sudo passwd 用户名先激活。

修改ssh端口后，密码登录也失败了？

端口变更不影响密码验证逻辑,但如果你使用的是非标准端口，需要检查SELinux策略或防火墙是否只放行了22端口，SELinux下自定义sshd端口需要手动修改策略，否则连接会被直接拒绝，表现和密码错误有区别（延迟明显更短）。

root用户总是被拒绝密码登录？

这大概率是PermitRootLogin设置问题，先看grep PermitRootLogin /etc/ssh/sshd_config，如果是prohibit-password，就改成yes，同时确认/etc/ssh/sshd_config.d/目录下是否存在覆盖这一项的文件，部分发行版（如Ubuntu）默认root没有设置密码，必须先sudo passwd root为root设置一个密码。

排查ssh服务器拒绝密码的本质,就是检查“是配置拒绝了密码认证”还是“是账户状态拒绝了登录”，日志和sshd -T参数输出始终是排查的第一依据，不要在客户端侧反复猜测密码错误，绝大多数情况下，问题都出在服务端配置文件对PasswordAuthentication的限制上。