การเชื่อมต่อ SSH ผ่าน HTTPS

 (trofi.github.io)
3 คะแนน โดย GN⁺ 2023-12-25 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ส่ง SSH ผ่าน HTTPS

  • การส่ง SSH ผ่าน HTTPS ต้องปรับทั้งฝั่งไคลเอนต์และเซิร์ฟเวอร์
  • ในตัวอย่างการตั้งค่าไคลเอนต์ มีการตั้งค่า ProxyCommand และ ServerAliveInterval ในไฟล์ ~/.ssh/config
  • สคริปต์ ~/.ssh/https-tunnel.bash ที่ใช้ จะส่งเมธอด CONNECT พร้อมเฮดเดอร์ และใช้ socat เพื่อสร้างการเชื่อมต่อ TLS

ตัวอย่างการตั้งค่าเซิร์ฟเวอร์

  • ในการตั้งค่าเซิร์ฟเวอร์ HTTPS ของ Apache2 จะโหลด proxy_connect_module และใช้คำสั่ง AllowCONNECT เพื่ออนุญาตให้ใช้เมธอด HTTP CONNECT กับปลายทางที่กำหนด
  • ฝั่งเซิร์ฟเวอร์มีการตั้งค่าให้ใช้เมธอด CONNECT ได้เฉพาะสำหรับโฮสต์ ssh-server ซึ่งเป็นปลายทางเดียวจาก https-server

ที่มา

  • ระหว่างพักอยู่ในโรงพยาบาล ผู้เขียนต้องการทำงานระยะไกลผ่าน Wi-Fi ของโรงพยาบาลที่บล็อกการเชื่อมต่อเกือบทุกประเภท
  • เครือข่ายของโรงพยาบาลอนุญาตเฉพาะการเชื่อมต่อ HTTP และ HTTPS เท่านั้น และบล็อก SSH อย่างสมบูรณ์
  • จึงได้สำรวจวิธีการส่ง SSH ผ่าน HTTP หรือ HTTPS

วิธีที่เป็นไปได้

  • โปรเจกต์ sslh สำหรับโฮสต์ร่วมกันทั้งโปรโตคอล SSH และ HTTPS บนพอร์ตเดียว แล้วกระจายไปยังปลายทางอย่างโปร่งใส
  • sslh ไม่ได้ห่อโปรโตคอลหนึ่งไว้ในอีกโปรโตคอลหนึ่ง แต่ใช้ฮิวริสติกหลายแบบเพื่อรีไดเร็กต์ไปยังแบ็กเอนด์จริง
  • วิธีใช้คำสั่ง ProxyCommand ของ openssh เพื่อห่อโปรโตคอล SSH ไว้อย่างสมบูรณ์ภายในอีกโปรโตคอลหนึ่ง

SSH over HTTP

  • สำหรับการลองทำ SSH over HTTP แบบง่าย มีการตั้งค่า Apache2 ให้อนุญาตเมธอด CONNECT สำหรับปลายทางเดียว ssh-server:22
  • ฝั่งไคลเอนต์สามารถปรับได้อย่างง่ายดายด้วย socat
  • ใช้ ServerAliveInterval เพื่อไม่ให้การเชื่อมต่อ HTTP หลุดแม้อยู่ในสถานะว่าง

SSH over HTTPS

  • socat ไม่รองรับ HTTPS proxy แต่รองรับการห่อหุ้มด้วย TLS
  • สามารถเขียนเมธอดที่อิงกับ CONNECT ขึ้นเองได้ไม่ยาก
  • ใช้สคริปต์ ~/.ssh/https-tunnel.bash เพื่อทำ SSH over HTTPS tunneling

สรุป

  • การมีอยู่ทั่วไปของ HTTPS ช่วยให้สามารถส่งข้อมูลผ่านอุปกรณ์ตัวกลางที่มีข้อจำกัดสูงได้
  • เมธอด CONNECT เป็นเทคนิคที่มีประโยชน์ในการห่อสตรีมเพย์โหลด TCP ไว้ในสตรีมโฮสต์ TLS
  • ServerAliveInterval ถูกใช้เพื่อคงการเชื่อมต่อไว้สำหรับชั้นการส่งข้อมูลที่ไม่เป็นมิตรกับการเชื่อมต่อที่ว่างอยู่

