Quoting

為什麼 scp 的嚴格文件名檢查拒絕引用最後一個組件而不拒絕其他組件?

  • February 12, 2019

當我嘗試在其路徑中使用斜杠 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。

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.

引用自:https://unix.stackexchange.com/questions/499958