技术 · 实用指南
SCP 报“Received message too long”？改 SSH 前先抓到多余字节
这个数字往往是意外文本的前四个字节被误读成 SFTP 包长度。复现同一账号和路径，抓取非交互输出，再区分启动脚本、子系统故障与有限的旧协议兼容。
“Received message too long”通常是协议症状，并不表示文件真的太大。现代 scp 默认使用 SFTP，远端多出的文本会在传输开始前被误当作二进制包长度。
按同一账号和链路建立证据表：抓字节、定位启动或子系统层、只改一个边界，再同时验证传输和交互登录。
先复现同一条失败链路
保存完整报错、命令、主机别名、用户、端口、跳板和认证方式。用同一配置开启详细日志，但遮盖密钥与令牌。交互登录成功不能证明 SFTP 路径干净。
用同一账号运行 ssh -T host /usr/bin/true。正常基线应没有 stdout。逐字保存任何 banner、echo、缺命令或启动错误，再去改文件。
把数字当作前四个多余字节的线索
SFTP 包以四字节长度开头；文本先到时，客户端可能把四个字符解释成巨大十进制长度。可把数字转成十六进制和 ASCII 作为线索，但必须与实际抓到的输出核对。
若字符像文件名、banner 或错误的一部分，就追踪那个产生者。本文核过的 macOS 案例解出“.bas”并证实来自 .bashrc；你的值可能不同。
追踪真正执行的启动文件
对 Bash，要核对 sshd 非交互路径是否读 ~/.bashrc、BASH_ENV 是否指向其他文件，以及系统 profile 或 wrapper 是否输出。必须检查实际传输账号。
把欢迎语和诊断放到经证明的交互判断后。不要在文件顶部盲目 return，因为自动任务可能依赖后续环境变量。修改后同时测试登录与无输出探针。
把启动噪声与子系统缺失分开
若无输出探针安静但 SFTP 仍失败，检查 Subsystem sftp、账号 shell、chroot、forced command 和策略日志。internal-sftp 可避开部分外部程序路径，但改 sshd_config 是全局动作。
不要在唯一会话里盲重启 sshd。先验证配置，按策略保留第二个管理会话和回退方案，再用同一账号测试。受限 shell 可能需要专门设计 SFTP。
旧 SCP 只作为有限兼容测试
现代 scp 默认是 SFTP；-O 选择旧 SCP。若 -O 成功而默认失败，记录差异，它能缩小范围但不能证明服务器配置正确。
只在明确的设备、账号或路径兼容场景记录使用 -O。旧模式会执行远端 shell，并有不同引用规则；能控制服务器时应修复 SFTP 或启动输出。
同时验证传输与登录边界
重复原命令，核对退出码、文件大小和可用时的校验和，并确认非交互探针没有多余 stdout。随后确认交互登录仍加载预期环境。
记录实际产生者、所改文件或子系统、所用协议和理由。自动化可加入“远端无输出探针”，让将来的故障成为明确回归。
