scp는 안전하지 않습니까? sftp로 바꿔야 할까요?

약간 "안전하지 않음"

그것예전에는scp -TOpenSSH 8.0에 추가되기 전에는 약간 "안전하지" 않았지만 여전히 그렇습니다.예사용하기에는 약간 "안전하지 않습니다" scp -r.

다른 답변에서 말했듯이 scp는 클라이언트가 요청한 내용을 받았는지 이전에 확인할 수 없기 때문에 안전하지 않다고 주장됩니다. scp가 유효성 검사에 실패하는 이유는 서버 환경(서버 상태 포함)에서 실행되는 셸 코드를 사용하여 요청이 이루어지기 때문입니다.

예를 들어 서버의 셸이 확장 글로브를 사용하여 zsh로 설정되어 있고 빠른 액세스를 위해 프로젝트 디렉터리를 동적으로 명명된 zsh 디렉터리로 설정했다고 가정해 보겠습니다. Rails 프로젝트에서 파일을 가져오려면부자, 다음을 통해 얻을 수 있습니다.

scp server:~foo/config/database.yml .

내 서버의 zsh 확장자 ~foo는 ~/work-for/client/$client_name/foo.

서버의 최신 일반 파일 10개를 가져오려면 다음과 같이 할 수 있습니다.

scp server:'*(.oc[1,10])' .

서버에 일반 bash가 있는 경우 다음을 수행할 수 있습니다.

scp server:'$(ls -t | head -10)' .

콘텐츠에 foo 패턴이 있는 파일을 가져오려면 다음을 수행할 수 있습니다.

scp server:'$(grep -l foo *)' .

scp 클라이언트는 셸 코드를 사용하여 이러한 요청을 확인할 수 없습니다. 그러나 걱정스럽게도 이를 통해 악의적인 서버가 다음과 같이 응답할 수 있습니다.

scp -r server:foo/ ~

적용 범위 .ssh/authorized_keys. 서버 쉘 코드 의 관점 scp에서 누가 무엇을 아는지 평가할 것입니다.foo/

입력하다 scp -T:

-티엄격한 파일 이름 확인을 비활성화합니다. 기본적으로 원격 호스트에서 로컬 디렉터리로 파일을 복사할 때 scp는 수신된 파일 이름이 명령줄에서 요청한 파일 이름과 일치하는지 확인하여 원격 측에서 예상치 못한 파일이나 원치 않는 파일을 보내는 것을 방지합니다. 다양한 운영 체제와 셸이 파일 이름 와일드카드를 해석하는 방식이 다르기 때문에 이러한 확인으로 인해 필수 파일이 거부될 수 있습니다. 이 옵션은 서버가 예상치 못한 파일 이름을 보내지 않을 것이라는 확신을 바탕으로 이러한 검사를 비활성화합니다.

요약하면 이전 기본 동작이 scp로 이동되었으며 -T이제 기본 동작은 제공된 인수를 단순 모드로 사용하여 재귀 복사를 수행하지 않을 때 수신된 내용을 확인하는 것입니다. 나는 이것이 간단한 와일드카드와 이스케이프(소스코드를 보세요, 그것은 사용경기(3)일치를 위해 플래그는 0으로 설정됨). 즉, 쉘 코드를 통해 파일을 지정하는 고유한 기능을 활용하고 싶지 않을 때 더 예측 가능하게 작동합니다.

따라서 이제 사용하지 -T않고 사용하지 않는 경우 -r이와 같은 것을 재정의하는 유일한 방법은 .bashrc명시적으로 요구하는 것입니다. 셸 코드를 사용하려면 -T서버 신뢰를 희생해야 합니다.

scp -T server:'*(.oc[1,10])' .

scp따라서 이제 또는 와 같은 다른 유틸리티보다 sftp더 유용한 고유한 기능을 완전히 포기하지 않고도 간단한 비재귀 사례에서 안전성을 얻을 수 있습니다 rsync.

할 수 있는scp를 sftp로 대체할 수 있나요?

