SSH3: Faster Secure Shell Using HTTP/3 and QUIC

January 18, 2024

SSH3 is an experimental project that reimagines the Secure Shell (SSH) protocol by mapping remote-shell functionality onto modern HTTP mechanisms. Instead of relying on the traditional SSH transport and authentication design, SSH3 uses QUIC, TLS 1.3, and HTTP authentication mechanisms to establish secure remote sessions.

The project explores several potential improvements over conventional SSH, including faster connection establishment, authentication through identity providers, UDP port forwarding, and the ability to restrict server responses to requests sent to a specific URL path.

SSH3 is a research-oriented implementation, not a drop-in replacement for OpenSSH. Its features, security guarantees, and compatibility should be evaluated carefully before use.

What Is SSH3?

SSH3 is designed to provide secure remote-terminal access using HTTP/3-related technologies. It uses QUIC for transport, TLS 1.3 for cryptographic protection, and HTTP authorization mechanisms for user authentication.

The project explores how established SSH capabilities can work with modern web protocols while introducing features that are difficult to provide through the traditional SSHv2 architecture.

Key features described by the project include:

Faster session establishment: Reduces the number of network round trips required to establish a session under the project’s described conditions.
Multiple authentication methods: Supports password-based and public-key authentication, with experimental integration for OpenID Connect.
URL-path-based server access: Allows a server to respond only to requests that use a configured path.
UDP port forwarding: Extends forwarding capabilities beyond traditional TCP-based SSH forwarding.
Modern transport capabilities: Builds on QUIC, which supports features such as connection migration at the protocol level.
Familiar SSH features: Implements selected capabilities associated with OpenSSH, although compatibility is not complete.

For installation instructions and the latest project information, consult the official SSH3 GitHub repository.

Why SSH3 Focuses on Connection Speed

One of SSH3’s main goals is to reduce the time needed to establish a new remote session. Traditional SSH connections require multiple network round trips to negotiate the connection, establish cryptographic protection, and authenticate the user.

The project’s documentation describes SSHv2 session establishment as taking approximately five to seven network round-trip times in the scenarios discussed, compared with approximately three for SSH3. Actual results depend on network conditions, authentication configuration, protocol implementation, and other factors.

The performance improvement concerns session establishment, not data-transfer throughput. Once a session is running, SSH3 does not automatically make individual keystrokes or commands faster. Its primary potential advantage is reducing the initial wait before a user can begin working.

This distinction is particularly relevant for users who frequently establish short-lived remote sessions or connect to systems over networks with noticeable latency.

SSH3 Security and Authentication

Traditional SSH implementations define their own transport, key-exchange, and user-authentication mechanisms. SSH3 instead builds on protocols and mechanisms associated with TLS 1.3, QUIC, and HTTP.

Using established protocols is a useful design choice, but it does not automatically make a new protocol implementation secure. The way these components are combined, configured, and implemented must also withstand independent security review.

According to the project documentation, SSH3 supports several authentication approaches:

Password authentication: Allows users to authenticate using a password.
Public-key authentication: Supports key-based authentication, including RSA and Ed25519-related methods described by the project.
OpenID Connect: Provides an experimental approach to authentication through an external identity provider.
Certificate-based server authentication: Supports the use of X.509 certificates to authenticate the server.

OpenID Connect integration can potentially simplify access management by allowing an organization to use an existing identity provider. However, identity-provider configuration, account authorization, token handling, and access policies must all be reviewed before relying on this approach.

For a practical guide to securing conventional remote access, see our article on SSH key authentication.

SSH3 Is Still Experimental

SSH3 originated as a research project exploring a different way to provide SSH-like functionality. The project documentation warns that it has not received the extended independent cryptographic review needed to establish confidence for production use.

New protocol designs can introduce subtle issues even when they rely on well-established cryptographic components. Authentication flows, certificate validation, session management, authorization rules, and interactions between protocol layers all require careful analysis.

For these reasons, do not treat SSH3 as a production-ready replacement for OpenSSH solely because it uses TLS 1.3 and QUIC. Check the current repository documentation, known issues, release history, and security assessments before experimenting with it.

Recommended Testing Environment

Anyone evaluating SSH3 should use an isolated virtual machine, sandbox, or private test network. Avoid exposing an experimental SSH3 server directly to the public internet when a safer test environment is available.

During evaluation:

Use dedicated test accounts with minimal privileges.
Avoid using production credentials or sensitive private keys.
Restrict network access to trusted test clients.
Use valid certificates and review authentication configuration.
Keep the operating system and dependencies updated.
Monitor logs and stop the service when testing is complete.

Hiding an SSH3 Server Behind a Secret URL Path

SSH3 includes a feature that allows the server to respond to connection attempts only when requests target a configured URL path. This can reduce the server’s visibility to casual scans that do not know the path.

The project’s documentation illustrates this feature with a command similar to the following:

ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>

In this example, 192.0.2.0 is a documentation-reserved IP address used for illustrative purposes. Replace it with an appropriate address in your own isolated test environment, and use a randomly generated path if evaluating the feature.

When a path is configured, requests that do not match it can receive a 404 Not Found response. This may make the service less obvious to scanners that only request common URLs.

However, a secret URL path is not a substitute for authentication or access control. Paths can leak through logs, browser history, configuration files, or other channels. A person who discovers the path must still be required to authenticate through the configured security mechanisms.

Server concealment should therefore be treated as an additional layer of obscurity, not as a security boundary. Firewalls, strong authentication, least-privilege access, and ongoing monitoring remain important.

HTTP/3, QUIC, and Port Forwarding

SSH3 builds on QUIC, a transport protocol that operates over UDP and provides encrypted connections through TLS integration. HTTP/3 uses QUIC to carry HTTP traffic, making these technologies relevant to SSH3’s architecture.

The project also describes UDP port forwarding, which can help users reach UDP-based services through a remote host. Traditional SSH forwarding is primarily associated with TCP traffic, so UDP forwarding is a notable capability for use cases that require protocols such as DNS or other UDP-based applications.

As with any tunneling mechanism, forwarding should be restricted to explicitly authorized destinations. Unrestricted tunnels can bypass network segmentation or expose internal services unintentionally.

SSH3 Installation and Official Documentation

The project’s repository provides installation instructions for downloading release binaries, installing the Go packages, or compiling the client and server from source. The exact commands and prerequisites can change between releases, so consult the repository before installing.

Use these official resources to get started:

Before following older tutorials, verify that the commands match the version you intend to test. Also review the current project status and known limitations, particularly if you are evaluating SSH3 for a specific operational requirement.

Conclusion

SSH3 explores an alternative approach to secure remote access by combining SSH-like functionality with HTTP/3-related technologies. Its potential advantages include faster session establishment, integration with modern identity providers, UDP forwarding, and configurable URL-path-based server visibility.

These features make SSH3 an interesting project for researchers and administrators who want to understand how remote-terminal protocols could evolve. However, the project has historically described itself as experimental and has cautioned against production deployment without further review.

For now, evaluate SSH3 in a controlled environment, read the current documentation, and continue using well-maintained, production-ready remote-access solutions for critical systems unless your security team has independently validated an alternative.