qsh is a modern secure remote shell, designed as a clean successor to SSHv2. The project is in the design & early implementation phase; this README is intentionally minimal and aimed at future users (not contributors).
SSHv2 has served for decades, but several structural issues are hard to fix in-place:
- Algorithm negotiation complexity creates downgrade / configuration risk.
- One set of session keys stretches across all channels with infrequent rekeys.
- TCP-only transport suffers head‑of‑line blocking and brittle network migration.
- Ad‑hoc binary framing and sprawling extensions raise parsing & audit complexity.
- Host key rotation is awkward; users either click through or get locked out.
- Privacy signals (capability ordering, message sizing) are inconsistent.
- Post‑quantum readiness requires bolt‑on patches instead of a coherent design.
qsh keeps the familiar user model (keys, TOFU, qsh user@host) while changing foundations:
- Fixed, modern hybrid cryptography (post‑quantum + classical) — no cipher negotiation.
- QUIC‑first transport with seamless TCP fallback for blocked UDP environments.
- Independent, frequently refreshed per‑channel (per direction) keys to narrow exposure windows.
- Deterministic, compact CBOR control messages for easier auditing and fuzzing.
- Explicit, signed host key rotation (“TOFU‑plus”) instead of silent trust shifts.
- Built‑in privacy measures (adaptive padding, canonical capability ordering).
- Versioned evolution (new ALPN for future modes) instead of in‑band option sprawl.
| Aspect | SSHv2 (today) | qsh v1 |
|---|---|---|
| Crypto | RSA / Ed25519 / Curve25519 (classical only) | Hybrid post-quantum by default (X25519 + ML-KEM-768, Ed25519 + ML-DSA-44) |
| Key lifecycle | One session key for all channels, rekey ~1GB/hour | Per-channel, per-direction keys; automatic rekey ≤1 MiB or 30 s (whichever first) |
| Handshake | Multi-roundtrip KEXINIT, cipher negotiation, downgrade risks |
Single 1-RTT handshake, fixed suite (no negotiation) |
| Transport | TCP only → head-of-line blocking, fragile across NAT/Wi-Fi hops | QUIC/UDP preferred (multiplexing, migration, congestion control), TCP fallback |
| Wire format | Custom ad-hoc binary blobs, extension hell | Deterministic CBOR maps, simple, fuzzable, extensible |
| Host trust | TOFU known_hosts, awkward rotation |
TOFU-plus (pinned hybrid keys, explicit signed rotations) |
| Audit posture | Optional session logging, weak tamper evidence | Planned option: per-channel MAC chaining (tamper-evident logs) |
| Legacy behavior | SSH to non-SSH service = confusing hangs | Preface “QSH1” → fast fail (“protocol mismatch”), predictable |
Bottom line:
- For the user: looks and feels like SSH.
- For the implementer/admin: a simpler spec, smaller attack surface, future-proof crypto, and better transport resilience.
Planning & specification work are active. The reference implementation is not yet ready for production use. Interfaces and on‑disk formats may still change.
If you need a stable tool today: keep using SSH. Monitor this project if you care about a QUIC‑native, post‑quantum‑ready successor with a smaller, stricter spec.
- You want lower latency interactive shells over variable networks.
- You need forward secrecy windows measured in seconds/megabytes, not hours/gigabytes.
- You operate in environments planning for post‑quantum migration.
- You prefer fixed suites (no negotiation spreadsheets) and simpler compliance narratives.
Deep technical definitions (message formats, key schedule, limits, staging) live in spec.md and roadmap.md. This README intentionally defers those so it stays approachable.
MIT — see LICENSE.
Created by @haukened (David Haukeness).
Project home: https://github.com/haukened/quicshell