[Feature] 提权通道：config 增加 sudo/su 凭据组 + exec --sudo/--su

[adrian803]

环境 / Env

• agent-ssh-cli 0.4.1（npm 发行版 + Rust native）
• 远端 util-linux：su 通道建议 >= 2.38（su -P，见下）；旧版需 fallback script 包装

动机 / Motivation

Agent 运维远端服务器时，身份切换 / 提权是刚需，但目标环境差异很大：

• 自管服务器：sudo（认证用执行者自己的密码）；
• 大公司 / 甲方：常无个人 sudo，只有共享业务账号（oracle / app / 中间件）密码或共享 root 密码，只能 su。

当前 exec 没有任何安全凭据通道。临时解法是远端落盘密码文件再重定向喂给 sudo -S——以下脚本来自本项目实际运维实践（由 AI 助手协助设计，已在真实服务器上运行验证），并非通用最佳实践，仅作现状说明：

agentsshcli exec <conn> "echo '<pw>' > /tmp/.pw && chmod 600 /tmp/.pw \
  && sudo -S -p '' <cmd> < /tmp/.pw; unlink /tmp/.pw"

该方案存在：① 明文密码进 argv（本机 shell history / ps / Agent 日志可见）；② 远端临时文件落盘残留窗口；③ 复合 shell 串无法被 commandWhitelist 精确匹配（validate_command 对整条命令正则校验）。

建议：复用项目已有的 SSH 密码本地加密机制（password 首次连接被动加密 → secrets.json ChaCha20-Poly1305 密文 → passwordRef），新增 sudo / su 双提权通道，密码只经 SSH 通道 stdin 喂给远端，全程零 argv / 零落盘。

提案 / Proposal

config.json（双通道平铺，均可选）

{
  "name": "conn-name",
  "host": "10.0.0.1",
  "username": "linxi",
  "password": "",
  "passwordRef": "agentsshcli:conn-name",

  // sudo 通道（可选；多数场景 sudoPassword 可留空，自动 fallback SSH 密码）
  "sudoUser": "root",
  "sudoPassword": "",
  "sudoPasswordRef": "agentsshcli:conn-name:sudo",

  // su 通道（可选；suUser + suPassword 需成对）
  "suUser": "oracle",
  "suPassword": "",
  "suPasswordRef": "agentsshcli:conn-name:su"
}

用法

# sudo：密码取用优先级 sudoPasswordRef → SSH passwordRef（sudo 认证=自己密码的常见语义）→ 报错
agentsshcli exec --sudo conn "systemctl status app"

# su：切共享业务账号（suPassword 必配；suUser 缺省 root）
agentsshcli exec --su conn "ls -la ~/appdata"

凭据迁移规则

sudoPassword / suPassword 明文首次写入 → 首次对应 flag 连接时加密存入 secrets.json → 明文置空、写入 sudoPasswordRef / suPasswordRef；更新密码 = 重新填明文，下次连接自动覆盖（与现有 password 机制完全一致）。

验收标准 / Acceptance

• --sudo / --su 时密码不出现在任何 argv / 本机与远端 shell history / 进程列表，远端零落盘
• sudoPasswordRef 缺失时 --sudo 自动 fallback 复用 passwordRef 解密结果（SSH 密码认证场景免重复配置）
• 密码经 SSH channel stdin（data() + eof()）喂入，命令包装：sudo → sudo -u <user> -S -p '' <cmd>；su → su -P -c '<cmd>' <user>
• requiretty（RHEL/CentOS 7 默认）与旧 util-linux（无 su -P）环境自动 fallback script -qec 包装
• 不传 --sudo / --su 行为与现状完全一致（默认安全，零回归）；两 flag 互斥；凭据缺失明确报错
• --json 模式透传真实 exitCode / stdout / stderr，认证失败如实返回非零码
• secrets.json 中 SSH / sudo / su 三组密文 key 互不覆盖（agentsshcli:<name> / :sudo / :su）

实现方向 / Implementation notes

参考 native/src/main.rs（@ main）：

• 加密基元可直接复用：encrypt_password / decrypt_password（L770 / L789，ChaCha20-Poly1305，与密码语义无关）
• 迁移逻辑照抄 migrate_plain_password_for_connection（L847，泛型 serde_json::Value 操作字段）；注意 ref key 命名空间隔离，避免 secrets.json HashMap insert 覆盖 SSH 密码密文
• 传输层：execute_remote_command_with_session_async（L1841）当前只消费 stdout/stderr，从不写 channel stdin；需补一次 channel.data() + eof()（一次性喂密码，无需交互 pty 桥）
• 白名单兼容：validate_command（L1504）校验用户原始命令，sudo/su 前缀为 CLI 注入的受信包装，不参与正则匹配
• 新字段遵循 RawConnection 的 #[serde(rename_all = "camelCase")]，勿用小写

兼容与安全边界 / Notes

• 建议依赖 util-linux su -P（>= 2.38，stdin 非 tty 时自动关 ECHO 防回显）；旧版 fallback script -qec
• 不做 --sudo-password <明文> 之类的便捷参数（会把问题引回 argv）
• su 到 root 需要 root 密码，本特性仅提供安全通道，凭据托管责任在调用方

我可以尝试提交 PR

如果本特性方向认可，我可以尝试提交 PR：实现已拆分为可独立合入的提交（commit 1：凭据层 = 数据模型 + sudo/su 迁移 + 解密；commit 2：执行层 = 命令包装器 + channel stdin + 远端探测；commit 3：README 与测试），代码位置已按上文定位。也可以先只合入凭据层（commit 1），为后续能力打底。

