服务器突然 ssh 连不上了，可能是什么问题？

面试记录 2026-10-22

题目：服务器突然 ssh 连不上了，可能是什么问题？

难度：low

标签：practice/debug, linux/sshd, difficulty/low

评分：⭐⭐⭐☆☆（3/5）

我的回答

根据不同服务部署情况有不同的方案;

首先如果是云服务,那么登录对应服务商的服务后台,查看服务状态是否正常可用,看是否能通过云服务平台登录到机器,而不是通过ssh;

在本地检查网络链接,通过telnet 检查对应的ssh端口是否还可以访问,网络是否可达,默认是22,但是有些时候会修改,具体看服务方面开启的配置;

如果网络端口访问不通,而云服务平台的机器是正常的,那么可能中间的安全策略导致服务无法访问,或者本地网络到云服务的安全网络是不通的可以进行检查排查,是否未登录VPN等;

如果发现机器活着无法登录,那么排查密钥是否正确,是否有人调整了服务器配置,或者你的密钥出现了问题;

可以通过云服务器的管理平台登录进去检查具体信息;

点评

优点：有真实运维视角，先分层再定位——云控制台 → 本地网络 → 安全策略 → 密钥/配置，并且明确用了控制台 VNC 作为带外通道，这是很多人漏掉的关键一步；还注意到 sshd 端口不一定是 22。

不足：① 少了"机器活着但登不上"的高频内因：sshd 进程挂了、磁盘写满、系统负载过高 fork 失败、iptables/firewalld 误封、fail2ban 拉黑、PAM/limits 配置、/etc/nologin；② 没有给出每层的判定证据（超时 vs 拒绝 vs 握手后断开，三者指向完全不同的原因）；③ 没提日志这个最终定位手段（sshd 日志、/var/log/secure、dmesg OOM Killer）。

补充：telnet 22 的三种结果要分开说：Connection timeout = 网络/安全组层面；Connection refused = 机器可达但 sshd 没监听；能连上但认证失败/立即断开 = sshd 正常但认证、PAM、磁盘或 shell 配置有问题。云上还要注意安全组与主机内防火墙是两层，安全组放通不代表 firewalld 放通。

完整讲解

第一部分：知识重点剖析

核心考点定位：考察「分层排查」的思维纪律——能不能把"连不上"拆成网络层、主机层、服务层、认证层，并为每层找到成本最低的观测手段。

知识点拆解：

1. 带外通道优先：云厂商控制台/VNC/IPMI 是唯一不依赖 sshd 与网络策略的入口。能通过控制台登进去，问题范围立刻从"整机失联"缩小到"sshd 或网络策略"；进不去才需要怀疑内核 panic、硬件、宿主机故障。
2. 三层网络判定：安全组/ACL（云层）→ 主机防火墙 iptables/firewalld（OS 层）→ sshd 监听（进程层）。telnet/nc 的返回码是分界线：timeout 查前两层，refused 查进程层，connected 查认证层。
3. 主机层高频内因：磁盘 100%（sshd 无法写 utmp/session 文件，登录后立刻被踢）、内存耗尽触发 OOM Killer 干掉 sshd、负载过高导致 fork 失败（-bash: fork: Cannot allocate memory）、/etc/nologin 存在、/etc/security/limits 或 PAM 配置错误、inode 耗尽。
4. 认证层：密钥权限必须 600、authorized_keys 不能 group-writable、SELinux 上下文错误、PermitRootLogin/AllowUsers 被改、fail2ban 或云 WAF 把来源 IP 拉黑。
5. 日志是终点：journalctl -u sshd、/var/log/secure、/var/log/auth.log、dmesg -T | grep -i oom，基本能一锤定音。

按「底层原理 → 设计权衡 → 工程实践」递进排列。

第二部分：考察方向与延伸递进

考察方向：

• 深度：是否理解"网络可达"与"服务可用"是两层，能否用返回码区分。
• 广度：能关联到云网络（安全组 vs 防火墙）、Linux 资源（磁盘/inode/内存/负载）、PAM 认证体系、监控告警。
• 应用：线上事故中如何在不重启的前提下恢复访问，以及如何做预防（跳板机、监控 sshd、磁盘水位告警）。

延伸递进面试题：

1. 磁盘写满为什么会表现为 ssh 登录失败？

• 解答要点：sshd 登录要写 utmp/wtmp 与用户 session 文件，写失败会导致认证后立即断开；root 保留块耗尽后 root 也可能写不进去；同时 rsyslog 写不了日志会让排查更难。

1. telnet 端口通但登录秒断，怎么定位？

• 解答要点：ssh -vvv 看卡在哪个阶段；查 /var/log/secure、/etc/nologin、PAM 配置、用户 shell 是否被改成 /sbin/nologin、磁盘与 inode。

1. 怎么预防这类故障？

• 解答要点：跳板机/堡垒机 + 多可用区、控制台带外通道演练、磁盘与 inode 水位告警、sshd 存活探针、fail2ban 白名单、密钥轮换与权限基线检查。

第三部分：面试者参考回答（三步法口语化，300-400 字）

【一句话结论】

面试官您好，SSH 连不上我会按"带外通道 → 网络 → 主机 → sshd → 认证"五层往下收，而不是直接重启。

【三点展开】

第一，先用云控制台或 VNC 登进去，这是唯一不依赖 sshd 的通道。能进去就说明机器活着，问题在 sshd 或网络策略；进不去再怀疑内核、硬件或宿主机。

第二，用 telnet 看返回值区分层次。timeout 是网络或安全组没放通；refused 是机器可达但 sshd 没监听，去看进程和端口；能连上却认证失败或秒断，就查密钥权限、/etc/nologin、PAM 和磁盘。

第三，主机层最常见的其实是资源问题：磁盘写满、inode 耗尽、内存不足被 OOM Killer 杀掉 sshd、负载过高 fork 失败。最后看 sshd 日志、/var/log/secure 和 dmesg，基本能定死原因。

【一句边界】

当然，如果是安全组被误改或 fail2ban 拉黑了来源 IP，机器本身完全正常，只在机器内部查是永远查不出来的——所以一定要先确认外部网络路径。