☰

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

tag-icon • tag-icon quoting filenames scp
为什么 scp 严格的文件名检查会拒绝引用的最后一个组件而不是其他组件？

当我尝试 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。

答案1

Ubuntu 的人们以推出不考虑问题/不完整的补丁而闻名（最近例子）；就你而言，大约是这个补丁，不到 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。

相关内容