参考 / workaround

上述远端落盘方案为当前临时做法，特性落地后退役。

[sleepinginsummer]

这个功能方向是可行的：现有的 SSH 密码加密/迁移机制可以复用于 sudo、su 凭据，russh channel 也支持在 exec() 后通过 data() 写入密码。密码不进入 argv、不经过 shell history、不在远端落盘，这个目标值得采纳。

不过，当前提案中的执行层有几个关键细节需要调整，否则会出现部分命令没有提权、旧系统 fallback 失效、密码回显或输出语义不一致的问题。

1. sudo 必须让提权后的 shell 执行整条命令

提案中的包装：

sudo -u <user> -S -p '' <cmd>

只对简单命令可靠。远端 shell 会在执行 sudo 之前解析 &&、管道和重定向。例如：

sudo -u root -S -p '' id && cat /root/file

这里只会以 root 执行 id，cat /root/file 仍由原 SSH 用户执行。类似地：

sudo -u root -S -p '' cat /root/file > /root/copy

重定向由外层普通用户 shell 建立，可能直接权限失败。

建议让提权后的 shell 接收完整命令：

sudo -S -p '' -u <user> -- sh -c '<shell-escaped-command>'

validate_command 仍只校验用户提交的原始命令；校验通过后，再由 CLI 添加受信任包装。

2. su -P 的含义和版本判断需要修正

-P 是 util-linux su 的 --pty：它会创建一个内部伪终端，并在外部 stdin 为 pipe 时关闭内部 PTY 的 ECHO，避免通过管道输入的内容被回显。它不是单纯的“关闭密码回显”参数。

另外，su -P 需要 util-linux >= 2.38 这个边界似乎不准确；util-linux 2.34 的发布说明已经提到 su --pty。不同发行版也可能回移植功能，因此不建议按版本字符串判断。更可靠的方法是在已认证的 SSH 会话中探测：

su --help

确认是否支持 -P/--pty，然后选择执行路径。

3. SSH PTY 与 su -P 的内部 PTY 是两层不同机制

sudo 遇到 Defaults requiretty 时，需要 SSH channel 在 exec() 前调用 request_pty()；su -P 则由 su 自己创建内部 PTY，通常不要求外层 SSH channel 也分配 PTY。

需要注意：SSH PTY 模式下，部分 SSH 服务端会把 stderr 合并到终端输出。此时真实 exitCode 仍可透传，但 --json 未必还能严格区分 stdout/stderr。因此，“requiretty 自动兼容”和“stdout/stderr 在所有环境下严格分离”应通过 RHEL/CentOS 实机验证，不能仅靠单元测试承诺。

4. data(password + "\n") 后调用 eof() 会关闭目标命令 stdin

密码应至少发送为：

<password>\n

然后调用 eof()，否则 sudo/su 可能持续等待换行。但 eof() 同时意味着目标命令无法继续读取 stdin，例如以下场景不能工作：

read value
cat > /root/file

当前 agentsshcli exec 本身没有交互式 stdin，因此这不属于现有功能回归；建议明确第一版 --sudo/--su 仅支持非交互命令，不支持提权后的命令继续读取 stdin，也不支持交互 shell。

5. script -qec fallback 本身也需要能力探测

旧版 util-linux 的 script 参数并不完全一致。有些版本支持 -c，但未必支持 -e，或者不能按照预期传递子命令退出码。直接写死：

script -qec '<command>' /dev/null

可能在最需要兼容的旧系统上再次失败。

建议在 su 不支持 -P 时继续探测：

script --help

只有确认所需参数及退出码语义后才使用 fallback。无法满足安全执行和退出码透传时，应明确报“远端不支持安全 su 通道”，不要静默使用行为不确定的包装。

6. 用户名和原始命令必须分别进行安全处理

sudoUser/suUser 不能作为任意字符串直接拼接到 shell 命令，应限制为合法 Unix 用户名，避免类似下面的配置改变命令结构：

{"sudoUser":"root; touch /tmp/unexpected"}

传给 sh -c 或 su -c 的原始命令也必须通过统一的 POSIX shell 参数转义函数处理。简单地在命令两侧添加单引号无法处理命令自身包含单引号的情况，例如：

echo 'hello world'

建议把“用户名校验 + shell 单参数转义”做成独立、可单测的函数，并覆盖单引号、换行、$()、反引号、管道、重定向和 && 等输入。

7. sudo/su 的密码 fallback 语义需要保持区分

sudo 默认验证当前 SSH 登录用户自己的密码，因此：

sudoPasswordRef -> SSH passwordRef -> 明确报错

这个优先级合理。SSH 使用私钥登录时，CLI 不知道登录用户的系统密码，所以仍需单独配置 sudoPassword。

su 验证的是目标用户密码，例如 su oracle 输入 oracle 密码，su root 输入 root 密码，因此 suPasswordRef 不应 fallback 到 SSH 登录密码。

建议实现顺序

1. 凭据模型、命名空间隔离、明文迁移和解密；
2. --sudo 非 PTY 执行及完整命令包装；
3. sudo requiretty 探测/兼容；
4. --su 与 su -P 能力探测；
5. script fallback；
6. 单元测试和真实 Linux 冒烟测试。

总体支持采纳这个功能方向，但建议把以上边界纳入验收标准。特别是完整命令提权、shell 转义、PTY 下的 stdout/stderr 行为，以及旧版 script 的退出码透传，需要在合入前验证。