Windows 服务器 SSH 认证失败排查实录

背景

一台公网 Windows Server 2022 服务器，SSH 客户端（paramiko）一直报 Authentication failed，但端口 22 明明可达。之前部署时还能正常连接，某天开始突然全部失败。本文记录完整的排查路径，供同类问题参考。

第一步：确认密码本身是否有效

先用另一个客户端 + 同一份密码尝试连接。如果别的客户端能连上，说明服务器侧密码有效，问题大概率在失败方的凭据或调用方式上——这个对照实验是整个排查的分水岭。

第二步：服务器侧基础检查

net user Administrator
net accounts

• net user 确认账户已启用、密码最后设置时间（对比是否被动过）、上次登录时间
• net accounts 确认锁定策略（锁定阈值=从不，排除账户被锁）

第三步：检查 sshd_config

type C:\ProgramData\ssh\sshd_config

重点看 PasswordAuthentication、Match 段、AllowUsers 等限制项。默认配置下密码认证是开启的，多数情况这里没问题。

第四步：事件日志定位失败来源（关键）

安全日志 4625（登录失败）能看到失败的用户名，但 SSH 的失败记录（LogonType=8）通常不带来源 IP。真正的金矿是 OpenSSH 自己的日志：

Get-WinEvent -LogName 'OpenSSH/Operational' | Where-Object {$_.Message -match 'Failed password'}

每条失败都带来源 IP 和用户名：

sshd: Failed password for Administrator from 221.10.95.138 port 44047 ssh2

锁定失败来源 IP 后，对比能成功连接的客户端出口 IP，立刻就能判断：是某个固定来源用错密码（程序自动重试），还是公网扫描器在爆破。

结论

本例服务器侧完全正常：密码有效、配置干净、无锁定策略。失败方是某个固定 IP 的自动重试程序，它持有的密码与服务器实际密码不一致。排查要点总结：

• 对照实验先行：能连上 vs 连不上，差异即是答案
• 密码特殊字符是重灾区：@ # $ * 这类字符经过 shell 命令行传参会被截断、展开或通配，务必用程序内字符串直传或配置文件
• 推荐密钥认证：公钥 + 私钥彻底绕开密码传递问题

附：公网 SSH 的爆破风险

排查时发现日志里混着大量来自全球各地 IP 的扫描尝试（Invalid user admin 等），22 端口裸奔风险很高。建议：改用高位端口、限制来源 IP、或强制密钥认证。