Paramiko复用现有SSH句柄长时间闲置后执行exec_command抛出EOF异常问题

• 服务端保活探测未响应导致主动断连：日志中Rejecting "keepalive@openssh.com" global request from server说明服务端定期发送保活探测校验连接有效性，paramiko默认不响应这类全局请求，服务端多次探测无应答后，会主动发送RST包断开TCP连接，这就是后续Connection reset by peer (104)错误的来源。
• 现有活跃性校验存在盲区：transport.is_active()仅校验paramiko内部维护的传输层状态标记，并非实时探测TCP连接真实状态；transport.send_ignore()发送的数据包极小，若此时服务端返回的RST包还在网络队列中未被进程接收，该方法不会抛出异常，会误判连接为正常。直到调用exec_command需要创建新SSH通道、发送业务数据时，才会触发内核返回的RST错误，抛出EOF异常。
• 确实存在SSH传输层状态标记为活跃，但实际TCP连接已断开、新通道无法创建的场景，原有校验仅覆盖传输层状态，未校验通道层的可用性。

1. 开启SSH保活机制避免服务端主动断连
   在paramiko建立连接后配置主动保活，既可以定期向服务端发送保活包，也可以正确响应服务端的保活探测，从根源避免超时断连：

# 在ssh.connect执行后添加如下代码
transport = ssh.get_transport()
transport.set_keepalive(30) # 每30秒发送一次保活包，可根据需求调整间隔

也可以修改服务端sshd_config配置，调整ClientAliveInterval、ClientAliveCountMax参数放宽超时限制。

2. 优化活跃性校验逻辑，提升校验准确率
   在原有校验基础上，新增执行空命令的逻辑，真实验证TCP连接、传输层、通道三层的可用性：

import socket
def is_ssh_active(client):
    if not client:
        return False
    try:
        transport = client.get_transport()
        if not transport or not transport.is_active():
            return False
        transport.send_ignore()
        # 新增通道可用性校验：执行空命令确认可正常调用
        _, stdout, _ = client.exec_command('exit 0', timeout=5)
        return stdout.channel.recv_exit_status() == 0
    except (EOFError, socket.error, TimeoutError, Exception):
        return False

3. 新增调用侧异常兜底
   在exec_command调用处捕获EOF、连接重置类异常，触发强制重新建连逻辑，避免单次校验漏判导致的流程失败。

内容的提问来源于stack exchange，提问作者ManiAm