Paramiko中SSH信号的传播实现及Web终端命令审核方案问询

• 信号传递的核心逻辑：Paramiko遵循SSH协议（RFC 4254）规范，信号通过已建立的加密通道以特定消息包形式传递。本地端发起的信号（如SIGINT、SIGTERM）会被封装为SSH_MSG_CHANNEL_REQUEST类型的请求，请求类型标记为signal，附带具体信号名称后发送给远程SSH服务器。
• 具体实现流程：
  1. 调用Channel.send_signal(signal_name)方法时，Paramiko构造符合协议的信号请求包，通过加密会话发送至远程服务器。
  2. 远程服务器接收请求后，将信号转发给当前通道绑定的进程（如交互式shell或exec启动的命令进程）。
  3. 远程进程处理信号后，将结果（如进程终止、输出变更）通过通道回传至Paramiko，再由Paramiko传递给本地应用。
• 交互式shell的特殊处理：使用invoke_shell()创建的交互式shell中，键盘事件（如Ctrl+C）会被Paramiko转化为对应信号，发送给远程shell，再由shell转发给前台运行的进程，实现和本地终端一致的信号响应逻辑。

核心问题拆解 #

使用invoke_shell()的交互式模式时，前端历史命令由本地组件缓存，后端无法直接捕获；且键盘输入会直接转发至远程主机，缺少中间拦截审核的环节。

可行解决方案 #

方案1：替换为非交互式命令执行模式 #

放弃invoke_shell()，改用exec_command()执行单条命令，完全掌控命令流转：

• 前端将用户输入（包括选中的历史命令内容）通过POST请求发送至Django接口。
• 后端先执行审核逻辑，示例代码：

  FORBIDDEN_OPERATIONS = ['ping', 'wget', 'curl', 'mount', 'umount', 'dd', 'rm -rf']
  def validate_command(command):
      cmd_lower = command.lower()
      for op in FORBIDDEN_OPERATIONS:
          if op in cmd_lower:
              return False, f"禁止执行包含「{op}」的操作"
      return True, "命令合法"
  

• 审核通过后调用exec_command()执行命令，捕获输出后返回给前端；不通过则直接返回错误提示。

方案2：保留交互式体验，新增代理拦截层 #

若需保留交互式shell，可在后端做输入代理拼接与审核：

• 前端不再直接转发键盘事件，而是将每一次按键输入发送至Django接口。
• 后端为每个用户会话维护命令缓冲区，拼接输入字符直到用户按下回车，触发审核逻辑。
• 审核通过后再将完整命令发送至远程shell通道；不通过则终止命令发送，返回错误提示给前端。

方案3：前端历史命令的后端同步 #

• 用户执行新命令后，前端将命令内容发送至后端，存储到Redis或数据库（以用户ID为标识维护历史列表）。
• 用户调用历史命令时，前端从后端接口拉取历史列表，选中后将命令内容发送至后端审核，而非直接触发键盘事件。

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