คู่มือภาพสำหรับ SSH Tunneling และ Port Forwarding (2023)

คู่มือแบบภาพสำหรับ SSH Tunneling และ Port Forwarding

• สรุป: บล็อกโพสต์นี้เขียนขึ้นเพื่อช่วยให้เข้าใจ SSH tunneling และ port forwarding โดยหัวข้อครอบคลุมกรณีการใช้งาน การตั้งค่า SSH jump host, local/remote/dynamic port forwarding และข้อจำกัด

กรณีการใช้งาน

• ความปลอดภัย:

  • เข้ารหัสการเชื่อมต่อที่ไม่ปลอดภัย เช่น FTP
  • เข้าถึงแผงผู้ดูแลระบบเว็บผ่าน SSH tunnel (การยืนยันตัวตนด้วย public key)
  • ลดจำนวนพอร์ตที่เปิดเผย (เปิดเพียงพอร์ต 22)

• การแก้ปัญหา:

  • ข้ามไฟร์วอลล์/ตัวกรองเนื้อหา
  • เลือกเส้นทางอื่น

• การเชื่อมต่อ:

  • เข้าถึงเซิร์ฟเวอร์ที่อยู่หลัง NAT
  • ใช้ jump host เพื่อเข้าถึงเซิร์ฟเวอร์ภายในผ่านอินเทอร์เน็ต
  • เปิดพอร์ตในเครื่องให้เข้าถึงได้จากอินเทอร์เน็ต

Port Forwarding

• การตั้งค่า/การเตรียมพร้อม:
  • ผู้ใช้ฝั่ง local และ remote ต้องมีสิทธิ์ในการเปิดพอร์ต
  • พอร์ต 0-1024 ต้องใช้สิทธิ์ root
  • ตั้งค่าไฟร์วอลล์ของไคลเอนต์และเครือข่ายให้เหมาะสม
  • ต้องเปิดใช้งาน port forwarding บน SSH server: AllowTcpForwarding yes
  • หากต้องการ forward พอร์ตจากอินเทอร์เฟซอื่น ต้องเปิด GatewayPorts yes

SSH Jump Host / SSH Tunnel

• การเชื่อมต่อผ่าน jump host:

  ssh -J user@REMOTE-MACHINE:22 -p 22 user@10.99.99.1
  

• ใช้หลาย jump host:

  ssh -J user@REMOTE-MACHINE:22,user@ANOTHER-REMOTE-MACHINE:22 -p 22 user@10.99.99.1
  

Local Port Forwarding

• ตัวอย่าง 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
  

Remote Port Forwarding

• ตัวอย่าง 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
  

Dynamic Port Forwarding

• ใช้โปรโตคอล SOCKS:

  ssh -D 10.10.10.1:5555 user@REMOTE-MACHINE
  

SSH TUN/TAP Tunneling

• สร้าง TCP tunnel แบบสองทาง:

  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 ให้คงอยู่

• การจัดการ timeout:
  • ClientAliveInterval 15
  • ClientAliveCountMax 3

ข้อจำกัด

• UDP:

  • SSH ไม่รองรับ UDP เพราะต้องอาศัยการส่งข้อมูลที่เชื่อถือได้

• TCP-over-TCP:

  • throughput ลดลงและ latency เพิ่มขึ้นเนื่องจาก overhead ที่มากขึ้น

• ไม่ใช่ตัวแทนของ VPN:

  • SSH tunneling สามารถใช้แทน VPN ได้ แต่ในด้านประสิทธิภาพ VPN เหมาะสมกว่า

• ความเสี่ยงด้านความปลอดภัยที่อาจเกิดขึ้น:

  • ควรปิดใช้งานฟีเจอร์ที่ไม่จำเป็น

สรุปโดย GN⁺

• บทความนี้อธิบายกรณีการใช้งานและวิธีตั้งค่าต่าง ๆ ของ SSH tunneling และ port forwarding
• SSH tunneling มีประโยชน์ในการสร้างการเชื่อมต่อที่ปลอดภัยและข้ามไฟร์วอลล์
• อย่างไรก็ตาม มันไม่สามารถทดแทน VPN ได้อย่างสมบูรณ์ และมีข้อจำกัด เช่น ประสิทธิภาพที่ลดลง
• โครงการอื่นที่เกี่ยวข้องมีเช่นโซลูชัน VPN อย่าง OpenVPN

[GN⁺]

