Secure remote access has a new—still very experimental—contender: SSH3. It is a ground-up revisit of the SSH protocol that maps SSH semantics onto HTTP/3, uses QUIC (over UDP) and TLS 1.3 to secure the transport, and leverages HTTP authorization mechanisms for user authentication. The project, born from independent academic research and proposed to the IETF as an Internet-Draft (initially draft-michel-remote-terminal-http3-00, now retitled “Remote Terminals over HTTP/3”), has released its first experimental client and server, written in Go and distributed under the Apache 2.0 license.
The pitch in one line: faster session setup, modern auth methods like OAuth 2.0 and OpenID Connect alongside classic password and public key, native UDP port forwarding in addition to TCP, and all the benefits of modern QUIC, including connection migration (coming) and multipath. And because it blends into HTTP/3/TLS traffic, SSH activity is harder to single out on the wire.
What SSH3 is (and what it isn’t)
The authors are explicit: SSH3 is not a bolt-on patch to SSHv2. It is a rethinking in which canonical SSH features (channels, port forwarding, auth) are implemented on top of HTTP—in practice via HTTP/3 Extended CONNECT—while TLS 1.3 over QUIC provides channel security. That choice aims at two goals:
- Stand on proven, widely audited protocols that already secure e-commerce, banking, and critical web apps (TLS 1.3/QUIC/HTTP).
- Integrate with the web ecosystem (HTTP authorization, X.509 certificates, port 443 deployments) so SSH traffic can blend into the rest of the network.
Headline improvements, compared to SSHv2/OpenSSH:
- Noticeably faster session establishment: SSH3 trims the handshake from 5–7 round trips down to 3 (throughput is unchanged, but the time-to-prompt improves).
- HTTP-native auth methods: OAuth 2.0 and OpenID Connect (OIDC) join classic password and public key (RSA, EdDSA/ed25519).
- Resilience to port scanning: servers can be “hidden” behind a secret URL path, replying 404 to all other requests so scanners see a dull web server.
- UDP port forwarding: beyond classic TCP forwarding, SSH3 tunnels UDP (e.g., QUIC, DNS, RTP) using QUIC datagrams.
- X.509 for server identity: use your HTTPS certificates (e.g., Let’s Encrypt) to authenticate the host, avoiding the SSHv2 “first-contact host key” dilemma and mitigating MITM on first connection.
- QUIC goodies: connection migration (change networks mid-session) and multipath (multiple active routes), among others.
SSH3 also keeps a long list of OpenSSH-style conveniences: parses ~/.ssh/authorized_keys on the server; supports known_hosts when not using X.509; automatic ssh-agent use for public key auth; agent forwarding; direct TCP port forwarding (reverse coming later); proxy jump across SSH3 servers; and basic parsing of ~/.ssh/config (handling Hostname, User, Port, IdentityFile, plus new SSH3-specific options like URLPath and UDPProxyJump).
A crucial caveat: SSH3 is experimental. While it relies on TLS 1.3 and QUIC, the protocol mechanics and implementation require extensive community review and maturation before anyone should consider production use.
Faster to first prompt: 3 round trips instead of 5–7
One of the most tangible wins is time-to-interactive. With ~100 ms ping to a server, SSHv2 often consumes 5–7 round trips to get you a prompt; SSH3 claims 3. Keystroke latency during a live session does not change, but that initial friction does, which is especially noticeable across higher-latency links (remote clouds, branch offices, inter-region work).
Authentication: from public keys to “sign in with Google/Microsoft/GitHub”
SSH3 doesn’t discard the familiar: passwords (disabled by default) and public keys (RSA, ed25519) are supported. But it also brings HTTP-native authentication: OAuth 2.0/OpenID Connect. Practically, admins can delegate login to an IdP—the company SSO, Google Identity, Microsoft Entra, GitHub, etc.—and avoid shuffling public keys across hosts.
- On the client,
~/.ssh3/oidc_config.jsondefines issuer_url, client_id, client_secret (PKCE optional). - On the server,
~/.ssh3/authorized_identitiesaccepts oidc entries alongside traditional authorized_keys.
This keyless path is attractive for enterprise SSO, though the authors label it experimental and note the config may change.
“Invisible” servers and port-scan mitigation
A pragmatic addition: hide your SSH3 endpoint behind a secret path. The server supports:
ssh3-server -bind 0.0.0.0:443 -url-path /<long-random-secret>
Code language: HTML, XML (xml)It will only respond on that URL and reply 404 elsewhere. To an Internet scanner, it looks like a plain web server. Important: this is not an auth mechanism; it reduces discovery, but does not replace proper authentication.
X.509 server identity (and goodbye to “accept this host key?”)
Because SSH3 rides TLS 1.3, the server needs a certificate and private key. Options:
- Let’s Encrypt (recommended): auto-issue and renew public certs via
-generate-public-cert. - Existing cert: pass
-cert/-keypaths. - Self-signed:
-generate-selfsigned-cert(equivalent to SSHv2 host keys in security and first-contact MITM risk).
Using publicly issued certs sidesteps the SSHv2 first-use trust decision and provides a smoother and safer first connection.
UDP inside: forwarding for QUIC, DNS, RTP…
SSH3 adds UDP forwarding (in addition to TCP). If you manage QUIC, DNS, RTP or any UDP-only service reachable only from an intermediate host, this is a material improvement: the client tunnels datagrams over QUIC using -forward-udp.
ProxyJump also works with two SSH3 servers: B forwards UDP from A to C so the A↔C connection is end-to-end; B cannot decrypt or tamper with the SSH3 traffic.
Install and kick the tires: binaries, go install, or build from source
One more warning: do not run SSH3 on production Internet-facing hosts. Lab it on private networks or, if you expose it, pair with the secret path and treat it as unsafe until further vetting.
Install routes:
- Download the latest release binaries.
- Use go install:
go install github.com/francoismichel/ssh3/cmd/...@latest
- Build from source (modern Go; server needs CGO/gcc):
git clone https://github.com/francoismichel/ssh3
cd ssh3
go build -o ssh3 cmd/ssh3/main.go
CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go
Code language: PHP (php)With root privileges you can copy to /usr/bin/. Otherwise, append the repo path to your PATH.
Start a public server on 443 with Let’s Encrypt and path /ssh3:
ssh3-server -generate-public-cert my-domain.example.org -url-path /ssh3
Code language: PHP (php)Use an existing cert:
ssh3-server -cert /path/to/cert.pem -key /path/to/priv.key -url-path /ssh3
As with OpenSSH, the server must run with elevated privileges to allow logins as other users.
Files that matter:
- Server:
~/.ssh/authorized_keysand~/.ssh3/authorized_identities. - Client:
~/.ssh/config(parsed subset) and~/.ssh3/oidc_config.json(OIDC).
Client, quick examples:
- Private key auth:
ssh3 -privkey ~/.ssh/id_rsa [email protected]/my-secret-path
Code language: JavaScript (javascript)- Password (if explicitly enabled on server):
ssh3 -use-password user@my-server.example.org/my-secret-path
Code language: CSS (css)- Agent forwarding and proxy jump:
ssh3 -forward-agent -proxy-jump bastion@bastion.example.org [email protected]/my-path
Code language: CSS (css)- Forward UDP/TCP:
ssh3 -forward-udp 5353/10.0.0.53@53 -forward-tcp 8443/10.0.0.10@443 user@host/ssh3
Project status and disclaimers
SSH3 is not an “official” effort by the OpenSSH maintainers or classic SSH implementers. It is a research prototype published to invite community scrutiny. The maintainers are clear:
- SSH3 needs long-horizon cryptographic and protocol review before any solid security claims.
- They do not recommend public production deployment; “secret URL” reduces scanning but does not replace strong auth.
- The “SSH3” name may change; the draft spec was renamed Remote Terminals over HTTP/3 because the changes are too extensive (and diverge in philosophy) for popular SSH stacks to adopt directly.
What it brings today (and what it doesn’t)
Brings:
- Lower session setup latency (3 RTTs vs. 5–7).
- Modern auth (OAuth/OIDC) and enterprise SSO without copying keys.
- UDP forwarding out of the box.
- X.509 server identity (Let’s Encrypt) to avoid first-contact MITM and host-key prompts.
- Camouflage in HTTP/3/TLS traffic and an optional secret path to reduce scanner noise.
- A path to connection migration/multipath via QUIC.
Doesn’t bring (yet):
- Security assurances comparable to mature SSH implementations.
- Full parity with every OpenSSH option and edge case (though it covers the popular ones).
- A green light for critical environments—its place is the lab, not the DMZ.
Bottom line
SSH3 is, first and foremost, a bold proposal: peel back the bespoke layers of a venerable protocol and re-use TLS 1.3, QUIC and HTTP to slot secure shells into the modern Internet—one that is more “web-shaped”, with SSO everywhere and UDP-first transports spreading fast. You get a snappier handshake, richer authentication, and features like UDP forwarding and mobility that were hard or impossible in SSHv2. In exchange, you must apply caution: it’s early, seeks peer review, and does not try to pass for production-ready.
For admins and security teams the advice is twofold: experiment (in sandboxed environments) to understand the upsides, and wait for broader review and hardening before you let it anywhere near critical systems. The community now has the floor.
FAQs
How do I install and test SSH3 in a safe lab environment?
Use go install:
go install github.com/francoismichel/ssh3/cmd/...@latest
or build from source (modern Go; server needs CGO/gcc). Start the server with a certificate (Let’s Encrypt via -generate-public-cert or self-signed) and a secret URL path via -url-path. Connect from the client using a private key or via OIDC (configure ~/.ssh3/oidc_config.json). Reminder: do not deploy in production yet.
How does OpenID Connect login (Google/Microsoft/GitHub) work in SSH3?
SSH3 can delegate authentication to an OIDC IdP. On the client, define issuer_url, client_id, client_secret in ~/.ssh3/oidc_config.json and run ssh3 -use-oidc https://accounts.google.com user@host/secret-path. On the server, add an oidc line to ~/.ssh3/authorized_identities. It’s experimental and may require registering an app in your IdP to obtain credentials.
How do I hide an SSH3 server to reduce port-scan noise?
Run it on 443/QUIC behind a secret URL path (-url-path /long-random-string). The server will only respond on that URL and return 404 otherwise. Note: this is merely discovery reduction, not an access control. Keep strong key/SSO auth and standard policies.
What are the practical benefits of SSH3’s “UDP port forwarding” and how do I use it?
It lets you tunnel UDP (e.g., QUIC, DNS, RTP) for services reachable only from the SSH3 host. Use -forward-udp on the client; datagrams are encapsulated in QUIC. It’s useful for remote admin of UDP services or testing without opening additional ports.
Why prefer X.509 (Let’s Encrypt) for server identity over SSHv2 host keys?
With X.509, first contact avoids “accept this host key?” and the associated MITM risk. Because SSH3 already uses TLS 1.3, it’s natural to leverage the public PKI. Let’s Encrypt (-generate-public-cert) automates issuance/renewal and improves the first-use experience.
via: SSH3 GitHub