ความเห็นจาก GN⁺

  • ประเด็นสำคัญที่สุดของบทความนี้คือการนำเสนอวิธีแก้ปัญหาอย่างสร้างสรรค์เพื่อให้สามารถเชื่อมต่อ SSH ได้แม้อยู่ในสภาพแวดล้อมเครือข่ายที่จำกัด
  • วิธีผสาน SSH กับ HTTPS อาจน่าสนใจเป็นพิเศษสำหรับผู้ที่มีความรู้ด้านความปลอดภัยเครือข่าย
  • การตั้งค่า ProxyCommand และ ServerAliveInterval เพื่อหลบข้อจำกัดของเครือข่ายเป็นข้อมูลที่มีประโยชน์สำหรับผู้ดูแลเครือข่ายหรือผู้เชี่ยวชาญด้านความปลอดภัย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-25
ความเห็นจาก Hacker News
  • ผู้ให้บริการอินเทอร์เน็ต XS4ALL ของเนเธอร์แลนด์เคยให้บริการการเชื่อมต่อ SSH ผ่านพอร์ต 80 มาก่อน ฟีเจอร์นี้มีประโยชน์เมื่อพอร์ตอื่นถูกบล็อก เช่น ในเครือข่าย Wi‑Fi ของโรงแรม
  • การมีอยู่ทั่วไปของ HTTPS ทำให้สามารถส่งข้อมูลผ่านอุปกรณ์ตัวกลางที่มีข้อจำกัดมากได้ นี่คือเหตุผลหลักที่โปรโตคอล VPN แบบกรรมสิทธิ์ที่เรียกว่า SSL VPN มักมีโหมดสำหรับเริ่มต้น tunnel ผ่าน HTTPS
  • ยังสามารถรัน SSH บนพอร์ต 80 หรือ 443 แล้วใช้ ProxyJump ผ่านโฮสต์อื่น หรือใช้ SOCKS เพื่อให้ได้การเชื่อมต่ออินเทอร์เน็ตที่ถูกจำกัดน้อยกว่าได้ นอกจากนี้ยังสามารถฟอร์เวิร์ด DNS ผ่าน TLS ผ่านการเชื่อมต่อ SSH ได้ด้วย
  • บริษัทชื่อ Adaptive กำลังสร้างโครงสร้างพื้นฐานด้านความปลอดภัยข้อมูลที่ให้บริการ SSH และโปรโตคอลอื่น ๆ ผ่าน HTTP3 ซึ่งช่วยให้ผู้ใช้เชื่อมต่อกับฐานข้อมูล เซิร์ฟเวอร์ และทรัพยากรอื่น ๆ ผ่านพอร์ตภายนอกได้
  • ในทางปฏิบัติ ไฟร์วอลล์ส่วนใหญ่สามารถหลบเลี่ยงได้เพียงแค่ให้ openssh รอฟังอยู่บนพอร์ต 443
  • การมองเมธอด CONNECT เหมือน reverse proxy แทนที่จะเป็น forward proxy เป็นมุมมองที่น่าสนใจ แต่ CONNECT อย่างเดียวไม่พอ จึงมีการใช้ SSH ผ่าน WebSocket เพื่อหลบเลี่ยงพร็อกซีขององค์กร
  • ความถี่ของโพสต์เกี่ยวกับวิธีแก้ปัญหา "ใหม่" ทำให้รู้สึกไม่สบายใจ แนวคิดเหล่านี้ไม่ใช่เรื่องใหม่ และมีคนจำนวนมากรู้อยู่แล้ว
  • คงจะดีถ้ามีระบบจัดการตัวตนที่คล้าย SSH ฝังอยู่ในเบราว์เซอร์ ตอนที่ได้อ่านข้อเสนอการยืนยันตัวตน HTTP ด้วยกุญแจสาธารณะชื่อ hobo ครั้งแรกก็ตื่นเต้นมาก แต่กลับพบว่าไม่มี implementation ฝั่งเซิร์ฟเวอร์ และฝั่งไคลเอนต์ (เบราว์เซอร์) ก็ไม่มีเช่นกัน
  • เมื่อราว 20 ปีก่อน เคยใช้เครื่องมือชื่อ corkscrew เพื่อผ่านไฟร์วอลล์ขององค์กร implementation และคำอธิบายแบบอิสระของเครื่องมือนี้น่าประทับใจมาก
  • การทำ tunneling ผ่าน HTTP2 เป็นตัวเลือกที่ยอดเยี่ยม มี gRPC ซึ่งเป็นโปรโตคอล RPC ที่สร้างอยู่บน HTTP2 โดย HTTP2 โดดเด่นในการส่งและรับโครงสร้างข้อมูลหลายชุดพร้อมกันผ่านการเชื่อมต่อ TCP เดียว อย่างไรก็ตามอาจไม่จำเป็นต้องใช้ HTTP3 เพราะตัว QUIC เองก็มี multiplexing อยู่แล้ว