Windows下用SSH连接Linux服务器失败，常见原因有哪些？

Question

Windows下SSH连接Linux服务器失败的常见原因包括：① Linux端SSH服务未启动或配置错误（如`sshd`未运行、`/etc/ssh/sshd_config`中`PermitRootLogin`/`PasswordAuthentication`被禁用）；② 防火墙拦截（Linux的`firewalld`/`ufw`或Windows Defender防火墙阻止22端口）；③ 网络层问题（IP地址变更、端口被NAT/路由器屏蔽、SSH服务监听非默认端口但客户端未指定）；④ 认证失败（密码错误、密钥权限不当、公钥未正确写入`~/.ssh/authorized_keys`且权限过宽）；⑤ Windows端工具问题（PuTTY编码设置异常、OpenSSH客户端版本兼容性问题、本地`known_hosts`冲突）。建议按“服务→网络→认证→客户端”顺序排查，使用`ssh -v user@host`获取详细调试日志，快速定位断点。

Answer 1

```html

一、服务层：Linux端SSH守护进程与配置健康性诊断

这是排查链的起点——若sshd未运行或核心配置被误禁用，连接在TCP三次握手后即被拒绝。需验证：systemctl status sshd（RHEL/CentOS）或systemctl status ssh（Ubuntu/Debian）；检查/etc/ssh/sshd_config中PermitRootLogin yes/no/prohibit-password是否匹配登录意图，PasswordAuthentication yes是否启用（密钥登录时可为no），且确认ListenAddress未绑定到127.0.0.1等受限地址。修改后务必执行sudo systemctl reload sshd而非restart，避免配置语法错误导致服务中断。

二、网络层：端到端连通性与路径可达性验证

检测层级	命令/工具	预期输出含义
本地路由与ARP	ping -c 4 192.168.1.100	ICMP响应成功表示L2/L3基础通路正常
TCP端口可达性	telnet 192.168.1.100 22 或 Test-NetConnection 192.168.1.100 -Port 22（PowerShell）	“Connected to”或“TcpTestSucceeded : True”表明端口开放且未被中间设备拦截

特别注意：若SSH监听非标准端口（如2222），Windows客户端必须显式指定：ssh -p 2222 user@host；NAT环境下需确认路由器端口转发规则已将WAN:22映射至内网Linux主机IP:22。

三、认证层：凭证有效性与密钥基础设施完整性校验

认证失败常因权限失控引发静默拒绝。关键检查项包括：
① 密钥文件权限：Linux端~/.ssh/authorized_keys必须为600（chmod 600 ~/.ssh/authorized_keys），其父目录~/.ssh须为700，用户主目录~不能是777；
② 公钥内容：确保公钥末尾无换行、空格，且完整写入authorized_keys单行；
③ SELinux上下文（RHEL系）：ls -Z ~/.ssh/authorized_keys应显示unconfined_u:object_r:ssh_home_t:s0，否则执行restorecon -Rv ~/.ssh修复。

四、客户端层：Windows终端工具行为与环境兼容性分析

graph TD
    A[Windows SSH客户端] --> B{PuTTY}
    A --> C{OpenSSH for Windows}
    B --> B1[编码设置：Translation → UTF-8]
    B --> B2[Connection → Data → Auto-login username]
    C --> C1[版本检查：ssh -V ≥ OpenSSH_9.0]
    C --> C2[known_hosts冲突：ssh-keygen -R host]
    C --> C3[代理跳转异常：ProxyCommand配置语法]

PuTTY需禁用“Implicit CR in every LF”以避免密码粘连；OpenSSH客户端需警惕C:\Users\%USER%\.ssh\known_hosts中旧指纹残留导致WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!而阻断连接，此时应执行ssh-keygen -R hostname清除缓存。

五、纵深调试：结构化日志驱动的故障定位法

执行ssh -vvv user@host（三级详细日志）可精准定位断点：
• 若日志卡在debug1: Connecting to host [x.x.x.x] port 22 → 网络层问题；
• 若出现debug1: Authentications that can continue: publickey,password但后续无响应 → 认证配置矛盾；
• 若报Permission denied (publickey)且此前已提供密钥 → 检查sshd_config中PubkeyAuthentication yes及密钥路径；
• Linux端同步抓包：sudo tcpdump -i any port 22 -w ssh-debug.pcap，结合Wireshark分析SYN/ACK/RST序列。

六、企业级加固场景下的特殊考量

在启用PAM模块（如pam_faillock.so）、SSH证书认证（CA签发user_ca.pub）、或集成LDAP/Kerberos的环境中，失败原因可能延伸至：① PAM策略锁定了用户账户；② 客户端未携带有效证书链；③ 时间不同步导致Kerberos票据失效（ntpdate -s time.windows.com）。此时需交叉验证/var/log/secure（RHEL）或/var/log/auth.log（Debian）中的PAM审计日志。

```