xshell连接云服务器失败 原因排查

Xshell 连接云服务器时出现失败，最直接的困扰是无法进行远程管理。先确认是卡在地址解析、端口连通还是登录认证阶段，再针对性调整设置。本例基于 Windows 11 上的 Xshell 8 连接一台有权限管理的 Linux 云主机，按照“核对会话信息—测试端口连通—检查云端规则—验证服务与认证”的顺序排查，最后重新登录验证效果。

准备好云平台控制台访问权限、实例当前的公网地址、实际 SSH 端口号，以及管理员提供的登录账号和密码或私钥文件。服务器端命令以 Ubuntu 的 OpenSSH 为例；其他 Linux 发行版的服务名和日志路径可能不同，请勿直接照搬修改配置。

Xshell新建会话时正确填写主机IP和SSH端口

1. 留下完整报错，核对连接的确实是这台实例

先记下 Xshell 弹出的报错原文和出现时间。一直等待后提示“连接超时”、立即提示“Connection refused”、或者进入认证界面后被拒绝，分别对应不同的排查方向。把这些信息保留在本地记录里，比只写一句“连不上”更容易对照后续的测试结果。

进入云平台控制台，确认实例处于“运行中”状态，核对地域、实例名称和当前绑定的公网 IP。如果是家庭或办公网络直接连接，应填写当前能从该网络到达的公网地址；只有内网地址的实例，需要按已经配置好的 网络工具、堡垒机或其他私网通道接入。

如果实例近期重建过、变更了绑定地址或更换了弹性公网 IP，旧会话里的地址可能已经失效。使用域名连接时，也要确认它当前指向这台实例，不能把域名能打开网页当成 SSH 服务一定可用。

然后确认实际 SSH 端口。22 是默认值，但如果管理员修改过端口，后面的 Xshell 设置、端口测试、安全组以及服务器监听检查必须全部使用同一个实际端口。

2. 在 Xshell 中建立一份可核对的会话

打开 Xshell，点击【文件】—【新建】，把会话命名为“云服务器-核对”。在【连接】页将协议设为 SSH，【主机】填写刚核对的公网 IP 或域名，【端口号】填写实际端口。

注意主机栏只填写地址本身，不要把网址的 https://、网页路径或者“账号@地址”整段粘进去。账号需要在后续的认证设置中单独填写。先保存这份新会话，保留旧会话以便对照原先哪里填错。

单击连接后，观察是否出现与原来不同的提示。若从“超时”变成了用户名输入框或认证窗口，说明排查已经推进到了后面的阶段；若仍提示超时，先做下一步端口测试，不要反复尝试更换密码。

2. 在 Xshell 中建立一份可核对的会话

3. 在本机测试同一个 TCP 端口

在 Windows 系统中按 Win+R，输入 powershell 并回车，打开 Windows PowerShell。依次执行下面三行命令，根据提示输入真实的地址和端口数字：

$cloudServer = Read-Host "请输入云服务器公网IP或域名"
$cloudSshPort = [int](Read-Host "请输入实际SSH端口号")
Test-NetConnection -ComputerName $cloudServer -Port $cloudSshPort -InformationLevel Detailed

这里重点查看输出中的 TcpTestSucceeded 字段。它为 True，表示本次从这台电脑到目标 TCP 端口建立了连接；但这不能证明端口后面一定是正确的 SSH 服务，也不能证明账号已经通过认证。

如果它为 False，就继续检查公网地址、访问通道、安全组以及服务器监听。测试域名时，同时看 RemoteAddress 是否符合实例当前地址。若地址不一致，先处理域名解析，再对正确的地址进行测试。

PingSucceeded 与 TcpTestSucceeded 要分开看。服务器可以限制 ICMP 响应（即 Ping 不通），却允许 SSH 连接；因此不能只凭 ping 不通就认定服务器离线，也不能凭 ping 通就认定 SSH 端口已放行。以上输出应以你本机这次运行结果为准，不照抄示例结论。

4. 端口不通时，逐项核对云端入方向规则

若上一步测试端口不通，以阿里云 ECS 为例，在控制台进入对应实例详情，打开【安全组】，查看当前实例实际绑定的安全组和入方向规则。其他云平台使用对应的安全组或云防火墙入口，规则含义相同，菜单名称以实际平台为准。

检查是否有允许当前客户端访问实际 SSH TCP 端口的规则。如果端口改过，只保留默认 SSH(22) 规则并不能放行新端口。授权来源也要与当前办公网络的公网出口一致，而不是 Windows 中看到的 192.168 开头局域网地址。