ความเห็นจาก Hacker News

• ในปี 2024 แนะนำให้ใช้ไฟล์ ~/.ssh/config เพื่อตั้งค่า LocalForward, RemoteForward, ProxyJump แทนการพิมพ์คำสั่ง SSH โดยตรง

  • ตัวอย่างการตั้งค่าช่วยประหยัดเวลาเมื่อต้องส่งข้อมูลผ่านการเชื่อมต่อ SSH ตัวกลางหลายชั้น
  • หลังตั้งค่าแล้ว สามารถใช้ SSH, SCP, RSYNC กับ target-server ได้ผ่าน alias
  • การตั้งค่า LocalForward และ RemoteForward ช่วยให้ทำ port forwarding ได้ง่าย

• SSH tunneling เป็นสิ่งจำเป็นในสภาพแวดล้อมองค์กรที่ซับซ้อน

  • เพราะมีขั้นตอนราชการและเวลารอจำนวนมาก การขอสิทธิ์เข้าถึงที่จำเป็นจึงใช้เวลานาน
  • ใช้คำสั่ง ssh -D 8888 someserver แล้วตั้งค่า SOCKS proxy ของเบราว์เซอร์เป็น localhost:8888 เพื่อให้ทราฟฟิกของเบราว์เซอร์ถูก route ผ่านเซิร์ฟเวอร์นั้น

• หากต้องการเชื่อมต่อ SSH ไปยังเซิร์ฟเวอร์ Linux หรืออุปกรณ์ IoT ที่อยู่หลังไฟร์วอลล์และไม่มี fixed IP สามารถใช้บริการ tunneling ได้

  • ตัวอย่าง: sshreach.me

• ประสบการณ์การแฮ็ก SSH tunneling ที่ซับซ้อนที่สุดเกิดขึ้นตอนเชื่อมต่อระหว่างดาต้าเซ็นเตอร์

  • ต้องย้ายข้อมูลจาก A ไป B แล้วจาก B ไป C
  • ใช้ทั้ง rsync, SSH tunnel, key และ routing ร่วมกันจนย้ายข้อมูลสำเร็จ
  • ตอนนั้นถือเป็นความสำเร็จครั้งใหญ่ และจนถึงตอนนี้ก็ยังจำได้ชัดเจน

• อยากให้มีการทำ visualization ด้าน networking มากกว่านี้

  • โดยเฉพาะการมองเห็นทราฟฟิกในระดับการเชื่อมต่อ low-level

• TCP-over-TCP อาจเพิ่ม overhead และ latency จนทำให้ประสิทธิภาพลดลง

  • ใน SSH tunnel มักไม่เป็นปัญหา เว้นแต่จะใช้ TAP/TUN
  • แต่หากใช้หลาย channel ก็อาจเกิดปัญหาด้านประสิทธิภาพได้

• SSH tunnel เป็นเครื่องมือที่ยอดเยี่ยม แต่ทุกวันนี้มักใช้เครื่องมือที่มี TLS และความสามารถ reverse proxy ในตัวมากกว่า

  • รายชื่อเครื่องมือที่เกี่ยวข้อง: awesome-tunneling

• sshuttle เป็นเครื่องมือที่ดีกว่าสำหรับงาน tunneling

  • สามารถใช้คำสั่ง sshuttle -r user@host 10.0.0.0/8 เพื่อใช้งานในลักษณะคล้าย VPN

• เริ่มใช้ SSH tunnel เพื่อหลบเลี่ยงไฟร์วอลล์ของเครือข่ายมหาวิทยาลัยเมื่อ 15 ปีก่อน

  • เปลี่ยนพอร์ตเริ่มต้นเป็น 443 แล้วใช้งาน
  • หลังจากนั้นก็ใช้ต่อในหลายกรณีนอกเหนือจากการเลี่ยงไฟร์วอลล์

• สงสัยว่าใน SSH เองมีความสามารถด้าน redirect หรือไม่

  • ถ้า A พยายามเชื่อมต่อ SSH ไปยัง B แล้ว B บอกให้ไปเชื่อมต่อ C จากนั้น A ก็เชื่อมต่อ C โดยตรงแบบโปร่งใส
  • ทำให้ B ไม่ต้องเป็นส่วนหนึ่งของเส้นทางข้อมูลสำคัญอีกต่อไป
  • อยากรู้ว่ามีฟีเจอร์ลักษณะนี้อยู่หรือไม่