sftp는 쉘 코드를 사용하여 원하는 파일을 지정할 수 없습니다. 실제 파일 경로만 허용됩니다. 이것은 더 제한적입니다. 간단한 파일 경로에 scp만 필요하다면 그렇습니다. 그러나 서버측 셸 코드를 사용하여 간단한 명령으로 파일을 지정할 수 있기를 원한다면(비록 서버를 신뢰해야 하는 대가를 치르더라도) 유일한 옵션은 scp.

왜 "안전하지 않음"을 인용합니까?

이는 안전하지 않지만 서버가 손상되지 않을 것이라고 신뢰하지 않는 경우에만 가능합니다. 내 경우, 그리고 아마도 대부분의 사람들은 완전히 신뢰하는 서버와 함께 scp를 사용합니다. 특히 저는 노트북에서 데스크톱으로 또는 그 반대로 로그인하는 데 이 기능을 사용합니다. 기기를 믿을 수 없다면 무엇을 믿을 수 있을까요? 그렇기 때문에 안전하지 않다고 말하는 것은 과장된 것이라고 생각합니다. 예를 들어, 이는 텔넷이 안전하지 않다고 말한 것과 다릅니다.

그러나 -T. 그것예더 안전합니다. 또한 기능을 활성화할 필요가 없는 사람들의 경우 -Tsftp 또는 rsync보다 scp를 사용하는 데 실제로 큰 이점이 없습니다.

내가 읽는 방식은 "상황에 따라 다르다"입니다.

~에 따르면CVE-2019-6111

그러나 scp 클라이언트는 반환된 개체 이름에 대해 대략적인 유효성 검사만 수행합니다(디렉터리 탐색 공격만 방지). 악의적인 scp 서버(또는 중간자 공격자)는 scp 클라이언트의 대상 디렉터리에 있는 임의의 파일을 덮어쓸 수 있습니다. 재귀적으로 수행하는 경우(-r) 서버는 하위 디렉터리에서도 작동할 수 있습니다(예: .ssh/authorized_keys 파일 덮어쓰기).

따라서 scp구내(데이터 센터)의 호스트 간에 전송이 이루어지는 경우 MITM 공격을 수행할 수 없을 가능성이 높습니다(확실하지는 않음).

그러나 World Wide Web을 통해 고객/파트너로부터 비즈니스 파일을 받는 경우에는 에 의존해야 합니다 sftp( ftps적어도 scp클라이언트와 ssh서버에 적절한 버전이 있는지 확인하십시오).

SSH를 통한 MITM의 가능성을 고려한다면 많은 Unix 명령이 안전하지 않게 될 것입니다. 악의적인 행위자는 sudo귀하의 비밀번호를 훔칠 수 있고, 악의적인 통신 클라이언트는 귀하의 이메일/인스턴트 메시지 등을 읽을 수 있습니다.

손상된 서버와 대화할 때 교체하면 scp어떻게든 상황을 바로잡을 수 있다는 점은 매우 낙관적입니다. sftp로컬 파일에 어떤 손상이 가해졌든 scp바이너리, 셸 스크립트, Python 파일, Makefiles 등을 통해 수행될 수도 있으며, sftp이는 사기꾼이 기꺼이 제공할 것입니다.

간단히 말해서, 어떤 서버에 SSH로 연결하는지 주의를 기울이지 않으면 어떤 도구를 사용하더라도 문제가 발생할 위험이 높으며 그냥 SSH 를 사용하는 sftp대신 사용할 수 있습니다.scp미미하게더 안전합니다.

전환이 나쁜 생각이라는 것은 아닙니다 sftp. 전환이 현재 작업에 적합한 고품질 도구라면 전환해야 할 충분한 이유가 있으며 보안과는 아무런 관련이 없습니다.

manscp

scp는 네트워크의 호스트 간에 파일을 복사합니다. 데이터 전송에 ssh(1)을 사용하고 ssh(1)과 동일한 인증을 사용하며 동일한 보안을 제공합니다. rcp(1)과 달리 인증에 암호나 암호 문구가 필요한 경우 scp에는 암호나 암호 문구가 필요합니다.

물어scp는 안전하지 않습니까?? 올바르게 설정 및 사용되지 않은 다른 모든 것과 마찬가지로 그럴 수도 있습니다.

