[Plugin] astrbot_plugin_ssh

[HSOS6]

插件信息

{
  "name": "astrbot_plugin_ssh",
  "display_name": "远程SSH执行器",
  "desc": "一个功能弱小的 AstrBot 插件，允许您通过聊天连接远程 SSH 服务器并执行命令。支持交互式 Shell 会话、状态保持、LLM 函数调用，并具备一定的安全保护机制。",
  "author": "5060ti个马力的6999",
  "repo": "https://github.com/HSOS6/astrbot_plugin_ssh",
  "tags": [
    "ssh",
    "远程控制",
    "服务器"
  ],
  "social_link": "https://github.com/HSOS6"
}

插件检查清单

• 我的插件经过完整的测试
• 我的插件不包含恶意代码
• 我已阅读并同意遵守该项目的 行为准则。

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_ssh

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

代码质量与编码规范问题

• 违规/多余的日志模块导入：顶部 import logging 在本文件中未使用，且框架规范要求日志“必须且只能”使用 from astrbot.api import logger（避免引入/使用 Python 内置 logging）。即便未调用也建议移除以符合规范与减少误用风险。
• 未使用的导入：import logging 未使用（同上）；from astrbot.api import logger 已足够。
• 指令文档与实现不一致：ssh_cmd docstring 写的是“/ssh disconnect”，实现却是 cmd == "out" 才断开，容易误导使用者。
• 异常处理写法不佳：except Exception as e: ... raise e 会丢失部分异常上下文（traceback 链接信息）；应使用 raise 原样抛出。

功能实现与逻辑正确性问题

• 无效/不可达的异常分支：ssh_cmd 中捕获 ValueError 并提示“插件未配置”，但 _get_or_create_session() 从未抛出 ValueError；该分支属于死代码，实际配置缺失会走到其它 Exception 分支，提示不准确。
• 会话“断开”逻辑与数据结构不一致：/ssh out 中尝试关闭 self.sessions[user_id]["process"]，但代码从未创建/维护 process 字段，属于不一致逻辑，容易产生维护误解。
• 输出解析不健壮：marker = "___PWD_MARKER___" 的解析方式存在多种边界问题：
  • 若命令输出中包含 marker 字符串（用户 echo ___PWD_MARKER___，或某些程序输出包含该片段），split(marker) 会被干扰，cwd 解析错误。
  • 若出现多个 marker，parts[1] 不一定是预期的 pwd 输出，且其余部分被忽略。
• 目录处理不健壮：full_cmd = f"cd {cwd} && {cmd}; ..." 未对 cwd 做任何 shell 转义/引用：
  • 当路径包含空格、引号等字符时会 cd 失败或产生意外解析。
  • cwd 来源于远端 pwd 输出（可被构造/污染），最终被拼进 shell 命令串，存在被“二次注入/破坏命令结构”的风险（尤其是用户先通过命令把工作目录切到包含特殊字符的路径）。

安全漏洞与最佳实践问题

• 高危：主命令入口未做任何安全过滤：/ssh 命令（ssh_cmd）对 cmd 完全不经过 _is_safe_command()，而是直接远程执行。即使限制为 ADMIN，也属于“高权限远程命令执行”能力，风险极高（误操作、账号被盗、群管理误用等）。
• LLM 工具的权限控制组合无效：ssh_tool 同时使用了 @filter.permission_type(filter.PermissionType.ADMIN) 和 @filter.llm_tool(...)。按你的框架规则，这种组合是无效的，将导致你期望的权限控制不生效（潜在地让 LLM tool 被非管理员间接调用）。
• 主机密钥校验被禁用（MITM 风险）：asyncssh.connect(... known_hosts=None ...) 禁用 known_hosts 校验，会使连接易受中间人攻击；在生产环境中属于明显安全隐患。
• 命令黑名单策略易绕过：_is_safe_command() 仅做正则黑名单匹配，存在明显绕过空间：
  • 大小写、额外空白、转义、换行、子 shell、变量拼接等都可绕过（如 rM -Rf /、rm$IFS-rf、sh -c 'rm -rf /' 等）。
  • 未覆盖大量高危命令/组合（如 : > /etc/passwd、chmod -R、chown -R、kill -9 -1、useradd、iptables 等）。
• 敏感信息泄露到日志：logger.info(f"Final command to execute: '{cmd}'") 会把完整命令写入日志；命令中可能包含 token、密码、内网信息等，造成二次泄露风险。
• 资源关闭不完整：多处仅调用 conn.close()，但通常还需要等待连接完全关闭（例如 await conn.wait_closed()）以避免资源悬挂；清理线程/任务也未处理（见下文）。

可维护性与可读性问题

• 在 __init__ 中创建后台任务但不保存引用/不支持取消：asyncio.create_task(self._cleanup_sessions()) 未保存 task 引用，也没有在插件卸载/关闭时取消任务，可能导致：
  • 插件重载后残留多个清理任务在跑。
  • 事件循环关闭时出现“Task was destroyed but it is pending”类警告。
• 会话锁粒度过大：_get_or_create_session() 在持有 self.lock 时执行 await asyncssh.connect(...)（网络 I/O）。
  • 这会阻塞所有需要该锁的协程（包括其他用户的新建会话、log/out、清理协程），在网络抖动时放大延迟，甚至造成级联拥塞。
  • 同类问题也出现在 _cleanup_sessions()：持锁期间逐个 conn.close()，使锁占用时间不可控。

潜在缺陷、性能与异步最佳实践问题（仅指出网络 I/O 相关）

• 持锁等待网络 I/O（严重的并发瓶颈）：如上所述，asyncssh.connect() 在锁内等待网络返回是典型异步反模式，会显著降低并发性能，并可能造成“看似卡死”的体验。
• 清理逻辑可能受单个连接影响：_cleanup_sessions() 中在锁内遍历并关闭连接；若某个连接关闭过程卡顿/异常处理不当，会拖慢整个清理周期并阻塞其他对 sessions 的操作。

---

代码评审团

人物一（Linus Torvalds，毒舌但务实）：
你把 asyncssh.connect() 放在锁里面 await，这就是把“全局大锁”当成交通锥摆在高速路正中间。网络一抖，所有人一起堵车。把“检查/写入 sessions”的临界区缩到最小：锁内只做字典判断与占位，锁外做连接，成功后再锁内回填，别拿锁当保险箱。

人物二（Grace Hopper，偏工程与可验证性）：
你用 marker 解析 pwd 的做法太脆弱了：输出里只要出现 marker 就会污染状态，导致后续命令在错误目录执行。应当让“获取 cwd”与“命令输出”在协议层可区分：至少使用更难碰撞的随机 token，并对分段数量做严格校验；同时对 cwd 做可靠引用/转义，否则路径里一个空格就能让行为不可预测。

人物三（Guido van Rossum，关注可读性与边界）：
/ssh disconnect 文档写着断开，实际却是 out；ValueError 分支永远走不到；还出现了从未定义的 process 字段——这些都会让维护者对代码产生错误心理模型。把命令子命令（out/log/exec）做成清晰的分派结构，并确保异常分支与数据结构是“可证明存在”的，代码自然会更可靠。

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[HSOS6]

更新的1.2.0修复了一些安全问题

[astrbot-plugin-copybara]

插件信息已同步到集合仓库。
PR: AstrBotDevs/AstrBot_Plugins_Collection#254
已自动合并 PR #254

该插件已上架。
This plugin is now published.