오프너를 사용하여 HTTP 프록시를 통한 SSH

오프너를 사용하여 HTTP 프록시를 통한 SSH

HTTP 프록시 뒤에서 SSH를 사용하여 Cygwin 터미널에서 집 Raspberry Pi에 연결하는 데 문제가 있습니다. 그것은 작동했었습니다™, 며칠 전 이후로 무엇이 변경되었는지 모르겠습니다(아마도 프록시 필터링?). 오프너 없이도 프록시 네트워크 외부에서 연결할 수 있습니다.

클라이언트에 관한 한 내 SSH 구성은 다음과 같습니다.

Host *
        ServerAliveInterval 60
        ProxyCommand /bin/corkscrew http.proxy.here 80 %h %p

연결 시도는 다음을 제공합니다.

blx@proxyed-pc:~$ ssh [email protected] -v
OpenSSH_7.9p1, OpenSSL 1.0.2p  14 Aug 2018
debug1: Reading configuration data /home/blx/.ssh/config
debug1: /home/blx/.ssh/config line 1: Applying options for *
debug1: Executing proxy command: exec /bin/corkscrew http.proxy.here 80 my.home.ip 22
debug1: identity file /home/blx/.ssh/id_rsa type -1
debug1: identity file /home/blx/.ssh/id_rsa-cert type -1
debug1: identity file /home/blx/.ssh/id_dsa type -1
debug1: identity file /home/blx/.ssh/id_dsa-cert type -1
debug1: identity file /home/blx/.ssh/id_ecdsa type 2
debug1: identity file /home/blx/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/blx/.ssh/id_ed25519 type -1
debug1: identity file /home/blx/.ssh/id_ed25519-cert type -1
debug1: identity file /home/blx/.ssh/id_xmss type -1
debug1: identity file /home/blx/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
ssh_exchange_identification: Connection closed by remote host

서버 측에서 /var/log/auth는 다음을 보고합니다.

Nov 26 13: 39:36 raspi sshd[19130]: debug1: Forked child 19699.
Nov 26 13: 39:36 raspi sshd[19699]: debug1: Set /proc/self/oom_score_adj to 0
Nov 26 13: 39:36 raspi sshd[19699]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 26 13: 39:36 raspi sshd[19699]: debug1: inetd sockets after dupping: 3, 3
Nov 26 13: 39:36 raspi sshd[19699]: debug1: getpeername failed: Transport endpoint is not connected
Nov 26 13: 39:36 raspi sshd[19699]: debug1: ssh_remote_port failed

$corkscrew http.proxy.here 80 my.home.ip 22그래서 TCP 연결이 끊어진 것 같지만, 코르크 따개로 직접 연결하려고 하면 이런 문제가 발생하지 않는 것 같습니다(예:).

Nov 26 13: 39:32 raspi sshd[19130]: debug1: Forked child 19698.
Nov 26 13: 39:32 raspi sshd[19698]: debug1: Set /proc/self/oom_score_adj to 0
Nov 26 13: 39:32 raspi sshd[19698]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 26 13: 39:32 raspi sshd[19698]: debug1: inetd sockets after dupping: 3, 3
Nov 26 13: 39:32 raspi sshd[19698]: Connection from http.proxy.here port 28220 on 192.168.0.11 port 22
Nov 26 13: 39:32 raspi sshd[19698]: Did not receive identification string from http.proxy.here port 28220

하지만 물론 sshd는 무엇을 해야할지 모릅니다 ...

어떤 제안이 있으십니까? 설정에서 아무 것도 변경하지 않은 것 같아서 프록시 필터링 정책의 몰래 업데이트로 인해 문제가 발생한 것 같습니다.이것상황은 알 수 있지만 확실히 알 수는 없습니다. 집에 도착하면 포트 443을 사용하도록 라우터와 Pi를 업데이트해 보겠습니다.

답변1

우리는 특정 보안 조치를 우회할 의도가 없으며 이 연결 방법이 확실히 어떠한 계약/합의도 위반하지 않는다는 점에 동의해야 합니다. 의사 법적 면책 조항이 완료되었습니다. 만약 제가 당신이라면 실제로 다른 서버보다 더 잘 작동하는 포트 443에서 SSH 연결을 수신하도록 서버를 전환하려고 시도할 것입니다(웹 프록시를 통하는 경우). 이유는 간단합니다.

  • 포트 80(일반 웹 트래픽)의 통신은 암호화되지 않고 대부분 일반 텍스트(페이지를 읽을 때)인 반면, 포트 443은 SSL 암호화 통신에 사용됩니다. 에이전트는 이 포트를 통한 바이너리 형태의 통신을 보고 놀라지 않을 것입니다. 웹 페이지와 달리 SSH에는 바이너리 연결이 필요합니다.
  • 잘 알려진 포트(예: 22)를 사용하여 서버를 대중에게 노출시키지 않습니다(상대방에 IP 화이트리스트 방화벽이 없는 경우). 새 서버가 감지되지 않고 5분 미만 동안 온라인 상태가 되는 경우도 있습니다. 그러면 어딘가에 있는 누군가가 포트 22가 열려 있는 것을 보고 SSH를 통해 로그인을 시도할 것입니다. 포트 443은 많은 보안을 추가하지는 않지만 22보다 눈에 덜 띄는 정도입니다. 행운을 빌어요!

관련 정보