당신은 무엇을 했나요?

사용해 보셨나요?삼SSH 명령:

1. 언제두번째당신이 만든 콘솔:

   ssh -4 -N -f -R 18822:localhost:22 <user>@<vps>
   

   sshd(서버) 명령으로 포트를 엽니다 18822.외딴vps:18822로컬호스트(B) 포트 22에 연결합니다.

2. 언제가상 사설 통신망당신이 만든 콘솔:

   ssh -g -f -N -L 0.0.0.0:18888:localhost:18822 <user>@localhost
   

   18888사용 가능한 포트를 여는 SSH(클라이언트) 명령외부( ) 0.0.0.0의 ( ) 포트 vps는 내부 포트 18822에 연결되어 있습니다.

   이렇게 하면 인터넷에 표시되는 포트가 열리고 vps:18888트래픽이 해당 포트로 리디렉션되고 18822다시 로 리디렉션됩니다 B:22.

3. 언제ㅏ콘솔(그리고오직참여 연결):

   클라이언트에서 연결ㅏ고객에게 직접두번째존재하다 vps:18888.

중요한 것은 마지막 연결입니다.
전체 SSH 보안은 다음에 달려 있습니다.확인하다~의ㅏ도착하다두번째.

무슨 뜻이에요

이것SSH 프로토콜

SSH는 안전하지 않은 네트워크를 통해 보안 채널을 제공합니다.

사용하여엔드투엔드 암호화

E2EE(End-to-End 암호화)는 통신하는 사용자만 메시지를 읽을 수 있는 통신 시스템입니다. 원칙적으로 이는 잠재적인 도청자(통신 제공업체, 인터넷 제공업체, 심지어 통신 서비스 제공업체 포함)가 대화를 해독하는 데 필요한 암호화 키에 액세스하는 것을 방지합니다.

종단 간 암호화는 개념입니다. SSH는 프로토콜입니다. SSH는 종단 간 암호화를 구현합니다. https 또는 다른 암호화 프로토콜도 작동합니다.

만약에프로토콜은 강력합니다.그리고구현이 정확합니다. 암호화 키를 아는 당사자는 두 명뿐입니다.검증됨(종료) 모든 당사자.

키를 알 수 없고 프로토콜의 보안을 침해할 수 없으므로 다른 당사자는 통신 내용에서 제외됩니다.

만약에, 설명대로 :클라이언트 A에서 클라이언트 B로 직접시스템 B에 직접 인증합니다.그 다음에, 클라이언트 A와 클라이언트 B만이 키를 가지고 있습니다. 다른 것은 없습니다.

1분기

사례 A: VPS 자체는 수정되지 않지만 트래픽과 파일은 완전히 모니터링됩니다.

발생하는 통신(날짜, 시간, 최종 IP 등)과 특정 양의 트래픽(킬로바이트, 메가바이트)만 모니터링할 수 있지만 실제로 통신되는 콘텐츠는 모니터링할 수 없습니다.

2분기

시나리오 B: VPS가 완전히 손상되어 파일 시스템 내용이 변경될 수 있습니다.

문제가 되지 않습니다. 통신이 다른 사이트/위치를 통해 다시 라우팅되더라도 키를 알고 있는 당사자는 A와 B뿐입니다. 지금 바로:만약에통신 시작 시 인증은 A와 B 사이에서 이루어집니다.

(선택) A가 접속한 IP의 유효성을 확인한 후, 공개키 인증을 사용합니다.한 번A와 B만 알고 있는 개인 키-공개 키 쌍)이 완료되었습니다.

당신에 대해 알아요~ 해야 하다사용된 공개 키가 시스템 B에 안전하게 전달되었는지 확인하십시오. 키를 전달한 다음 암호화를 전달하는 데 동일한 채널을 신뢰할 수 없습니다. 가지다프로토콜을 깨뜨릴 수 있는 중간자 공격.

3분기

이제 SFTP를 통해 클라이언트 A에서 클라이언트 B로 파일을 보내는 경우 VPS를 호스팅하는 회사가 파일을 "가로채서" 파일의 (암호화되지 않은) 내용을 읽을 수 있습니까?

아니요, 공개 키가 양쪽 끝에 안전하게 배치되어 있다면 이런 일이 발생할 가능성은 거의 없습니다.

공개키가 담긴 디스크를 가지고 상대방에게 다가가서 설치하시면 더 이상 걱정하지 않으셔도 됩니다.

---

논평

귀하의 의견으로 판단하면 다음과 같습니다.

1분기

그러면 기본적으로 내 설정의 VPS는 포트 전달만 수행하고 클라이언트 A에서 B로 발생하는 실제 SSH 연결이나 인증에는 관여하지 않습니다. 그렇죠?

