☰

단일 단계 SSH 포트 전달이 작동하지 않지만 SSH 포트 전달이 원격 점프 서버와 원격 로컬 호스트에서 별도로 수행되는 경우에만 해당됩니까?

tag-icon • tag-icon ssh ssh-tunneling port-forwarding
단일 단계 SSH 포트 전달이 작동하지 않지만 SSH 포트 전달이 원격 점프 서버와 원격 로컬 호스트에서 별도로 수행되는 경우에만 해당됩니까?

이 시나리오에서는 세 가지 시스템을 고려하십시오.

  1. Machine_A: 내 로컬 MacBook
  2. Machine_B: 일부 서버는 VPN이 필요 없이 Machine A에서 직접 SSH를 통해 연결할 수 있습니다. (원격 점프 서버)
  3. Machine_C: 방화벽이 있는 컴퓨터는 Machine_B를 통해서만 액세스할 수 있습니다. (원격 보호 로컬 호스트)

궁극적으로 Machine_C에서 VNCserver를 시작하고 이를 Machine_A에서 보고 싶습니다.

다음 예제를 실행하여 Machine_C에서 VNCserver를 실행하는 방법을 알아냈습니다 vncserver :4. 현재로서는 vncviewer가 잘 작동하지만 해야 할 일이 있습니다.vncviewer가 성공적으로 작동하도록 포트 전달을 활성화하는 2단계 프로세스:

  1. 내 Machine_A 터미널에서 다음을 실행합니다.ssh -L 5904:localhost:5904 myusername@Machine_B
  2. 1단계부터 이제 Machine_B에 SSH를 사용하게 되었습니다. 이제 Machine_B에서 다음을 실행합니다.ssh-L 5904:localhost:5904 Machine_C

localhost:4이 두 단계가 작동하면 내 vncviewer가 정상적으로 실행되어 vncviewer를 입력하여 Machine_C의 vncsession을 표시했습니다.

그러나 두 단계를 거쳐야 합니다. 아래에 표시된 ONE 명령 흐름을 기억합니다.

ssh -L 5904:Machine_C:5904 myusername@Machine_B

작업을 수행해야 하지만 작동하지 않고 다음 디버깅된 응답을 보여줍니다.

debug1: Connection to port 5904 forwarding to Machine_C port 5904 requested.
debug2: fd 12 setting TCP_NODELAY
debug1: channel 3: new [direct-tcpip]
channel 3: open failed: connect failed: Connection refused
debug2: channel 3: zombie
debug2: channel 3: garbage collecting
debug1: channel 3: free: direct-tcpip: listening port 5904 for Machine_C port 5904, connect from ::1 port 61702 to ::1 port 5904, nchannels 4

참고로:

Machine_B 및 Machine_C의 내 ~/.ssh/config 파일:

Host *
     ForwardAgent yes
     ForwardX11 yes
     ForwardX11Trusted yes
     RhostsAuthentication yes
     RhostsRSAAuthentication yes
     RSAAuthentication yes
     TISAuthentication no
     PasswordAuthentication yes
     FallBackToRsh yes
     UseRsh no
     BatchMode no
     StrictHostKeyChecking no
     IdentityFile ~/.ssh/identity
     Port 22
     EscapeChar ~

Machine_B 및 Machine_C의 내 ~/.vnc/xstartup 파일 설정:

#!/bin/sh


# Uncomment the following two lines for normal desktop:
unset SESSION_MANAGER
exec /etc/X11/xinit/xinitrc


[ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
[ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
xsetroot -solid grey
vncconfig -iconic &
/usr/bin/gnome-session --session=2d-gnome &
xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &
#startx &i
x-window-manager &

원스텝 포트 포워딩이 ssh -L 5904:Machine_C:5904 myusername@Machine_B작동하지 않는 이유에 대해 도움을 주실 수 있나요? 내가 뭐 놓친 거 없니 .ssh/config?

답변1

-Jssh >= 7.3(Machine_A에만 필요)을 사용하면 / 옵션을 사용하여 이 두 단계를 백그라운드에서 수행할 수 있으므로 ProxyJump수행해야 할 작업이 단순화됩니다(실제로 이 특정 예의 보안이 향상됨).

ssh -L 5904:localhost:5904 -J myusername@Machine_B myusername@Machine_C

이렇게 하면 간단할 뿐만 아니라 이전처럼 Machine_B에서 VNC 액세스가 이루어지지 않으므로 Machine_B의 다른 사용자가 VNC를 사용할 수 없습니다.

설명하자면, 이는 동일한 작업을 수행하는 전통적인(안전한) 방법입니다.

ssh -L 2222:Machine_C:22 myusername@Machine_B

Machine_A에 있는 다른 터미널에서:

ssh -L 5904:localhost:5904 myusername@localhost:2222

Machine_B에는 사용 가능한 터널 진입점이 없습니다. ProxyJump( -J)는 포트 2222 대신 두 SSH 프로세스 사이에 파이프를 사용한다는 점을 제외하면 내부적으로는 거의 동일한 작업을 수행합니다.

이제 SSH를 통해 Machine_C에 전혀 연결할 수 없습니다. 이는 SSH 문제가 아닌 VNC 액세스/설정 문제일 가능성이 높습니다. VNC가 localhost로 제한되지 않는 것이 확실합니까? 구성을 통해서입니까, 아니면 로컬 방화벽을 통해서입니까?

관련 정보