技術 · 實用指南
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。随后确认交互登入仍加载预期环境。
记录實际产生者、所改檔案或子系統、所用協定和理由。自动化可加入“远端无輸出探针”，让将来的故障成為明确回归。
