记一次堡垒机 SSH 超时致运维无法紧急操作的排查

Wed, 21 Feb 2024 15:30:00 +0000

问题背景

公司内网部署了一台 JumpServer 堡垒机，所有运维人员通过该堡垒机 SSH 跳转到生产服务器。堡垒机配置了完整的会话审计（录像 + 日志），日均登录次数约 200 次。

故障现象

下午 3:10，线上 Redis 集群发生主从切换异常，需要紧急登录服务器切换 VIP。运维人员通过堡垒机 SSH 登录目标服务器时，发现从输入 ssh 命令到出现密码提示，卡顿了 30 秒以上，登录过程极度缓慢。多位运维人员同时遇到相同问题，严重拖慢了故障处理进度。

登录行为在 putty 的表现：Connecting to 10.x.x.x... 长时间停留在该状态，且无任何超时报错。

排查过程

第一步：网络连通性检查

首先排查是否是网络问题：

1
2

$ ping 10.x.x.x -c 10              # 延迟正常，<1ms
$ telnet 10.x.x.x 22                # 端口秒开，排除TCP握手问题

网络层面一切正常，问题锁定在堡垒机本身或 SSH 服务端。

第二步：堡垒机资源检查

1
2

$ top                                # CPU idle >95%，Memory available >4GB
$ iostat -x 1                       # 磁盘IO await <5ms，无异常

堡垒机本身资源非常充裕，不是性能瓶颈。

第三步：SSH 客户端详细调试

使用 ssh -vvv 查看详细交互过程：

$ ssh -vvv user@10.x.x.x
...
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
# <--- 此处卡顿30秒 --->
Last login: Wed Feb 21 15:28:00 2024 from 10.x.x.y

卡顿发生在认证成功后、进入交互会话之前——此时 SSH 守护进程会做两件事：更新登录日志（wtmp/lastlog）和PAM 会话模块初始化。

第四步：wtmp 锁定

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
...
/dev/sda1        20G   19G     0 100% /var

/var 分区 100% 占满。进一步排查：

1
2
3

$ ls -lhS /var/log/jumpserver/ | head -5
-rw------- 1 jumpserver jumpserver 8.2G Feb 21 15:28 session_replay_20240221.log
-rw------- 1 jumpserver jumpserver 5.1G Feb 20 23:59 session_replay_20240220.log

堡垒机的会话审计录像日志堆积了超过 15GB，而 /var/log/wtmp 也受分区满载影响无法写入：

1
2
3

$ tail -f /var/log/secure | grep wtmp
Feb 21 15:12:34 bastion sshd[4823]: pam_lastlog(sshd:session): \
  unable to open /var/log/wtmp: No space left on device

pam_lastlog.so 在尝试写入 wtmp 时阻塞，导致 SSH 会话建立被严重拖慢。

解决方案

紧急处理：

1
2
3

# 临时关闭 pam_lastlog 模块
sed -i 's/^session.*pam_lastlog.so/#&/' /etc/pam.d/sshd
systemctl restart sshd

重启 sshd 后，登录速度恢复正常（<2秒）。

清理旧审计日志：

1
2

find /var/log/jumpserver/ -name "*.log" -mtime +7 -exec gzip {} \;
find /var/log/jumpserver/ -name "*.log.gz" -mtime +30 -delete

配置日志轮转：创建 /etc/logrotate.d/jumpserver 并配置按天轮转、保留 30 天。

根因分析

直接原因：JumpServer 的会话审计录像日志未做轮转和清理，占满 /var 分区，导致 pam_lastlog.so 在尝试更新 wtmp 时长时间阻塞。

深层原因：堡垒机初始部署时未规划日志分区隔离——/var 分区与系统盘共享 20GB 空间，且未配置任何 logrotate 策略。对于每天产生数百 MB 审计录像的堡垒机来说，20GB 很快就会被耗尽。

预防措施

磁盘分区隔离：堡垒机单独挂载一块大容量磁盘用于审计日志存储
配置 logrotate：审计日志按天轮转，保留 30 天，超过后自动删除
磁盘容量监控：/var 分区使用率 >80% 时触发告警
pam_lastlog 优化：将 silent 参数添加到 pam_lastlog.so 行，避免因 wtmp 写入失败阻塞登录
定期巡检：每月检查堡垒机的磁盘和日志状态

总结

堡垒机作为运维入口，其稳定性直接关系到故障应急效率。/var 分区满了看似是小问题，但在 SSH 登录这种场景下会被放大为严重的业务影响。任何时候，关键基础设施的磁盘分区和日志轮转都应该在部署时做好规划，而不是等到故障爆发再救火。

堡垒机 on Zero Day Notes