需要补充规则时，按已确认的实际端口添加 TCP 入方向允许规则，来源限定为当前可信公网出口；单个 IPv4 地址可用“该地址/32”表示。保存后，回到同一个 PowerShell 窗口重新执行上一节最后一行命令，比较 TcpTestSucceeded 是否变为 True。

不要为了试一试把全部端口向所有地址开放，也不要直接关闭服务器内部防火墙。云安全组与系统内部防火墙是不同层级，两边都要与实际访问需求匹配。换到另一个经过允许的网络测试时，来源地址可能改变，也要一并核对规则。

如果规则已经正确但仍不通，进入下一步检查服务；若端口已通，直接继续认证检查，不重复扩大网络权限。

4. 端口不通时，逐项核对云端入方向规则

5. 通过控制台检查 SSH 监听与错误日志

当本机 SSH 进不去时，使用云平台正常提供的 VNC 或其他控制台登录方式进入同一台实例。以阿里云 ECS 为例，可以从实例的【远程连接】入口选择可用的控制台方式。这里需要实例的正常管理权限，不是用 Xshell 绕过登录限制。

在 Ubuntu 控制台先查看 TCP 监听状态：

sudo ss -lntp

在结果中查找实际 SSH 端口，并结合进程信息判断是否由 SSH 服务或相应的服务管理机制监听。如果没有目标端口的监听，就应检查 SSH 服务及配置；如果只监听回环地址（127.0.0.1），也不能当成外部客户端可以访问。云公网地址可能经过映射，不要求公网 IP 必须原样出现在实例内部的监听列表中。

继续检查 SSH 配置语法和近期日志：

sudo sshd -t
sudo journalctl -u ssh.service -n 50 --no-pager

sshd -t 出现错误时，记录提示的文件与行号，由管理员检查对应配置；没有错误输出只说明这次配置检查未发现相应问题，不代表服务已经启动或网络已通。日志里则对照前面记录的连接时间，查找启动失败、认证拒绝等信息。

如果这台 Ubuntu 使用 UFW，再运行下面这条只读检查：

sudo ufw status verbose

查看当前策略是否允许所需来源访问实际端口。显示 inactive 只表示 UFW 当前未启用，不能由此推断云安全组或其他过滤规则全部放通。

这一轮先把“目标端口是否监听、配置是否报错、日志如何记录”对应起来。涉及修改 SSH 配置时，保留控制台通道和原配置备份，检查通过后再由管理员按当前系统方式应用；不要在唯一登录通道上盲目重启服务。

通过ss命令检查SSH端口监听状态

6. 已进入认证阶段，再核对账号与私钥

回到 Xshell 的“云服务器-核对”会话，在【连接】下的【用户身份验证】页检查用户名。它是 Linux 实例中的登录账号，不是云平台网站账号，也不保证一定是 root，应使用该实例实际允许登录的用户。

服务器允许密码登录时，认证方法选择 Password，连接时输入这个 Linux 账号的密码。如果提示密码认证不可用，先核对实例规定的登录方式，不要把重复输入密码当成修复办法。

使用密钥对时，选择 Public Key，在用户密钥中选择与服务器该账号公钥配置相匹配的私钥。Xshell 8 可通过【工具】—【用户密钥管理器】导入已有私钥，再回到会话选择它。不要导入 .pub 公钥文件冒充私钥，也不要把云平台访问密钥当成 SSH 登录密钥。

私钥的 Passphrase 是保护本地私钥的口令，与 Linux 账号密码不是一回事。若提示 Permission denied 或认证方式不被支持，对照用户名、当前选中的密钥及服务器允许的认证方法逐项检查，并结合服务器日志判断。单纯重新安装 Xshell 不会自动修正这些服务器端条件。

7. 核对主机指纹，登录后保存可用会话

首次连接出现主机密钥提示时，先通过可信的云控制台或管理员提供的信息核对指纹，匹配后再接受。如果原来能连接、现在提示主机密钥变化，先确认实例是否重装、地址是否变更以及新指纹是否可信；不要直接清空全部主机密钥记录来消除提示。

确认主机身份并完成认证后，在远程终端执行：

whoami
pwd

对照 whoami 的实际结果确认当前账号，查看 pwd 返回的工作目录，确认已经进入目标实例的远程 shell。这里不预设固定输出，不能只凭“端口测试成功”就宣布登录完成。

保存已核对的会话参数，保留此次报错、端口测试和修正记录。最后输入 exit 退出，再从保存的会话连接一次；能经过正常身份验证重新进入目标实例，才说明这次排查落实到了可用连接。

Xshell会话中的用户身份验证配置