MITM(Man-in-the-Middle) 취약성, 초기 팝업이 나타나는 곳으로 처음 SSH를 통해 접속할 때 팝업을 무시하고 확인을 클릭한다는 사실을 알고 계실 것입니다.

서버의 호스트 키는 레지스트리에 캐시되지 않습니다. 서버가 귀하가 생각하는 컴퓨터라는 보장은 없습니다. 서버의 SSH 지문은 blablabla입니다.

이는 SSH(또는 scp)의 잘못이 아닙니다. 이것이 프로토콜을 올바르게 사용하지 않는 이유입니다.

SSH 서버를 설정하고 연결 대상에 연결하면 간단한 문제입니다(제 생각에는).SSH 프로토콜 2 및 AES-256 암호 사용. 이는 대부분의 보안입니다. 귀하 sshd_conf(및 클라이언트 ssh_config)를 사용자 정의하지 않고 기본값으로 두는 경우 이는 귀하의 책임입니다.

이는 sshd_config에 대한 예외입니다. 다음을 고려해 보세요.

Protocol                                     2
Ciphers                                      aes256-ctr
MACs                                         hmac-sha2-512,hmac-sha2-256
# MACs                                       hmac-sha1
PermitRootLogin                              no
AuthorizedKeysFile                           .ssh/authorized_keys  {set this up}
IgnoreRhosts                                 yes
IgnoreUserKnownHosts                         yes
StrictModes                                  yes
UsePAM                                       yes

---

CVE-2019-6111에 따르면

scp 클라이언트는 반환된 개체 이름에 대해 대략적인 유효성 검사만 수행합니다(디렉터리 탐색 공격만 방지). 악의적인 scp 서버(또는 중간자 공격자)는 scp 클라이언트의 대상 디렉터리에 있는 임의의 파일을 덮어쓸 수 있습니다. 재귀적으로 수행하는 경우(-r) 서버는 하위 디렉터리에서도 작동할 수 있습니다(예: .ssh/authorized_keys 파일 덮어쓰기).

이것은 문맥에서 벗어난 것입니다. 먼저 불량 SSH 서버에 연결하지 마십시오. 프로토콜을 사용하여 SSH 서버를 설정한 사람에 대해 SSH를 비난하지 마십시오.scp 클라이언트의 대상 디렉터리에 있는 모든 파일을 덮어씁니다. 먼저 서버/클라이언트 키를 사용하여 SSH 연결이 올바르게 설정되었으며 MITM 불량 서버가 없습니다.

SSH라고도 불리는 scp는 안전합니다. scp가 안전하지 않다고 말하는 것은 본질적으로 ssh가 안전하지 않기 때문에 ssh를 사용해서는 안 된다는 것을 의미하지만, 사실은 그렇지 않습니다.

SSH = 보안 셸

scp = SSH를 통한 보안 복사

ftp = 파일 전송 프로토콜

sftp = SSH FTP

ftps = TLS/SSL을 통한 ftp

scp를 sftp로 바꿔야 할까요?

서버의 호스트 키/지문이 마음에 들지 않을 때 sftp(서버가 누구인지 보장할 수 없는 서버에 연결)를 사용하는 방법을 자문하고 확인을 클릭하면 됩니다.

SSH가 통신하면터널정확하게 말하면, 보안 사본이든 파일 전송 프로토콜이든 두 지점 사이에 통신을 설정하는 의미는 이 시점에서는 간단합니다. SSH라고도 불리는 scp는 안전합니다. scp가 안전하지 않다는 것은 본질적으로 ssh가 안전하지 않기 때문에 ssh를 사용해서는 안 된다는 것을 의미합니다. 그러나 그것은 진실이 아니다. 내가 당신에게 전화해서 당신이 나에게 나쁜 일을 일으킨다면 그것은 전화 회사의 잘못이 아닙니다.

"scp 프로토콜은 오래되고 유연성이 없으며 수정하기가 쉽지 않습니다. sftp 및동기화파일 전송용. "

pleeeasssee...rsync 자체는 암호화를 수행하지 않으며 연결하려는 사람이 자신이라고 생각하는 사람이라는 보장이 없으면 동일한 문제가 발생합니다. 하지만 이 힌트에서 rsync가 통과합니까? 어디서 조언을 받을지 주의하세요.