거의. 예, VPS입니다.~해야 한다인증에는 관여하지 않습니다. 그러나 이는 "중간"입니다. 즉, 한쪽에서 패킷을 수신하여 (올바르게 작동하는 경우) 다른 쪽으로 전달합니다. 그러나 대안이 있습니다. VPS(또는 모든 중간 장치)를 선택할 수 있습니다.거짓말하다그리고"중간자 공격" 수행. 클라이언트 B인 척하고 클라이언트 A에게 거짓말을 할 수도 있고, 클라이언트 A인 척하면서 클라이언트 B에게 거짓말을 할 수도 있습니다. 이렇게 하면 "중간 사람"과의 통신에 포함된 모든 내용이 드러납니다. 그래서 제가 강조하는 단어는~해야 한다이상.

나또한 말해야 할 것입니다:

...공개 키 방법을 사용하여 인증된 SSH 연결에 대해 MITM을 구현하는 도구는 없습니다...

비밀번호 기반 인증은아니요공개 키 방법.

인증을 위해 비밀번호를 사용하는 경우 중간자 공격에 취약할 수 있습니다. 몇 가지 다른 대안이 있지만 이는 이 기사의 범위를 벗어납니다.

원래,SSH-keygen을 사용하여 키 쌍 생성(A면에 있다고 가정), (적절한 보안을 위해) 디스크의 공개 부분을 B면으로 전송하고 인증 키 파일에 설치합니다. 하다아니요네트워크 설치 공개 키를 사용하십시오. 예:ssh-copy-id를 사용하지 마세요정말로 인터넷을 통해하다귀하가 무엇을 하고 있는지, 그리고 당사자 B의 신원을 확인할 수 있는 능력이 있는지를 정확히 알고 계십시오. 이 작업을 안전하게 수행하려면 전문가가 되어야 합니다.

2분기

그런데 공개키는 공개 아닌가요?

• 예, 공개입니다.
  네, 그렇습니다. 공개-비공개 쌍을 생성하는 엔터티는 공개 부분을 누구에게나 공개할 수 있으며 비밀은 손실되지 않습니다. 누군가 공개 키로 암호화하면 일치하는(비밀) 개인 키로 모든 메시지를 해독할 수 있습니다.

• SSH 암호화.
  그런데 SSH 암호화는 비대칭(공개)이 아닌 대칭입니다. 인증이 비대칭적입니다(또는DH(디피-헬먼) (비밀번호의 경우) 또는RSA, DSA, Ed25519 주요 강도또는 기타(공개 키의 경우)) 해당 인증을 기반으로 대칭 키가 생성되어 통신 암호화 키로 사용됩니다.

• 인증에 사용됩니다.
  그러나 SSH를 사용하면 공개 키(ssh-keygen을 사용하여 생성됨)에 추가 비밀이 제공됩니다. 즉, 공개 키의 소유자를 확인합니다.

  인터넷에서 공개 키를 받은 경우 그 공개 키가 누구의 것인지 어떻게 알 수 있나요? 공개 키가 주장하는 것을 믿습니까? 당신은해야하지! !

  그렇기 때문에 공개 키 파일을 (안전한 방식으로) 원격 서버로 가져가서 거기에 설치해야 합니다. 그런 다음 (확인된) 공개 키를 해당 서버에 대한 로그인을 인증하는 방법으로 신뢰할 수 있습니다.

3분기

이전에 VPS에서 클라이언트 B에도 연결한 적이 있습니다(주로 테스트용). 공개 키가 교환되지 않았나요?

암호화를 위해 공개 키 세트(DH에서 생성된 공개 키 세트)를 교환합니다. 아니요확인하다ssh-keygen에서 생성된 공개 키를 사용합니다. 통신이 종료되면 해당 통신에 사용된 키는 삭제되고 잊어버립니다.

또한 원격 서버의 IP를 확인하기 위해 키를 수락하고 사용합니다. IP 보안은 단순한 것보다 더 복잡합니다(??) 공개 키 인증.

내 생각에는 공개 키는 공유할 수 있지만 개인 키나 비밀번호는 안전하게 유지되어야 한다는 것입니다.

당신의 (일반적인) 인상은 정확하지만, 악마는 세부 사항에 있습니다...

키 쌍을 생성한 사람은 보안을 저하시키지 않고 자신의 공개 키를 게시할 수 있습니다.

공개 키를 받는 사람~ 해야 하다 독립적으로공개 키가 자신이 속해 있다고 생각하는 사람의 것인지 확인하세요.

그렇지 않으면 공개 키를 받는 사람이 악의적인 파트너와 통신할 수 있습니다.

키 생성

SSH를 사용하여 A를 C에 연결한 다음 C를 B에 연결하면 엔드투엔드가 아닙니다. C의 한쪽 끝이고 C의 다른 쪽 끝입니다. C는 무엇이 전송되고 있는지 볼 수 있습니다.

종단 간 암호화의 경우 연결의 양쪽 끝을 모두 SSH로 연결해야 합니다. 당신이 어떤 일을 겪었는지는 중요하지 않습니다.

양쪽 끝이 서로를 볼 수 없지만 C를 볼 수 있는 경우 (보안 또는 비보안) 연결 A-C 및 B-C가 설정될 수 있습니다. 그런 다음 SSH를 사용하여 보안 연결 A-B를 설정합니다.