为什么 scp 的严格文件名检查拒绝引用最后一个组件而不是其他组件？

Question

当我尝试 scp 路径中带有斜杠的文件时，该路径为本地主机引用，最后一个路径组件为远程主机另外引用，例如scp host:"a/b/'c'" .，它失败了

protocol error: filename does not match request

除非我使用该-T选项。但是，如果引用了任何其他路径组件，例如scp host:"a/'b'/c" .，它就可以工作。此外，如果本地主机的路径没有被引用，例如scp host:a/b/'c' .，它也可以工作。

手册页文件-T为：

禁用严格的文件名检查。默认情况下，将文件从远程主机复制到本地目录时，scp 会检查接收到的文件名是否与命令行上请求的文件名匹配，以防止远程端发送意外或不需要的文件。由于各种操作系统和 shell 解释文件名通配符的方式不同，这些检查可能会导致所需文件被拒绝。此选项以完全信任服务器不会发送意外文件名为代价禁用这些检查。

我不明白这个描述如何解释我看到的行为。scp 行为的基本原理是什么？有没有办法禁用这个“功能”？

我正在运行 Ubuntu 16.04，而远程主机正在运行 Ubuntu 12.04。

Answer 1

Ubuntu 人以推出不考虑/不完整的补丁而闻名（最近的例子）；就您而言，这是关于此 patch 的，该补丁发布时间不到 3 周，包括在快照中花费的时间：

check in scp client that filenames sent during remote->local directory
copies satisfy the wildcard specified by the user.

This checking provides some protection against a malicious server
sending unexpected filenames, but it comes at a risk of rejecting wanted
files due to differences between client and server wildcard expansion rules.

For this reason, this also adds a new -T flag to disable the check.

reported by Harry Sintonen
fix approach suggested by markus@;
has been in snaps for ~1wk courtesy deraadt@

OpenBSD-Commit-ID: 00f44b50d2be8e321973f3c6d014260f8f7a8eda

这还没有准备好迎接黄金时间（它天真地使用fnmatch(3)文件的基本名称）并且已经必须修复以允许大括号扩展。

结论：这是一个错误；它可能迟早会被修复；或者如果没有，请准备好始终禁用这个新的错误功能-T。