Making post-quantum visible: per-session indicators and warnings

2.1What a session's protection depends on

After the key exchange, everything in a session, the login included, is encrypted with keys derived from its shared secret [1]. The key exchange method decides whether a recording can be decrypted later: a hybrid such as mlkem768x25519-sha256 [4] or sntrup761x25519-sha512 [5] is designed to stay secure while either of its halves does [2]. The host key decides who the server is, and only at connection time; the cipher and MAC protect the traffic itself, and a 256-bit cipher is not the weak point [2]. A useful report therefore names the key exchange first, then the host key, then the cipher, MAC and compression.

2.2Where the facts come from

The client learns the server's choice inside its SSH library. GHOSTSHELL's library, a fork of russh, keeps a record of what each completed key exchange negotiated: the method, the host key algorithm (a certificate type when the server presented a certificate), the cipher, the MAC in each direction, shown as <implicit> next to an AEAD cipher as OpenSSH prints it, and the compression in each direction. For the first exchange, the library stores the record only after the host key check has accepted the server, and before connect() returns; each rekey replaces it. The binding offers it as negotiatedAlgorithms(), null before the first exchange, and as negotiatedAlgorithms$, which emits after each one. The library also refuses a host key of any type but the negotiated one, so the host key named is the type that signed the handshake; that refusal was reviewed in the code but not exercised.

3.1Three states, decided conservatively

Each connection gets one of three states (Table 1). With a report, the state is the report's. Without one, the offer alone decides, and only where it leaves no doubt: if every method offered was post-quantum, whatever ran was post-quantum; if none was, the exchange was classical; otherwise the state is unknown. A connection is never shown as post-quantum because a post-quantum method came first in its offer. A method counts as post-quantum if the policy names it or if its name starts with a post-quantum family's (mlkem, sntrup, ntruprime and others), so a method a later library adds is not mistaken for classical.

3.2The words

The summary names the state, the method and the host key in one line. A classical summary is followed by a warning in two parts (Figure 1). The first is the risk, the same every time: traffic recorded from this connection could be decrypted later by a quantum computer. The second is the reason, which decides who can fix it. Either the server supports none of the post-quantum methods GHOSTSHELL offered, which it lists, with the OpenSSH versions that offer one by default and a note that crypto policies, other servers and network equipment vary; or the profile's own policy offered none, with a pointer to the profile's Ciphers tab. The first reason sends the user to the server's administrator, the second to their own settings. An unknown state gets one sentence saying what would have made the exchange post-quantum. Algorithms that only Legacy or a profile's own ticks allow, such as SHA-1 key exchange, CBC, ssh-rsa or HMAC-SHA1 beside a non-AEAD cipher, get a line of their own.

PQ  Post-quantum key exchange: mlkem768x25519-sha256 · host key ssh-mldsa44-ed25519

!   Classical key exchange: curve25519-sha256 · host key ssh-ed25519
!   Not post-quantum: traffic recorded from this connection could be decrypted
    later by a quantum computer. The server supports none of the post-quantum
    methods GHOSTSHELL offered (mlkem768x25519-sha256, mlkem1024nistp384-sha384,
    mlkem768nistp256-sha256, sntrup761x25519-sha512,
    sntrup761x25519-sha512@openssh.com). OpenSSH servers offer one by default
    from version 8.9 (sntrup761) and 9.9 (ML-KEM), unless the system's crypto
    policy removes it; other SSH servers and network equipment vary.

?   Key exchange not reported by this SSH library: post-quantum methods were
    offered first, but a classical one may have been used · host key ssh-ed25519
?   The key exchange is post-quantum only if the server supports one of
    mlkem768x25519-sha256.

3.3Where it shows, and when

Figure 2 places each surface in the life of a connection, and Table 2 lists them. The terminal line comes at the one moment the user is sure to be looking: after the key exchange and before authentication, so no password goes into a classical session without a warning on the screen. It stays in the scrollback. The badge keeps the answer in view for the life of the tab, on the terminal toolbar, which is pinned by default. The dialog holds what no line can: every hop, every algorithm and where the policy came from. Settings → Security puts the stored policy and the open tabs on separate rows, so the page never implies that a setting is in force where a server overruled it; Settings → SSH answers a different question, what this build can do.

3.4Jump hosts: the weakest hop

A tab that goes through jump hosts has one connection per hop, and each negotiates on its own. The tab's state is its weakest hop's: classical if any hop is classical, else unknown if any hop did not report, else post-quantum. The badge names the case rather than averaging it away (Table 3). A post-quantum target behind a classical bastion reads Classical jump host, because the outer connection carries the bastion login and the target's address. A post-quantum chain through a proxy command reads Post-quantum inside proxy, in grey, because GHOSTSHELL cannot see the proxy's own connection. The tooltip lists each hop's summary, and the terminal names the profile whose policy a jump host was raised to.

3.5Shared connections and rekeys

Two tabs can share one connection. The second tab never saw the first one's lines, so it prints the shared connection's summary and warning itself, after "Sharing the open connection to". A rekey is a new key exchange inside the session, and the server could choose differently. After each one the library emits an event, and the app reads the record again and prints the summary only if the record changed, so a long session's routine rekeys add nothing to the terminal while a change of method would be announced. The badge and the dialog always show the latest record.

5.1Method

The SSH library the app installed (russh 0.2.0-ghostshell.1) connected over 127.0.0.1 to the project's test server, which runs the same russh fork and answers an exec request with its own record of what it negotiated. The host keys (ML-DSA-44 + Ed25519, and Ed25519) were throwaway keys made in a temporary folder, and the password a random throwaway. What the library reported went through the app's own connectionSecurity.ts, as the app passes it. Four checks ran on 12 November 2026, on Windows 11 x64 with Node 24.22.2:

1. Every key exchange name the library implements, 5 post-quantum and 14 classical (sntrup761 and curve25519 each have two), one connection each offering only that name: was the record there when connect() returned, did it match the server's record in method, host key, cipher, MACs and compression, was the state right, and was the record the same after password authentication?
2. Three server-initiated rekeys for each of the five post-quantum names: did each event arrive, and how many lines would the app's rule print?
3. A two-hop chain, the inner session reaching a second server through a forwarded channel of the first, with a classical and then a post-quantum outer hop.
4. The 0.1 library (npm russh 0.1.38), which cannot report, under three policies against the same server, whose record says what really ran.

The badge for each chain follows the rule of sshTab.component.ts, applied to the measured states; the component itself was not run.

5.2Results

The first 0.1 row is the case the conservative rule exists for: under the default policy the server did run a post-quantum method, and GHOSTSHELL still said it could not tell, because nothing it had could tell it. The rekey times include the exec request that started each rekey, so they bound how soon a changed record would reach the screen. One cost shows in Figure 1: the classical warning is 487 characters long, with five method names, and with its summary it fills 8 rows of an 80-column terminal. It appears only on classical connections, but it is long.