服务器SSH连不上怎么排查:按网络端口认证服务四段定位

先看报错是超时、拒绝、认证失败还是连上即断,再按网络、端口、认证、服务四段由外向内查。只读命令先跑,改配置、重启服务等操作由人确认后执行。

要点速览

• 先读报错:超时、拒绝、认证失败、连上即断各指向不同段
• 按网络、端口、认证、服务四段由外向内排查
• 只读命令可直接跑,改配置、重启、删文件须人工确认
• 改sshd前保留已登录会话,先语法检查再用新窗口验证
• 托管服务器提工单写清IP、时间、现象、已做操作与授权

服务器SSH连不上,先看客户端报的是哪一种错误。超时、拒绝连接、认证失败、连上后立刻断开,分别对应不同的故障位置。然后按网络、端口、认证、服务四段由外向内查。前面几段多用只读命令,只看不改。改防火墙、改 sshd 配置、重启服务、清理磁盘这类操作,要由负责这台服务器的运维人员确认后再执行,并且保留一条能回退的会话。如果是托管在机房的服务器,远程手段都试过仍进不去,就带着 IP、时间、现象和已做操作去提工单,请机房远程协助或到场处理。

先看报错:四种「连不上」指向不同的段

很多人遇到 SSH 失败就开始重启、改配置,结果把原本简单的问题弄复杂了。先花一分钟读清报错,大致能判断该从哪一段查起。

• 连接超时(Connection timed out):数据包发出去没有回应。常见原因是网络不可达,或者途中被安全策略静默丢弃,优先查网络层。
• 拒绝连接(Connection refused):数据包到了主机,但对应端口没有服务在监听,或者被防火墙主动拒绝。优先查端口层和服务层。
• 认证失败(Permission denied):链路和服务都通了,卡在账号、密钥或口令上,直接查认证层。
• 连上后立刻断开:比如提示 Connection closed by remote host,或者在密钥交换阶段就被关闭。说明服务端主动断开,常见于 sshd 异常、资源耗尽、连接数限制,或者来源 IP 被封禁。

定位时可以先用 ssh -v 用户名@服务器IP 加详细输出再连一次,看日志停在哪一步:停在建立连接,还是停在交换密钥,还是停在提交身份凭证。这条命令是只读的,不会改动任何东西,可以放心多跑几次。

网络层:先确认本机到服务器是否可达

先看什么:本机能不能到达服务器 IP,路径上有没有丢包,中间有没有安全策略拦截。

命令示例(均为只读):

• ping 服务器IP:看能否收到回应、延迟和丢包情况。
• traceroute 服务器IP(Windows 下是 tracert),或者用 mtr 持续观察:看包在哪一跳开始丢。
• 换一个网络出口再试,例如手机热点,或者同机房的另一台机器。

结果说明什么:ping 不通不一定代表网络断了,不少服务器默认禁止回应 ICMP。所以 ping 只能作参考,要结合下一段的端口探测一起判断。换出口后能连上,问题多半在本地网络,比如公司出口限制了到外部 22 端口的访问,或者走了代理。路由追踪停在某一跳之后完全无响应,就要看云侧的安全组、机房侧的访问控制策略,或者上联设备有没有变更。另外要核对 IP 本身:服务器的公网 IP 最近是否调整过,DNS 解析是否还指向旧地址。

需要人工确认的操作:修改安全组、访问控制列表、路由。这些改动影响的不只是 SSH,可能波及业务流量,要由有权限的人评估后再改,并记下改了什么。

端口层:22 端口是否在监听、是否被拦截

先看什么:SSH 端口在网络上能不能探测到。默认是 22,很多服务器改过端口,先确认自己连的端口对不对。

从本机探测(只读):nc -vz 服务器IP 22,或者 telnet 服务器IP 22。能建立连接,说明端口通。超时多半是被防火墙丢弃。立刻被拒绝,说明主机可达,但端口上没服务或者被主动拒绝。

能通过控制台或其他通道登录服务器时(只读):

• ss -tlnp 并筛选 ssh:看 sshd 是否在监听,以及监听的地址。如果只监听在 127.0.0.1 或某个内网地址,外部自然连不上。
• 查看主机防火墙规则:iptables -L -n、firewall-cmd --list-all、ufw status,按系统选用。
• 如果装了 fail2ban 一类的防暴力破解工具,用 fail2ban-client status sshd 看自己的出口 IP 是否被封禁。

结果说明什么:端口在本机监听正常,外部却探测不到,问题在主机防火墙或外部安全策略。端口根本没在监听,转到服务层查 sshd。来源 IP 被封,往往是之前多次输错密码,或者自动化脚本反复尝试导致的。

需要人工确认的操作:增删防火墙规则、解封 IP、更改 SSH 端口。改规则时先加放行、确认生效后再删旧规则。不要直接清空整张规则表,否则可能把业务端口一起放开,也可能把自己彻底挡在外面。

认证层:密钥、口令、账号和权限

先看什么:ssh -v 的输出里,客户端尝试了哪些密钥,服务端接受哪些认证方式。如果有其他途径进入服务器,再看服务端的认证日志:Debian、Ubuntu 一般在 /var/log/auth.log,红帽系一般在 /var/log/secure,也可以用 journalctl 查看 sshd 的记录。这些都是只读操作。

常见原因:

