SSH3: SSHv2 using HTTP/3 and QUIC

Original Article ↗ Hacker News Discussion ↗

A new project called “SSH3” proposes reimagining secure shell connections by running SSH-like semantics over HTTP/3 and QUIC, promising faster session setup, better performance on high-latency links, and integration with web-style authentication such as OAuth/OIDC. Commenters are intrigued by potential benefits like easier traversal of locked-down networks and hiding SSH behind standard HTTPS traffic, but many criticize the name as misleading and question the added complexity and attack surface of layering on HTTP when SSH over QUIC alone might suffice. Several point out that traditional SSH already supports certificates, modern crypto and even passkeys, arguing that most gaps could be addressed through incremental improvements rather than a wholesale protocol redesign.

Project status and naming

  • Widely noted that this is a personal/academic project, not an IETF standard, not related to OpenSSH, and not an “official” SSH version.
  • Many consider “SSH3” a misleading or clickbaity name that may confuse users expecting an endorsed SSHv3 protocol.
  • Some argue naming is cosmetic; others see it as a signal of poor judgment and community awareness.

Protocol design: QUIC vs HTTP/3 vs SSHv2

  • Core idea: map SSH-like semantics onto HTTP mechanisms over QUIC+TLS 1.3.
  • Several commenters think SSH-over-QUIC makes sense, but layering HTTP/3 adds unnecessary complexity and attack surface.
  • Others say using HTTP/3 lets the protocol blend into web infrastructure and tooling, and aligns with modern networking stacks.

Authentication & PKI model

  • Project aims to reuse HTTP auth mechanisms (OIDC, OAuth, x.509), tying SSH access into web-style identity.
  • Some see this as a big advantage for enterprise SSO and passkeys; others note SSH already supports certificates, FIDO2/passkeys, and even OIDC via PAM/keyboard-interactive.
  • Concerns about misconfiguration: x.509 and OAuth may be overkill, brittle, or introduce new failure modes.

Security, privacy, and “hiding”

  • QUIC/HTTP/3 encrypts more metadata, which makes network inspection and middlebox security harder; some security practitioners are wary.
  • The “secret URL” / path-based hiding is debated: seen by some as capability-style access, by others as security-through-obscurity that any protocol could adopt (e.g., port knocking).
  • Additional worries: HTTP stacks have a larger history of vulnerabilities (LFI, request smuggling, etc.) than SSH.

Performance and usability

  • Claimed benefits: fewer RTTs for session setup, potential for better throughput on high-latency or long-fat networks, easier traversal of restrictive firewalls (443/HTTP-like traffic).
  • Skeptics say SSH connection latency is rarely a real problem, and OpenSSH already has mitigations (ControlMaster) and high-performance patches (HPN-SSH).

Comparisons to existing tools

  • Mosh and Eternal Terminal are mentioned as mature options for unreliable networks; they solve different problems (roaming, interactivity) and mostly reuse SSHv2.
  • Other existing approaches: SSH over WebSockets, QUIC-based experiments, port sharing via HAProxy/nginx/sslh, DNS SSHFP, SSH certificates.

Future SSH “v3” wishes

  • If an actual SSHv3 emerges, commenters want: QUIC transport, SNI-like routing/metadata, better load-balancing, cleaner auth integration, and larger window sizes—without inheriting full HTTP complexity.