パスにスラッシュがあるファイルをscpしようとすると、ローカルホストのパスが引用され、リモートホストの最後のパスコンポーネントも引用されます。たとえば、次のようにscp host:"a/b/'c'" .失敗します。
protocol error: filename does not match request
そのオプションを使用しない限り-T。しかし、他の人たとえば、パスコンポーネントが参照され、機能scp host:"a/'b'/c" .します。また、パスが次のような場合いいえたとえば、localhost参照の場合にscp host:a/b/'c' .機能します。
マニュアルページ-Tのドキュメントは次のとおりです。
厳密なファイル名解決を無効にします。デフォルトでは、リモートホストからローカルディレクトリにファイルをコピーすると、scpは受信したファイル名がコマンドラインから要求されたファイル名と一致することを確認して、リモート側から予期しないファイルや不要なファイルを送信するのを防ぎます。さまざまなオペレーティングシステムとシェルがファイル名のワイルドカードを解釈する方法が異なるため、これらの検証は必須ファイルを拒否する可能性があります。このオプションは、サーバーが予期しないファイル名を送信しないという確信に基づいて、これらのチェックを無効にします。
この説明が私が見ている動作をどのように説明するのかわかりません。 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。