• 用错了用户名或私钥文件,或者本机 SSH 配置里给这台主机指定了别的密钥。
• 服务端目录权限过宽。比如 .ssh 目录、authorized_keys 文件或家目录对其他用户可写,sshd 出于安全考虑会拒绝使用这些密钥。
• 账号被锁定、口令过期,或者服务端配置限制了登录方式,例如关闭了口令登录、禁止 root 直接登录、只允许指定用户。
• 客户端提示远端主机指纹变化。这个警告不要直接忽略。先确认服务器是否重装过、IP 是否重新分配给了别的机器,确认无误后再清除本机 known_hosts 里的旧记录。

需要人工确认的操作:修改文件权限、解锁账号、重置口令、调整 sshd 的认证配置、清除指纹记录。前几项会改变服务器上的安全设置。清除指纹看起来只动本机,但如果服务器确实被替换或被冒充,这一步等于主动跳过了提醒。

服务层:sshd 状态、配置变更和资源耗尽

先看什么:sshd 本身是否在正常运行,最近有没有人改过配置,服务器资源是否已经耗尽。

命令示例(只读):

• systemctl status sshd(部分发行版服务名为 ssh):看是否在运行、最近一次启动是否失败。
• journalctl -u sshd 查看近期日志:看有没有配置报错、端口占用或连接被拒的记录。
• sshd -t:只检查配置文件语法,不会重启服务。
• df -h 和 df -i:分别看磁盘空间和 inode 是否用满。
• free -m、uptime、top:看内存、负载和异常进程。

结果说明什么:磁盘或 inode 写满后,登录过程中写日志、建会话可能失败,表现为认证通过后立刻断开。内存耗尽时,系统可能杀掉进程,sshd 也可能受影响。最近改过 sshd 配置而服务启动失败,sshd -t 通常能直接指出出错的行。连接数过多时,sshd 会对新连接直接断开,这在遭遇大量扫描时比较常见。

需要人工确认的操作:重启 sshd、修改配置文件、删除文件释放磁盘、结束进程。这几类操作建议这样做:

1. 保留一个已登录的会话不要关,作为回退通道。
2. 改完配置先跑 sshd -t,语法检查通过再动服务,能用重载就不用重启。
3. 另开一个新窗口试登录,确认能进再关闭旧会话。
4. 清理磁盘前确认文件用途,特别是日志和数据目录,不要凭文件名猜。

把四段的命令按影响分一下级,值班时会清楚很多:只读查看类,如 ping、nc、ss、systemctl status、日志查看、df、free,可以直接跑;改配置类,如改防火墙、改 sshd 配置、改权限、解锁账号,要确认并记录;影响业务类,如重启服务、结束进程、删除文件、重启机器,要和业务负责人对齐时间与影响范围。更细的分级思路可以参考终端AI运维命令执行安全:哪些命令要人工确认?。

托管服务器:什么时候该找机房,工单写什么

服务器放在机房托管时,有些问题远程查不出来,也处理不了。出现下面几种情况,就该联系机房:

• 四段都查过,所有远程通道都进不去,也没有可用的带外管理或控制台。
• 服务器整机无响应,怀疑死机、硬件故障或供电问题。
• 怀疑网线、交换机端口、上联链路出了问题。
• 需要接显示器和键盘做本地操作,或者需要按电源键重启。

工单写得清楚,机房处理起来就快,来回确认也少。建议包含这些信息:

1. 设备信息:服务器 IP、机柜号与 U 位或设备编号。
2. 时间:最后一次正常连接的时间,以及发现故障的时间。
3. 现象:报错原文,以及是超时、拒绝、认证失败还是连上即断。
4. 已做操作:跑过哪些命令、结果如何、改过什么配置。
5. 请求范围:希望机房做到哪一步,比如只查看指示灯并拍照、检查网线、接控制台,还是按电源重启。
6. 授权与联系人:谁有权批准重启这类操作,出现意外时找谁。

哪些事机房可以代做、哪些需要客户自己处理,托管前好约定好。这部分可以对照服务器托管故障谁负责?远程协助、现场处理与自维护怎么分,以及服务器托管日常运维怎么约定?出入机房、工单、变更三件事。在润迅前海云和田心机房托管的服务器,也是按这样的思路沟通:先把现象和已做操作写清楚,再明确请机房做哪一步。

把排查固定成步骤:工具辅助,执行归人

SSH 故障常在夜里或业务高峰时出现,值班人员不一定熟悉每台服务器的历史。比较稳妥的做法是,把上面四段整理成团队自己的排查清单,并约定好哪些命令可以直接跑、哪些要找谁确认。

这一步可以用终端里的 AI 工具辅助。润迅的 MaxTerm 是终端 AI 运维工具,在这个场景里主要做三件事:把 ssh -v 输出、sshd 日志这类报错解释成能看懂的话;按四段整理排查步骤;针对当前现象给出命令建议,并提示哪些属于只读、哪些会改配置。命令要不要执行、要不要改线上配置,由运维人员确认。操作过程留下记录,方便事后复盘,也方便写进机房工单。MaxTerm 个人免费,支持 macOS 和 Windows。

行动上可以按这个顺序来:

1. 下次遇到 SSH 失败,先用 ssh -v 记下报错原文,判断属于四种表现中的哪一种。
2. 按网络、端口、认证、服务四段查,只读命令先跑完,再决定要不要动配置。
3. 改 sshd 配置或防火墙前,保留一个已登录的会话,改完用新窗口验证。
4. 托管服务器远程无法恢复时,按上面六项信息提工单,写明授权范围。
5. 想让排查步骤和命令建议在终端里随手可查,可以试用 MaxTerm 终端 AI 运维工具,并在团队里约定好命令确认和记录的规则。

→ 联系润迅,聊聊你的场景,获取适合的方案