SSH3 - เชลล์ปลอดภัยที่เร็วและครบเครื่องยิ่งขึ้นด้วย HTTP/3

 (github.com/francoismichel)
8 คะแนน โดย GN⁺ 2025-09-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • SSH3 คือ โปรโตคอลเชลล์ปลอดภัย ยุคถัดไปที่ทำงานบน HTTP/3 โดยช่วยเพิ่ม ความเร็วในการเชื่อมต่อเซสชัน ได้อย่างมากเมื่อเทียบกับ SSHv2 แบบดั้งเดิม
  • ใช้ QUIC และ TLS 1.3 เพื่อสร้างช่องทางสื่อสารที่ปลอดภัย และรองรับระบบยืนยันตัวตนสมัยใหม่อย่าง OAuth 2.0, OpenID Connect
  • สามารถซ่อนเซิร์ฟเวอร์ไว้หลังเส้นทางลับได้ จึงทนทานต่อการโจมตีอย่าง การสแกนพอร์ต และยังมี ฟีเจอร์ใหม่ เช่น UDP port forwarding/QUIC multipath
  • ได้นำความสามารถหลักหลายอย่างของ OpenSSH มาใช้แล้ว แต่ปัจจุบันยังอยู่ในขั้น ทดลอง จึงไม่แนะนำให้นำไปใช้งานจริงในสภาพแวดล้อม production
  • มีความเห็นจำนวนมากว่าชื่อ SSH3 อาจไม่เหมาะสม ทำให้ร่างมาตรฐานถูกเปลี่ยนเป็น “Remote Terminals over HTTP/3” และกำลังอยู่ระหว่างการเปลี่ยนชื่อ

ภาพรวมและความสำคัญของโครงการ SSH3

  • SSH3 เป็นโซลูชันโอเพนซอร์สที่ออกแบบโปรโตคอล SSH เดิมขึ้นใหม่ให้สอดคล้องกับ HTTP/3 และเทคโนโลยีเว็บสมัยใหม่
    • นำความหมายของโปรโตคอลการเชื่อมต่อ SSH เดิม (RFC4254) มาสร้างใหม่บน HTTP/3 Extended CONNECT และช่องทาง QUIC+TLS 1.3
  • ถูกเสนอเป็นร่างอินเทอร์เน็ตของ IETF draft-michel-remote-terminal-http3 โดยช่วยลด ความเร็วในการเชื่อมต่อเซสชัน ได้อย่างมาก พร้อมมอบข้อดีหลากหลาย เช่น การขยายรูปแบบการยืนยันตัวตนสมัยใหม่
  • เมื่อเทียบกับ implementation SSH อื่น ๆ จุดเด่นคือแนวคิดใหม่อย่างการใช้ QUIC และ การตั้งค่าเซิร์ฟเวอร์แบบซ่อนตัว

