这问题挺典型的，核心是不同SCP客户端实现和嵌入式SSH栈的兼容性差异，我来拆解下可能的原因：

• 客户端协议交互逻辑的区别
  GitBash自带的scp是OpenSSH的实现，而pscp属于PuTTY工具家族，两者在SCP会话的收尾流程上有明显不同：

  • OpenSSH的scp在传输完成后，可能会等待服务器返回额外的会话确认信号，或者默认启用了连接复用特性（后台保持连接供后续命令复用），但InterNiche作为定制硬件的轻量SSH栈，大概率没实现这些扩展的协议交互逻辑，导致客户端一直处于等待状态，连接无法自动关闭。
  • pscp的-scp模式则采用了更简洁、基础的SCP协议流程，传输完成后主动发起会话关闭请求，刚好适配InterNiche栈的处理能力，所以能正常结束连接。

• OpenSSH scp的默认连接复用特性
  GitBash里的OpenSSH scp默认可能开启了ControlMaster连接复用功能，这个特性会把SSH连接留在后台复用，但InterNiche栈可能不支持这种机制，导致传输完成后连接被挂住。你可以试试在GitBash里显式禁用这个特性：

  scp -o ControlMaster=no user@xxx.xxx.xxx.xxx:\path\to\file /local/file/path
  

  如果这样操作后连接能正常关闭，那基本就是连接复用的兼容性问题了。

• 嵌入式SSH栈的协议支持局限性
  InterNiche作为嵌入式场景的SSH栈，为了轻量化通常只实现了SCP协议的核心功能，而OpenSSH的scp会使用一些协议扩展（比如额外的状态查询、错误反馈机制），当InterNiche栈无法响应这些扩展请求时，客户端就会一直等待，导致连接保持打开。

排查建议 #

可以分别用 verbose 模式运行两个命令，对比协议交互的细节：

• GitBash scp：scp -v user@xxx.xxx.xxx.xxx:\path\to\file /local/file/path
• pscp：pscp -v -scp user@xxx.xxx.xxx.xxx:\path\to\file /local/file/path
  通过对比两者的输出，你能看到OpenSSH scp在传输完成后到底在等待什么响应，而InterNiche栈没有返回，这样就能精准定位问题点。

内容的提问来源于stack exchange，提问作者user7345878