SSH3 - Shell bảo mật nhanh hơn và phong phú hơn dùng HTTP/3

• SSH3 là giao thức shell bảo mật thế hệ mới chạy trên HTTP/3, cải thiện mạnh tốc độ thiết lập phiên so với SSHv2 truyền thống
• Thông qua QUIC và TLS 1.3, nó hình thành kênh bảo mật và hỗ trợ các hệ thống xác thực hiện đại như OAuth 2.0 và OpenID Connect
• Có thể ẩn máy chủ sau một đường dẫn bí mật, nhờ đó chống chịu tốt hơn trước các cuộc tấn công như quét cổng, đồng thời cung cấp tính năng mới như chuyển tiếp cổng UDP và QUIC multipath
• Dự án đã tiếp nhận nhiều tính năng cốt lõi của OpenSSH, nhưng hiện vẫn ở giai đoạn thử nghiệm, nên không khuyến nghị triển khai trong môi trường vận hành thực tế
• Do có nhiều ý kiến cho rằng tên SSH3 không phù hợp, bản thảo tiêu chuẩn đã được đổi thành “Remote Terminals over HTTP/3”, và quá trình đổi tên đang được tiến hành

---

Tổng quan và tầm quan trọng của dự án SSH3

• SSH3 là một giải pháp mã nguồn mở tái thiết kế giao thức SSH hiện có để phù hợp với HTTP/3 và các công nghệ web hiện đại
  • Tái cấu trúc ngữ nghĩa của giao thức kết nối SSH hiện tại (RFC4254) trên HTTP/3 Extended CONNECT và kênh QUIC+TLS 1.3
• Dự án được đề xuất dưới dạng bản thảo Internet của IETF draft-michel-remote-terminal-http3, giúp giảm đáng kể thời gian thiết lập phiên và mang lại nhiều ưu điểm như mở rộng phương thức xác thực hiện đại
• So với các triển khai SSH khác, những ý tưởng đổi mới như sử dụng QUIC và cấu hình máy chủ ẩn là điểm nổi bật

Các chức năng và đặc điểm chính

• Thiết lập phiên nhanh
  • Trong khi kết nối SSHv2 truyền thống trung bình cần 5~7 vòng khứ hồi mạng, SSH3 chỉ cần 3 vòng khứ hồi, giúp giảm đáng kể độ trễ mà người dùng cảm nhận
  • Độ trễ gõ phím (latency) vẫn được giữ ở mức tương đương trước đây
• Bảo mật được tăng cường
  • Dựa trên TLS1.3, QUIC và xác thực HTTP, tận dụng các giao thức bảo mật đã được kiểm chứng và đang dùng trong thương mại điện tử, ngân hàng trực tuyến, v.v.
  • Hỗ trợ nhiều phương thức xác thực như khóa công khai dựa trên RSA, EdDSA/ed25519 và OAuth 2.0, OpenID Connect
  • Cũng có thể đăng nhập bằng tài khoản Google, Microsoft và Github