ฟีเจอร์และคุณสมบัติหลัก

  • การเชื่อมต่อเซสชันที่รวดเร็ว
    • การเชื่อมต่อ SSHv2 เดิมโดยเฉลี่ยต้องใช้การไปกลับของเครือข่าย 5~7 ครั้ง ขณะที่ SSH3 ต้องการเพียง 3 รอบการไปกลับ จึงลดเวลา等待ที่ผู้ใช้รับรู้ได้อย่างมาก
    • ความหน่วงของการพิมพ์คีย์ (latency) ยังคงอยู่ในระดับเดิม
  • ความปลอดภัยที่เสริมแกร่งขึ้น
    • อิงกับ TLS1.3, QUIC, และ HTTP authentication โดยใช้โปรโตคอลความปลอดภัยที่ผ่านการพิสูจน์แล้วซึ่งถูกใช้ในอีคอมเมิร์ซและอินเทอร์เน็ตแบงก์กิ้งอยู่แล้ว
    • รองรับวิธียืนยันตัวตนหลากหลาย ทั้งแบบกุญแจสาธารณะบนพื้นฐาน RSA, EdDSA/ed25519 รวมถึง OAuth 2.0, OpenID Connect
    • สามารถล็อกอินด้วยบัญชี Google, Microsoft และ Github ได้เช่นกัน
  • ความสามารถในการซ่อนเซิร์ฟเวอร์
    • สามารถวางเซิร์ฟเวอร์ไว้หลัง URL ลับ เฉพาะ (เช่น https://192.0.2.0:443/M3MzkxYWMx... เป็นต้น) และตอบกลับเฉพาะเมื่อมีคำขอยืนยันตัวตนเข้ามาที่ URL นั้น
    • สำหรับคำขออื่นทั้งหมดจะตอบกลับเป็น 404 Not Found ทำให้ผู้โจมตีหรือ crawler บนอินเทอร์เน็ตไม่สามารถทราบการมีอยู่ของเซิร์ฟเวอร์ได้
    • อย่างไรก็ตาม เส้นทางลับไม่ใช่สิ่งทดแทนการยืนยันตัวตน จึงแนะนำให้ใช้กลไกยืนยันตัวตนแยกต่างหากเสมอ เช่น กุญแจสาธารณะ รหัสผ่าน หรือ OIDC
  • โครงการเชิงทดลองที่ยังพัฒนาอย่างต่อเนื่อง
    • ยังต้องการการตรวจสอบความปลอดภัยเชิงโครงสร้างอย่างน่าเชื่อถือ และ ไม่แนะนำให้นำไปใช้กับเซิร์ฟเวอร์ production
    • ปัจจุบันกำลังรวบรวม feedback จากชุมชนในสภาพแวดล้อมทดลองหรือเครือข่ายปิด
  • ความเข้ากันได้กับ OpenSSH และฟีเจอร์เพิ่มเติม
    • รองรับการแยกวิเคราะห์ ~/.ssh/authorized_keys และ known_hosts, การเชื่อมต่อกับ ssh-agent, TCP/UDP port forwarding และ Proxy Jump
    • รองรับ UDP forwarding เพื่อเปิดทางเข้าถึงเซิร์ฟเวอร์ที่ใช้ UDP เช่น DNS·RTP·QUIC services โดยใช้เส้นทาง QUIC datagram
    • มีความสามารถยืนยันตัวตนเซิร์ฟเวอร์ระดับ HTTPS ผ่าน ใบรับรอง X.509
    • การยืนยันตัวตนแบบไร้กุญแจ (Keyless): ใช้ OpenID Connect เพื่อเชื่อมต่อได้โดยไม่ต้องคัดลอกกุญแจสาธารณะ ผ่าน SSO ขององค์กรหรือบัญชีภายนอกอย่าง Google/GitHub

บทสรุป

  • SSH3 เป็นโครงการโอเพนซอร์สเชิงทดลองที่ผลักดันการพัฒนาโลก SSH ด้วยการนำ โปรโตคอลเครือข่ายและการยืนยันตัวตนสมัยใหม่ มาใช้
  • แม้จะยกระดับความเร็ว ความยืดหยุ่น และความปลอดภัยอย่างมาก แต่ก่อนผ่านการตรวจสอบอย่างเพียงพอ ก็ควร ระมัดระวังในการใช้งานจริง
  • มอบประสบการณ์ผู้ใช้ที่คล้ายกับ OpenSSH พร้อมฟีเจอร์ใหม่ที่หลากหลาย
  • หากผ่านการประเมินด้านความปลอดภัยอย่างเหมาะสมและได้รับการมีส่วนร่วมจากชุมชน ก็มีศักยภาพที่จะก้าวเป็น SSH ยุคถัดไปได้

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

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

 
GN⁺ 2025-09-28
ความคิดเห็นจาก Hacker News
  • ไม่ค่อยชอบชื่อ ssh3 เท่าไรนัก แต่ชอบที่มีเขียนไว้บนสุดของ repo ว่า “SSH3 จะมีการเปลี่ยนชื่อในอนาคต ตอนนี้ยังเป็น SSH Connection Protocol (RFC4254) ที่ทำงานอยู่บน HTTP/3 Extended connect แต่เพราะต้องเปลี่ยนหลายอย่างและต่างจาก SSH เดิมมากเกินกว่าจะรวมเข้าด้วยกันได้ง่าย ๆ ตอนนี้ร่างสเปกจึงเปลี่ยนชื่อเป็น ‘Remote Terminals over HTTP/3’ แล้ว และเราต้องการเวลาเพื่อหาชื่อถาวรที่ดีกว่านี้”
    • ชื่อแบบนี้ให้ความรู้สึกแปลก ๆ เหมือนมีใครไปสร้าง repo ชื่อ “Windows 12” หรือ “Linux 7”
    • มีคนเสนอชื่ออย่าง Secure Hypertext Interactive TTY แทน SSH3
    • ลองคิดว่า SSH/3 ก็น่าจะดีเหมือนกัน (ให้ฟีล SSH + HTTP/3)
    • Thread นี้ถือเป็นงานคลาสสิกของการถกเถียงแบบ ‘bike-shedding’ อย่างแท้จริง
    • คิดว่า SSH2/3 ก็อาจใช้ได้ เพราะส่วนใหญ่ยังเป็น SSH2 แต่รันอยู่บน HTTP/3
  • มีความเห็นว่า SSH นั้นช้า และจากประสบการณ์ของตัวเองคอขวดใหญ่สุดอยู่ที่การตั้งค่า session ไม่ว่าจะเป็นเพราะ PAM หรือ policy ของ OpenBSD ก็ตาม ไม่ว่าจะ reuse การเชื่อมต่อ SSH เดิมหรือสร้างใหม่ ขั้นตอนตั้งค่า session ก็ยังช้ามากทุกครั้ง สำหรับ session ยาว ๆ ก็พอรับได้ แต่ถ้าจะแค่รันคำสั่งสั้น ๆ ครั้งเดียวก็ยังมี overhead ทุกครั้ง ทำให้ไม่ค่อยพอใจกับประสิทธิภาพของ Ansible เลยถึงขั้นไปทำ mini ansible สำหรับรัน remote command ที่ไม่มี session overhead ขึ้นมาเอง
  • ตอนแรกสงสัยว่า ‘มันเร็วกว่า SSH แบบดั้งเดิมจริงเหรอ?’ แต่พออ่าน README แล้วบอกว่าเร็วแค่ช่วงตั้งค่าการเชื่อมต่อ ส่วนความเร็วจริงหลังเชื่อมต่อแล้วเท่าเดิม ก็รู้สึกเข้าใจได้ แบบนี้ก็ถือว่าเป็นการปรับปรุงที่สมเหตุสมผล
    • จริง ๆ แล้วในแง่นั้นมันไม่ได้เร็วกว่าเสมอไป แต่เวลามีการ forward traffic หลายพอร์ตผ่าน SSH connection เดียว จะเกิด head-of-line blocking ซึ่ง QUIC/HTTP3 แก้ปัญหานี้ได้
    • ขอยอมพนันเลยว่าโปรโตคอลนี้จะเร็วกว่า SSH มากบนลิงก์ที่มี latency สูง เพราะใช้ UDP จึงส่งข้อมูลจำนวนมากต่อเนื่องได้โดยไม่ต้องรอ ack เลยคาดว่าเวลาส่งไฟล์ใหญ่ด้วย scp ข้ามโลกน่าจะเร็วขึ้นมาก
    • บน VPN มันอาจเร็วจริง เพราะไม่มีปัญหา "TCP ซ้อน TCP"
    • ข้อดีหลักของ HTTP/3 และ QUIC โดยรวมคือการลดจำนวน round trip เมื่อเทียบกับของเดิม ซึ่งก็สอดคล้องกับการตั้งค่าการเชื่อมต่อที่เร็วขึ้น
  • มีคำอธิบายว่า “SSHv2 ต้องใช้ราว 5–7 round trip ในการเริ่มต้น session แต่ SSH3 ใช้แค่ 3 ครั้ง ระหว่าง session จริง latency ของการพิมพ์กับการตอบสนองยังเท่าเดิม” จากมุมผู้ใช้ส่วนตัวไม่เคยรู้สึกว่าความเร็วการเชื่อมต่อเป็นเรื่องสำคัญมากนัก เลยยังไม่ค่อยรู้สึกดึงดูด เพราะ SSH มีความเสถียรที่ผ่านการพิสูจน์มาอย่างหนักแล้ว และเครื่องมือใหม่แบบนี้ต่อให้พร้อมระดับ production จริงก็ยังเสี่ยงเกินกว่าจะเชื่อใจ
    • UDP tunnel คือฟีเจอร์สำคัญ มันเบากว่า wireguard มาก และยังมีอย่างเช่นการยืนยันตัวตนด้วย OpenID
    • ‘ความเร็วการเชื่อมต่อ’ เป็นสิ่งที่รบกวนผมอยู่เรื่อย ๆ โดยเฉพาะเวลาต้องรันคำสั่งจากระยะไกลแบบทันทีแล้วมันช้า
    • ใน ssh3 มีแนวโน้มว่าจะจัดการปัญหา head-of-line blocking ได้แล้ว ถ้ามีการ multiplex หลายพอร์ตหรือหลาย connection บน physical connection เดียวก็น่าจะเร็วขึ้น
    • ถ้าต้องการประสบการณ์ใช้งานที่ลื่นไหล แนะนำ Mosh
  • ไม่รู้ทำไม แต่รู้สึกเศร้านิด ๆ ที่โปรโตคอลชั้น application ทุกอย่างกำลังถูกดูดเข้าไปอยู่ใน http
    • ถ้ามันไปทางนั้นจริงก็น่าเศร้าอยู่เหมือนกัน โมเดลแบบฉบับของ HTTP มีข้อจำกัดและซับซ้อนเกินไปสำหรับหลายกรณีใช้งาน แต่ HTTP/2 หรือ QUIC (transport ของ HTTP/3) นั้นอเนกประสงค์มากจนชื่อ HTTP เองแทบไม่มีความหมายมากนัก อย่างน้อย QUIC ก็ถูกใช้ในตำแหน่งที่ค่อนข้างชัดว่าเป็นตัวแทน TCP
    • จริง ๆ แล้วถ้าโปรโตคอลต่าง ๆ ถูกทำให้เป็นมาตรฐานแบบนี้ ก็อาจมองในแง่ดีได้เพราะทำให้ traffic shaping หรือการเซ็นเซอร์ทำได้ยากขึ้น สุดท้ายถ้า traffic เป็น HTTP หรือเป็น random byte stream (คือไม่เด่นสะดุดตา) ก็ยากต่อการเฝ้าระวังหรือบล็อกบนเครือข่าย ถ้าจะสร้างโปรโตคอลใหม่ ตราบใดที่ ISP ไม่ได้ให้สิทธิพิเศษอะไรเป็นพิเศษ การปลอมตัวเป็น HTTP ก็มักเป็นวิธีที่ไม่ช้าลงและผ่านได้ดี
    • ปรากฏการณ์แบบนี้เป็นผลจากธรรมเนียมของทีม security ฝั่งองค์กรที่ชอบบล็อกหรือขวางทุกอย่าง พูดถึงพวกทีมที่ใช้ Zscaler หรือโหมด TLS man-in-the-middle นั่นแหละ
    • การบล็อกแบบนี้เจอได้แม้แต่บน Wi‑Fi สนามบินหรือโรงแรมทั่วโลก เช่น Apple Mail ส่งเมลไม่ได้ เพราะนโยบายองค์กรบล็อกพอร์ต 25 โดยอ้างกันสแปม แล้วก็ลามไปบล็อก 143, 587, 993 จนสุดท้ายปล่อยผ่านแค่ 80 กับ 443 หวังว่า IPv6 จะช่วยให้ดีขึ้นบ้าง และอยากให้เรื่องอย่างการผลักดัน ChatControl ของ EU หยุดสักที อยากให้เขาฟังคนที่เข้าใจ IT จริง ๆ บ้าง
    • ก็พอเข้าใจได้ว่าเพราะ connection init หรือความซับซ้อนของการเริ่มต้นการเชื่อมต่อเครือข่ายสูงขึ้น สุดท้ายจึงต้องอาศัย best practice บนโปรโตคอลที่ผ่านการพิสูจน์แล้ว แต่พอการรับส่งจริงไม่ได้เป็น hypertext อีกต่อไป การยังเรียกมันว่า http ก็ให้ความรู้สึกแปลก ๆ
  • การที่ความสามารถของ SSH ยังพัฒนาต่อเป็นเรื่องดี แต่ถ้าจะทำใหม่แทบทั้งหมดอยู่แล้ว ก็แอบเสียดายที่ไม่ได้ใส่ฟีเจอร์ใหม่เชิงทดลองมากกว่านี้ เช่นความสามารถแบบ Mosh สำหรับรองรับ “roaming/เครือข่ายไม่เสถียรชั่วคราว” https://mosh.org/
    • จุดเด่นของ Mosh คือการตอบสนองต่อการพิมพ์เร็วมาก ให้ความรู้สึกเหมือนทำงานบน local shell โดยตรง เลยสงสัยว่า SSH3 มีการปรับปรุงด้านนี้ไหม QUIC อาจช่วยได้บ้างเล็กน้อย แต่ก็ไม่เหมือน Mosh
    • เท่าที่เข้าใจ connection migration กับ multipath เป็นคุณสมบัติพื้นฐานของ QUIC อยู่แล้ว ส่วนความต่างระหว่างฟีเจอร์ roaming กับ 'tmux ในตัว' นั้น ยังไม่แน่ใจว่าการที่มันถูกรวมไว้ในระบบโดยตรงมีคุณค่ามากแค่ไหน
  • สงสัยคนที่หมกมุ่นกับชื่อย่อหรือคำย่อสั้น ๆ มาก มันไม่ค่อยดีเลย ทุกวันนี้คิดว่าชื่อคำสั่งจะยาวหน่อยก็ได้ ขอให้ชัดเจนทางเทคนิคที่สุดจะดีกว่า ควรใช้ชื่อเต็มเป็นหลัก ส่วนชื่อย่อค่อยให้ผู้ดูแลระบบบางกลุ่มหรือดิสโทรย่อใช้กันเอง คนทั่วไปควรถูกสอนชื่อเต็ม เช่น Set-Location ดูดีกว่า cd และชื่ออย่าง remote-terminals-over-http3 ก็ดีกว่า ssh3
  • commit ล่าสุดก็ 1 ปีแล้ว มีใครรู้ความคืบหน้าล่าสุดของโปรเจกต์นี้บ้างไหม?
  • เริ่มสงสัยแผนของโปรเจกต์แล้ว ทั้ง release และกิจกรรมบน GitHub ก็เงียบมาเกินปี อาจเป็นเพราะมันเริ่มจากงานวิจัย เลยยังทำงานวิจัยที่เกี่ยวข้องหรือโปรเจกต์รองอื่น ๆ อยู่ก็ได้
    • ขอบคุณที่ชี้ประเด็นนี้ สำหรับผมส่วนตัวมองว่าโปรเจกต์นี้น่าจะจบแล้ว มีประมาณ 239 commits จึงยังเป็นแค่ระดับ Proof of Concept มากกว่า ยังไม่ใช่อะไรที่พร้อมใช้จริงจัง ตรงกันข้ามฝั่ง OpenBSD (OpenSSH) ยัง active มากอยู่ เลยยังดูไม่ใช่สิ่งที่จะมาแทนได้ในเร็ว ๆ นี้ https://github.com/openbsd/src/commits/master/
  • ไอเดียของโปรเจกต์ถือว่าดี โดยเฉพาะถ้าสามารถ proxy ผ่าน H3 proxy ทั่วไปได้ยิ่งน่าสนใจมาก และถ้ายังแก้เรื่อง multipath/migration กับปัญหา blocking ที่เกี่ยวกับ TCP ได้ด้วย ก็ถือว่าเป็นความก้าวหน้าครั้งใหญ่มาก