SSH over Velocity

This overview captures how Velocity transports SSH traffic while preserving workflows operators rely on today. The goal is a reversible rollout: keep classical SSH online while Velocity assumes the heavy lifting.

Objectives

• Maintain familiar SSH semantics—authentication methods, agent forwarding, subsystems—while replacing TCP with Velocity streams.
• Issue hybrid host certificates (classical + Dilithium) that plug into existing OpenSSH trust stores.
• Provide a rollback-friendly posture so Velocity and SSH can run side by side until teams are confident.

Components

1. vsh-proxy (client)
   • Invoked through OpenSSH ProxyCommand.
   • Handles the Velocity handshake, negotiates the highest profile, and builds a dedicated stream for SSH.
   • Forwards bytes transparently between the local client and the remote Velocity server.
2. vshd (server)
   • Terminates Velocity sessions, validates hybrid certificates, and hands authenticated streams to the local sshd process.
   • Emits structured logs covering negotiated profile, ALPN, client identity, and replay decisions for audit trails.
3. Certificate bridge
   • Velocity CA issues hybrid certificates with classical and Dilithium signatures.
   • A conversion tool derives SSH host certificates using the same key material plus a Dilithium signature extension.
   • Clients verify both signatures; downgrade attempts trigger warnings or immediate rejection per policy.

Migration phases

1. Parallel deployment
   • Run Velocity on UDP/443 (or a staging port) alongside SSH on TCP/22.
   • Encourage early adopters to use vsh-proxy via targeted host aliases in ~/.ssh/config.
2. Progressive enforcement
   • Use Match blocks in sshd_config to require Velocity transport for specific users or groups.
   • Instrument metrics to monitor handshake outcomes, downgrade rates, and replay protection events.
3. Full cutover
   • Disable direct TCP/22 access once Velocity transport proves stable.
   • Maintain documented rollback paths to restore SSH quickly if needed.

Replay protection and 0-RTT

Velocity session tickets ship with replay windows and optional client address binding. For SSH, disable 0-RTT initially or restrict it to idempotent operations until replay tracking reaches production maturity.

Operational checklist

• Issue hybrid certificates from the Velocity CA and install them on pilot hosts.
• Deploy vshd alongside sshd, integrating logs with existing SIEM tooling.
• Update client configurations to invoke vsh-proxy for target hosts.
• Document rollback steps and keep a playbook for reverting to TCP.

Expect to expand this document with concrete configuration snippets, performance considerations, and troubleshooting notes as the implementation solidifies.