先理清楚你的场景：同宿主机的4台虚拟机，B、C都能通过ssh user@192.168.1.124用密码正常连主机A，D能ping通A还能反向让A连自己，但D连A就报密码错误。咱们从几个方向一步步排查：

• 先排除最基础的密码问题
  别笑，有时候真的是键盘布局坑人——比如D的键盘大小写锁定没关，或者特殊字符输入和B/C不一样。你可以在D上直接输echo "你的密码"看看输出是否和预期一致，或者去主机A本地用这个密码登录user账号，确认密码本身没问题。

• 检查主机A的SSH服务配置
  登录A，打开/etc/ssh/sshd_config文件，重点看这几个配置：

  • PasswordAuthentication yes：必须设为yes，而且不能被注释掉，毕竟你用的是密码认证。
  • AllowUsers/DenyUsers：如果这俩配置项存在，要确认user或者D的IP没被DenyUsers拉黑，同时在AllowUsers的允许列表里（如果配置了的话）。
  • PermitRootLogin：如果你登录的是root用户，得确保这个选项不是prohibit-password或者no。
    修改完记得重启SSHD服务：sudo systemctl restart sshd（Debian/Ubuntu也可以用sudo service ssh restart）。

• 看主机A的SSH日志找细节
  这是最有用的一步！在A上实时盯着日志：

  • Debian/Ubuntu：sudo tail -f /var/log/auth.log
  • RHEL/CentOS：sudo tail -f /var/log/secure
    然后在D上尝试连接，日志里会明确告诉你是密码错了、用户被拒绝、还是PAM模块拦了，直接定位根因。

• 检查主机A上的用户状态
  确认A上的user账号没被锁定：passwd -S user，如果输出里有L就是锁定了，解锁命令是passwd -u user。另外也可以看看用户的家目录权限是否正常，比如权限别设成700以外导致SSHD无法读取相关文件？不过B/C能连的话这个概率低，但也可以排查下。

• 用Verbose模式看D的连接过程
  在D上执行ssh -v user@192.168.1.124，开启详细日志模式，你能看到连接时的每一步——比如是否发送了密码认证请求，服务器返回了什么错误，有没有被本地的SSH配置干扰。另外也检查下D的~/.ssh/config或者/etc/ssh/ssh_config有没有针对这个IP的特殊配置，比如强制用密钥认证之类的。

• 排查防火墙/SELinux的限制
  虽然能ping通，但A的防火墙可能限制了D的IP访问22端口？可以临时关掉A的防火墙试试：sudo systemctl stop firewalld（或者ufw disable），再测试连接。另外SELinux也可能搞事情，用sestatus看状态，如果是Enforcing模式，临时改成Permissive：sudo setenforce 0，再试试。

• 确认网络端口连通性
  在D上用telnet 192.168.1.124 22测试22端口是否能通，如果能看到类似SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.9的banner，说明端口没问题；如果连不上，那就是宿主机或者虚拟机网络层面限制了流量。

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