• Khả năng ẩn máy chủ
  • Có thể đặt máy chủ sau một URL bí mật cụ thể (ví dụ: https://192.0.2.0:443/M3MzkxYWMx...); chỉ phản hồi khi có yêu cầu xác thực đi vào đúng URL đó
  • Với các yêu cầu khác, trả về 404 Not Found, khiến kẻ tấn công hoặc crawler trên Internet không thể nhận biết sự tồn tại của máy chủ
  • Tuy nhiên, đường dẫn bí mật không thay thế cho xác thực, nên vẫn được khuyến nghị bắt buộc sử dụng cơ chế xác thực riêng biệt như khóa công khai, mật khẩu, OIDC, v.v.
• Dự án thử nghiệm đang tiếp tục được phát triển
  • Về mặt cấu trúc, dự án cần được kiểm chứng bảo mật một cách đáng tin cậy, và không khuyến nghị áp dụng trên máy chủ production
  • Hiện đang thu thập phản hồi từ cộng đồng trong môi trường thử nghiệm hoặc mạng khép kín
• Tương thích OpenSSH và các tính năng bổ sung
  • Hỗ trợ phân tích ~/.ssh/authorized_keys và known_hosts, tích hợp ssh-agent, chuyển tiếp cổng TCP/UDP, và Proxy Jump
  • Hỗ trợ chuyển tiếp UDP, mở đường truy cập đến các máy chủ dùng UDP như DNS, RTP, QUIC service, thông qua đường dẫn QUIC datagram
  • Cung cấp khả năng xác thực máy chủ ở mức HTTPS thông qua chứng chỉ X.509
  • Xác thực không cần khóa (Keyless): với OpenID Connect, có thể kết nối bằng SSO doanh nghiệp hoặc tài khoản bên ngoài như Google/GitHub mà không cần sao chép khóa công khai

Kết luận

• SSH3 là một dự án mã nguồn mở mang tính thử nghiệm, thúc đẩy sự tiến hóa của môi trường SSH bằng cách đưa vào các giao thức mạng và xác thực hiện đại
• Dù cải thiện mạnh về tốc độ, tính linh hoạt và bảo mật, vẫn cần thận trọng khi dùng trong môi trường production trước khi được kiểm chứng đầy đủ
• Dự án mang lại trải nghiệm người dùng tương tự OpenSSH, đồng thời có thêm nhiều tính năng mới phong phú.
• Với đánh giá bảo mật đúng mức và sự tham gia của cộng đồng, nó có tiềm năng trở thành SSH thế hệ tiếp theo

[GN⁺]

Ý kiến trên Hacker News

• Tôi thực sự không thích cái tên ssh3, nên thấy vui khi ngay đầu repo có ghi rằng: “SSH3 sẽ được đổi tên. Hiện tại nó vẫn là SSH Connection Protocol (RFC4254) chạy trên HTTP/3 Extended CONNECT, nhưng cần rất nhiều thay đổi và khác SSH hiện có đến mức không thể tích hợp dễ dàng. Bản thảo đặc tả đã được đổi thành ‘Remote Terminals over HTTP/3’, và chúng tôi cần thời gian để nghĩ ra một cái tên lâu dài tốt hơn”
  • Kiểu tên này nghe như ai đó tạo một repo tên là “Windows 12” hay “Linux 7”, cảm giác rất không hợp
  • Tôi đề xuất tên như Secure Hypertext Interactive TTY thay cho SSH3
  • Tôi từng nghĩ SSH/3 có thể ổn hơn (mang cảm giác SSH + HTTP/3)
  • Thread này thực sự là một kiệt tác tranh luận kiểu ‘bike-shedding’
  • Tôi cũng nghĩ SSH2/3 có thể hợp lý, vì phần lớn vẫn là SSH2 nhưng chạy trên HTTP/3
• SSH thì chậm, và theo kinh nghiệm của tôi, nút thắt lớn nhất nằm ở bước thiết lập phiên. Dù là do PAM hay do chính sách của OpenBSD, mỗi lần tạo hay tái sử dụng kết nối SSH thì bước thiết lập phiên đều chậm một cách nghiêm trọng. Với các phiên dài thì không sao, nhưng ngay cả khi chỉ muốn chạy một lệnh đơn giản cũng luôn có overhead, nên tôi chưa từng hài lòng với hiệu năng của Ansible, và cuối cùng đã tự làm một mini ansible để chạy lệnh từ xa mà không có overhead của phiên
• Ban đầu tôi khá nghi ngờ kiểu “Cái này thật sự nhanh hơn SSH truyền thống à?”, nhưng đọc README thì thấy chỉ là bước thiết lập kết nối nhanh hơn, còn tốc độ thực tế sau khi kết nối là như nhau, nên thấy hợp lý. Chỉ như vậy thôi cũng đã là một cải tiến đáng giá
  • Thực ra theo nghĩa đó thì không hẳn nhanh hơn. Khi một kết nối SSH đơn lẻ chuyển tiếp lưu lượng cho nhiều cổng, sẽ có hiện tượng head-of-line blocking, còn QUIC/HTTP3 có thể giải quyết vấn đề này
  • Tôi sẵn sàng cá rằng giao thức này sẽ nhanh hơn SSH rất nhiều trên các liên kết độ trễ cao, vì nó dựa trên UDP nên có thể gửi liên tục lượng lớn dữ liệu mà không phải chờ ack, nên khi scp các tệp lớn từ khắp nơi trên thế giới có thể kỳ vọng cải thiện tốc độ đáng kể
  • Trên VPN có thể nó sẽ thực sự nhanh hơn, vì không có cái bẫy “TCP bên trong TCP”
  • Ưu điểm chính của HTTP/3, và của toàn bộ QUIC, là giảm số vòng khứ hồi so với trước đây, nên việc thiết lập kết nối nhanh hơn cũng hoàn toàn nhất quán với điều đó
• Giải thích là: “SSHv2 cần khoảng 5–7 vòng khứ hồi để khởi tạo phiên, còn SSH3 chỉ cần 3. Trong suốt thời gian phiên hoạt động, độ trễ đầu vào thực tế (từ lúc gõ phím đến lúc có phản hồi) là như nhau.” Từ góc nhìn người dùng, tôi chưa bao giờ quá bận tâm tới tốc độ kết nối nên không thấy hấp dẫn lắm. SSH còn có độ ổn định đã được kiểm chứng trong thực chiến, nên kể cả nếu công cụ mới này thật sự ở mức production thì việc tin tưởng nó vẫn khá rủi ro
  • Tính năng cốt lõi là đường hầm UDP, nhẹ hơn wireguard rất nhiều, và còn có cả xác thực OpenID
  • ‘Tốc độ kết nối’ lúc nào cũng khiến tôi hơi khó chịu. Đặc biệt là khi muốn chạy lệnh từ xa ngay lập tức mà nó lại chậm
  • Với ssh3, khả năng cao là head-of-line blocking đã được giải quyết, nên khi multiplex nhiều cổng hoặc nhiều kết nối trên một kết nối vật lý thì sẽ nhanh hơn
  • Nếu cần trải nghiệm người dùng mượt mà, tôi khuyên dùng Mosh
• Tôi không hiểu vì sao việc mọi giao thức tầng ứng dụng đều bị hút vào HTTP lại khiến tôi thấy buồn đến vậy
  • Nếu đúng là xu hướng như vậy thì đúng là đáng buồn. Mô hình điển hình của HTTP vừa quá gò bó vừa phức tạp trong đa số trường hợp nên không phù hợp ở nhiều nơi. Nhưng HTTP/2 hay QUIC (lớp truyền tải của HTTP/3) lại quá đa dụng, đến mức cái tên HTTP dường như không còn nhiều ý nghĩa nữa. Ít nhất thì QUIC vẫn được định vị khá rõ như một sự thay thế cho TCP
  • Thật ra nếu mọi giao thức đều được chuẩn hóa theo cách này thì tôi thấy cũng tích cực, vì việc traffic shaping hay kiểm duyệt sẽ khó hơn. Cuối cùng thì nếu lưu lượng là HTTP, hoặc là một luồng byte ngẫu nhiên (tức là không gây chú ý), thì việc giám sát/chặn ở mức mạng sẽ khó hơn. Nếu làm một giao thức mới, trừ khi nhà mạng có lý do đặc biệt để ưu ái nó, còn không thì ngụy trang thành HTTP là cách để nó đi qua mà không bị chậm lại
  • Hiện tượng này là do thói quen của các đội bảo mật doanh nghiệp: cái gì cũng chặn hoặc xen vào. Tôi đang nói đến các đội dùng Zscaler hay chế độ TLS man-in-the-middle đấy
  • Kiểu chặn như vậy cũng xuất hiện ở Wi-Fi sân bay hay khách sạn trên khắp thế giới. Ví dụ việc Apple Mail không gửi được thư cũng là vì chính sách doanh nghiệp chặn cổng 25. Họ bảo là để chống spam nhưng rồi còn chặn luôn 143, 587, 993 v.v., thành ra cuối cùng chỉ cho qua 80 và 443. Hy vọng IPv6 sẽ cải thiện phần nào. Và cũng mong những chuyện như nỗ lực thúc đẩy ChatControl ở EU sẽ dừng lại. Giá mà họ chịu nghe những người thật sự hiểu về CNTT
  • Tôi cũng hiểu rằng độ phức tạp của connection init, tức khởi tạo kết nối mạng, ngày càng cao nên cuối cùng người ta phải dựa vào best practice trên các giao thức đã battle-tested. Nhưng khi phần truyền tải thực tế không còn là hypertext nữa mà vẫn cứ gọi là HTTP thì vẫn thấy hơi kỳ
• Việc tính năng của SSH tiếp tục tiến hóa là điều rất hay, nhưng nếu đã gần như làm lại từ đầu thì tôi cũng hơi tiếc là họ không thêm vài tính năng thử nghiệm táo bạo hơn. Ví dụ những tiện ích như Mosh để xử lý chuyện “roaming / mạng chập chờn tạm thời” sẽ rất hay https://mosh.org/
  • Điểm mạnh của Mosh là phản hồi gõ phím cực nhanh, cảm giác như đang thao tác trực tiếp trên shell cục bộ. Tôi tò mò không biết SSH3 có cải thiện phần này không. QUIC có thể hỗ trợ đôi chút, nhưng vẫn là chuyện khác với Mosh
  • Theo hiểu biết của tôi thì connection migration hay hỗ trợ multipath là đặc tính mặc định của QUIC, còn sự khác biệt giữa tính năng roaming và kiểu ‘tmux tích hợp sẵn’ là tôi không chắc việc nó được tích hợp thẳng vào hệ thống có thật sự mang lại nhiều giá trị đến thế không
• Tôi thật sự không hiểu những người ám ảnh với tên gọi ngắn/viết tắt, thấy rất chán. Giờ lệnh dài một chút cũng không sao, tôi nghĩ nên dùng những cái tên dài nhưng càng rõ nghĩa kỹ thuật càng tốt. Mặc định nên dùng tên đầy đủ, còn viết tắt thì để một số quản trị viên hệ thống hay distro tự rút gọn nếu muốn. Người dùng nên được dạy tên đầy đủ. Ví dụ Set-Location tốt hơn cd, và một cái tên như remote-terminals-over-http3 tốt hơn ssh3
• Commit cuối cùng là từ 1 năm trước, có ai biết tiến triển gần đây của dự án không?
• Tôi bắt đầu tò mò về kế hoạch của dự án. Cả bản phát hành lẫn hoạt động GitHub đều im ắng hơn 1 năm rồi. Vì đây là kiểu dự án bắt đầu từ một bài báo nghiên cứu nên có thể họ vẫn đang tiếp tục các nghiên cứu liên quan hoặc những việc phụ trợ khác
  • Cảm ơn vì đã chỉ ra điểm này. Cá nhân tôi cho rằng dự án này giờ đã chết rồi. Khoảng 239 commit thì thực chất vẫn chỉ ở mức proof of concept, chưa phải thứ đủ nghiêm túc để dùng. Trong khi đó phía OpenBSD (OpenSSH) vẫn cực kỳ năng động, nên hiện giờ chưa thấy nhiều khả năng bị thay thế https://github.com/openbsd/src/commits/master/
• Ý tưởng của dự án thì ổn. Tôi đặc biệt kỳ vọng nếu nó có thể được proxy qua các proxy H3 thông thường. Chỉ riêng việc đó, cộng với multipath/migration và giải quyết các vấn đề blocking liên quan tới TCP, đã là một bước tiến rất lớn