6P by neo 2달전 | favorite | 댓글 1개

SSH 터널링 및 포트 포워딩에 대한 시각적 가이드

  • 요약: 이 블로그 포스트는 SSH 터널링 및 포트 포워딩에 대한 이해를 돕기 위해 작성되었음. 주제는 사용 사례, 설정, SSH 점프호스트, 로컬/원격/동적 포트 포워딩, 그리고 제한 사항을 포함함.
사용 사례
  • 보안:

    • FTP와 같은 안전하지 않은 연결 암호화
    • SSH 터널을 통한 웹 관리자 패널 접근 (공개 키 인증)
    • 노출되는 포트 수 감소 (22번 포트만 노출)
  • 문제 해결:

    • 방화벽/콘텐츠 필터 우회
    • 다른 경로 선택
  • 연결:

    • NAT 뒤에 있는 서버 접근
    • 점프호스트를 사용하여 인터넷을 통해 내부 서버 접근
    • 로컬 포트를 인터넷에 노출
포트 포워딩
  • 설정/준비:
    • 로컬 및 원격 사용자는 포트를 열기 위한 권한이 필요함
    • 0-1024번 포트는 루트 권한이 필요함
    • 클라이언트와 네트워크 방화벽을 적절히 설정
    • SSH 서버에서 포트 포워딩을 활성화해야 함: AllowTcpForwarding yes
    • 다른 인터페이스에서 포트를 포워딩하려면 GatewayPorts yes를 활성화해야 함
SSH 점프호스트 / SSH 터널
  • 점프호스트를 통한 연결:

    ssh -J user@REMOTE-MACHINE:22 -p 22 user@10.99.99.1
    
  • 여러 점프호스트 사용:

    ssh -J user@REMOTE-MACHINE:22,user@ANOTHER-REMOTE-MACHINE:22 -p 22 user@10.99.99.1
    
로컬 포트 포워딩
  • 예제 1:

    ssh -L 10.10.10.1:8001:localhost:8000 user@REMOTE-MACHINE
    
  • 예제 2:

    ssh -L 8001:10.99.99.1:8000 user@REMOTE-MACHINE
    
원격 포트 포워딩
  • 예제 1+2:

    ssh -R 8000:localhost:8001 user@REMOTE-MACHINE
    ssh -R 8000:10.10.10.2:8001 user@REMOTE-MACHINE
    
  • 예제 3:

    ssh -R 10.99.99.2:8000:10.10.10.2:8001 user@REMOTE-MACHINE
    
동적 포트 포워딩
  • SOCKS 프로토콜 사용:
    ssh -D 10.10.10.1:5555 user@REMOTE-MACHINE
    
SSH TUN/TAP 터널링
  • 양방향 TCP 터널 생성:
    ssh -w local_tun[:remote_tun]
    
백그라운드에서 SSH 실행
  • 백그라운드 실행:

    ssh -fN -L 8001:127.0.0.1:8000 user@REMOTE-MACHINE
    
  • 백그라운드 SSH 중지:

    ps -ef | grep ssh
    kill <PID>
    
SSH 연결 유지
  • 타임아웃 처리:
    • ClientAliveInterval 15
    • ClientAliveCountMax 3
제한 사항
  • UDP:

    • SSH는 신뢰할 수 있는 전달을 필요로 하므로 UDP는 지원되지 않음
  • TCP-over-TCP:

    • 오버헤드 증가로 인해 처리량이 감소하고 지연 시간이 증가함
  • VPN 대체 아님:

    • SSH 터널링은 VPN을 대체할 수 있지만, 성능 면에서 VPN이 더 적합함
  • 잠재적 보안 위험:

    • 필요하지 않은 기능은 비활성화하는 것이 좋음

GN⁺의 정리

  • 이 글은 SSH 터널링과 포트 포워딩의 다양한 사용 사례와 설정 방법을 설명함
  • SSH 터널링은 보안 연결을 제공하고 방화벽을 우회하는 데 유용함
  • 그러나 VPN을 대체할 수는 없으며, 성능 저하와 같은 제한 사항이 있음
  • 관련된 다른 프로젝트로는 OpenVPN과 같은 VPN 솔루션이 있음
Hacker News 의견
  • 2024년에는 SSH 명령어를 직접 작성하는 대신, ~/.ssh/config 파일을 사용하여 LocalForward, RemoteForward, ProxyJump를 설정하는 것이 좋음

    • 예시 설정을 통해 여러 중간 SSH 연결을 거쳐 데이터를 전송할 때 시간을 절약할 수 있음
    • 설정 후에는 별칭을 통해 target-server에 SSH, SCP, RSYNC를 사용할 수 있음
    • LocalForward와 RemoteForward 설정을 통해 포트 포워딩을 쉽게 할 수 있음
  • SSH 터널링은 복잡한 회사 환경에서 필수적임

    • 많은 관료주의와 대기 시간 때문에 필요한 접근 권한을 얻는 데 시간이 걸림
    • ssh -D 8888 someserver 명령어를 사용하여 브라우저의 SOCKS 프록시를 localhost:8888로 설정하면 브라우저 트래픽이 해당 서버를 통해 라우팅됨
  • 방화벽 뒤에 있고 고정 IP가 없는 리눅스 서버나 IoT 장치에 SSH 접속을 원할 때는 터널링 서비스를 사용할 수 있음

  • 가장 복잡한 SSH 터널링 해킹 경험은 데이터 센터 간 연결에서 발생함

    • A에서 B로, B에서 C로 데이터를 이동해야 했음
    • rsync, SSH 터널, 키, 라우팅을 조합하여 데이터를 성공적으로 이동시킴
    • 당시에는 큰 성취였으며, 지금도 그 기억이 생생함
  • 네트워킹 시각화가 더 많이 이루어지길 바람

    • 특히 저수준 연결에서의 트래픽 시각화가 필요함
  • TCP-over-TCP는 오버헤드가 증가하고 지연 시간이 늘어나 성능이 저하될 수 있음

    • SSH 터널에서는 TAP/TUN을 사용하지 않는 한 문제가 되지 않음
    • 그러나 여러 채널을 사용할 경우 성능 저하가 발생할 수 있음
  • SSH 터널은 훌륭한 도구지만, 요즘에는 TLS와 리버스 프록시 기능이 내장된 도구를 더 많이 사용함

  • sshuttle은 터널링에 더 나은 도구임

    • sshuttle -r user@host 10.0.0.0/8 명령어를 사용하여 VPN처럼 사용할 수 있음
  • 15년 전 대학 네트워크의 방화벽을 우회하기 위해 SSH 터널을 사용하기 시작함

    • 기본 포트를 443으로 변경하여 사용함
    • 이후로 방화벽 우회 외에도 다양한 용도로 사용 중임
  • SSH 자체에 리다이렉트 기능이 있는지 궁금함

    • A가 B에 SSH 접속을 시도하면 B가 C에 접속하라고 지시하고, A가 투명하게 C에 직접 접속하는 기능
    • B는 더 이상 중요한 데이터 경로의 일부가 아님
    • 이러한 기능이 존재하는지 궁금함