Detailed Description

Outbound SSH client + reverse tunnel (PC_ENABLE_SSH_CLIENT).

The SSH server terminates inbound connections; this is the mirror - the device is the SSH client, dialing OUT to a relay and asking it to forward a port back. That is how a device behind NAT / a firewall stays reachable: it holds a tcpip-forward (RFC 4254 §7.1, the ssh -R seam) to a relay with a public address, and a connection to the relay's forwarded port is tunnelled back to a service on the device - the standards-track "secure machine bridge over untrusted networks".

── What it negotiates ───────────────────────────────────────────────────────────────────── kex : mlkem768x25519-sha256 (PQ/T hybrid, PC_ENABLE_PQC_KEX), curve25519-sha256, ecdh-sha2-nistp256, diffie-hellman-group14-sha256 hostkey : ssh-ed25519, ecdsa-sha2-nistp256, rsa-sha2-512, rsa-sha2-256 - verified against a pin cipher : chach.nosp@m.a20-.nosp@m.poly1.nosp@m.305@.nosp@m.opens.nosp@m.sh.c.nosp@m.om, aes25.nosp@m.6-gc.nosp@m.m@ope.nosp@m.nssh.nosp@m..com, aes256-ctr (+ hmac-sha2-256/512, ETM and E&M) auth : publickey, ssh-ed25519 (RFC 4252 §7) - the device signs with its own key

The client offers the full suite and negotiates whatever the relay supports (RFC 4253 §7.1 order), so it interoperates with any modern SSH server without being kneecapped to one algorithm. It reuses the transport primitives the server already ships (the curve/DH/ECDH KEX cores, ML-KEM-768, ed25519 / ECDSA / RSA verify, chacha-poly / AES-GCM / AES-CTR, the RFC 4253 §7.2 KDF, and the role-aware binary packet layer), so this file is the client-role state machine only, not a second crypto stack.

── Security ─────────────────────────────────────────────────────────────────────────────── The relay's host key is pinned by fingerprint: the caller supplies the SHA-256 of the expected host-key blob (K_S), and the handshake aborts if the relay presents anything else (no trust-on-first-use, no accepting an unknown key). Pinning the fingerprint rather than a raw key is host-key-type agnostic - it works whether the relay's key is ed25519, ECDSA or RSA. The device authenticates with an ssh-ed25519 key of its own, whose public half the relay carries in authorized_keys.

Author: Douglas Quigg (dstroy0)

Date: 2026

Definition in file ssh_client.h.