SSH3: Faster and rich secure shell using HTTP/3

Original Article ↗ Hacker News Discussion ↗

Performance & protocol behavior

  • Thread converges that “faster” mostly means fewer RTTs for connection setup; steady‑state throughput and keystroke latency are intended to be comparable to SSH.
  • Several argue QUIC/HTTP‑3 could outperform SSH over high‑latency or “TCP-in-TCP” VPN links, due to better congestion control and native stream multiplexing.
  • Others stress that QUIC still has ACKs and windowing; the win is improved algorithms and multi‑stream design, not “not waiting for ACKs.”
  • Multiple comments note SSH’s own per‑channel window limits hurt throughput on long fat pipes; HPN‑SSH and manual tuning raise buffers but are clunky and not adaptive.
  • QUIC’s per‑stream transport avoids head‑of‑line blocking seen when SSH multiplexes multiple channels over one TCP connection.

Comparison with existing tools (SSH, mosh, VPNs)

  • Many say connection setup time is rarely noticeable for interactive use, but is a real problem for automation/orchestration touching many hosts.
  • For high‑latency interactive work, commenters still see mosh as superior: local echo, prediction, and roaming support make latency subjectively vanish, though mosh has drawbacks (scrollback handling, bugs, UDP/firewall issues, apparent project stagnation).
  • WireGuard and other UDP VPNs already solve “SSH over hostile networks” for some; others see SSH3’s UDP tunnels as a lighter-weight, app-scoped alternative.

HTTP/3 & QUIC as substrate

  • Supporters like building on HTTP/3: can sit behind standard reverse proxies, blend into web traffic, reuse HTTP auth flows (OIDC/OAuth2/SAML), and bypass restrictive firewalls that only allow 80/443.
  • Critics dislike the “everything over HTTP” trend (DNS-over-HTTP, now SSH-over-HTTP), arguing it adds unnecessary complexity and large web stacks into a security‑critical path.
  • Some suggest SSH‑over‑QUIC without HTTP semantics would be cleaner; others reply that HTTP/3 adds real value via proxies and existing identity tooling.

Authentication, PKI & identity

  • Big enthusiasm from infra/enterprise angle: using corporate IdPs (Entra, Google, GitHub, etc.) for SSH‑like access simplifies RBAC and offboarding vs managing SSH keys/certs.
  • Others are uneasy about pushing shell access through web SSO and public CAs, preferring TOFU, Kerberos, or SSH certificates over centralized PKI/IdP dependence.
  • There’s recognition that TOFU scales poorly (e.g., GitHub host key rotation pain), but also fear of putting “all eggs in a few CA/IdP baskets.”

Security, complexity & project status

  • Repeated concern: OpenSSH is battle‑tested and conservative; replacing its transport with QUIC/HTTP‑3 and TLS expands attack surface and is harder to audit.
  • Some like that it’s written in Go (memory safety), but overall sentiment is “needs serious review before production.”
  • Multiple commenters note the GitHub repo and IETF drafts appear stale/expired; several assume the project is effectively dead.
  • Name “ssh3” is widely criticized as misleading/clout‑chasing; even the project notes a rename is planned, triggering extensive bikeshedding over alternatives.