scp의 엄격한 파일 이름 검사가 참조된 마지막 구성 요소는 거부하고 다른 구성 요소는 거부하지 않는 이유는 무엇입니까?

scp의 엄격한 파일 이름 검사가 참조된 마지막 구성 요소는 거부하고 다른 구성 요소는 거부하지 않는 이유는 무엇입니까?

경로에 슬래시가 있는 파일을 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

우분투 사람들은 사려 깊지 않거나 불완전한 패치를 내놓는 것으로 알려져 있습니다(최근에는) 귀하의 경우에는 대략이번 패치, 스냅샷에 소요된 시간을 포함하여 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.

관련 정보