Secure Shell (SSH): Public Key Authentication over Hypertext Transfer Protocol (HTTP)

Secure Shell (SSH) protocol requires all implementations to support public key authentication method (“publickey”) for authentication purposes, so web applications which provide a SSH client over the web browser need to support “publickey”. However, restrictions in Hypertext Transfer Protocol (HTTP), such as same origin policy, and limited access to local resources, make it difficult to perform such authentications. In this document, a system to perform “publickey” authentication over HTTP is provided. It is ensured that no compromise is made that would pose a security risk to SSH protocol.

💡 Research Summary

The paper addresses the problem of enabling SSH public‑key authentication for web‑based SSH clients, which must operate over HTTP despite the protocol’s inherent restrictions such as the Same‑Origin Policy and limited access to local resources. To solve this, the authors propose a new component called ssh‑web agent, a local daemon that accepts authentication requests over HTTP, validates them, and performs the cryptographic operations required by the SSH “publickey” method.

The design begins by recognizing that traditional ssh‑agent communicates via UNIX domain sockets, which browsers cannot reach. Therefore, the ssh‑web agent must expose an HTTP interface limited to localhost. Because browsers will block cross‑origin requests to localhost unless CORS is explicitly allowed, the agent requires the server to enable CORS and to serve over TLS, avoiding mixed‑content warnings.

A trusted‑servers file is introduced to store the public keys of servers that are allowed to interact with the agent together with the expected HTTP Referer header values. When a request arrives, the agent checks the Referer header and the server’s public key against this file; only if both match does it proceed to signature verification. This dual check mitigates the risk of a malicious web page forging requests.

Since HTTP is stateless, the agent creates a logical session for each authentication flow. The session is identified by a unique identifier that is encrypted using a secret derived from a Diffie‑Hellman (DH) key exchange with the trusted server. The DH exchange is initiated by the server sending a KEX_DH_REQUEST message that contains the DH parameters (p, g) and a signature made with the server’s private key. The agent verifies the signature, computes the shared secret, and replies with a KEX_DH_RESPONSE that includes the encrypted session identifier. The shared secret S, together with SHA‑256 hashes, yields a shared secret hash, a symmetric encryption key, and an initialization vector.

All messages are transmitted as Base64‑encoded binary blobs inside HTTP POST requests with content‑type application/x‑www‑form‑urlencoded. The response body is plain text. The protocol defines several message types, mirroring SSH’s own binary format (as specified in RFC 4251/4253):

• KEX_DH_REQUEST / KEX_DH_RESPONSE – for establishing the DH‑based session.
• PRIVATE – a wrapper for encrypted payloads.
• NEW – the first encrypted message after session creation, containing only a random nonce and the session identifier.
• AUTH_REQUEST / AUTH_RESPONSE – carry the actual SSH authentication data.

The payload of an AUTH_REQUEST includes the SSH session identifier (as defined in RFC 4253) and is encrypted with the session key. Upon receiving it, the ssh‑web agent invokes the local ssh‑agent (or its own key store) to sign the SSH authentication message with the user’s private key(s). The resulting signatures, together with the corresponding public keys and optional encrypted options, are placed in an AUTH_RESPONSE message, encrypted with the same session key, and sent back to the trusted server. The server then verifies the signatures against the public key it has on record and completes the SSH “publickey” authentication.

The paper also discusses local user binding: the agent binds to a specific localhost port and runs under the same UID as the user, preventing other users on the same machine from hijacking the service. On Linux, the owner of a TCP connection can be determined via /proc inspection, and the paper provides sample code for this verification.

Performance considerations are examined. The dominant latency factor is network round‑trip time to the trusted server; cryptographic operations (DH, AES‑256‑CBC, RSA signatures) are negligible on modern CPUs. A full authentication flow requires four HTTP requests (two to the trusted server for session establishment, two to the agent for DH exchange and for the actual authentication) plus TLS handshakes for the first request to the server. The authors recommend keeping the server‑to‑client latency below 80 ms to achieve acceptable user experience.

In the conclusion, the authors argue that providing a secure, browser‑based mechanism for SSH public‑key authentication eliminates the need for users to expose their private keys to third‑party web applications, thereby enabling richer web‑based server management tools and broader adoption of remote services.

Overall, the paper delivers a concrete protocol specification, a threat model, and an implementation roadmap for bridging SSH public‑key authentication with HTTP. While the design is thorough, it relies heavily on the integrity of the trusted‑servers file, the correctness of Referer validation, and proper TLS deployment. Real‑world deployments would need additional safeguards such as OS‑level file protection, periodic integrity checks, and possibly a more robust attestation mechanism to replace the relatively weak Referer check. Nonetheless, the proposal represents a significant step toward secure, web‑native SSH client functionality.