Client-side extension response parsing rejects non-query extension responses from spec-compliant agents

[sfriedenberg-etsy]

Summary

ssh-agent-lib's client cannot parse extension responses from agents that follow the IETF spec / OpenSSH wire format. This is the inverse of #1 (which covers the server encoding direction). Together, these two issues mean ssh-agent-lib agents cannot interoperate with spec-compliant agents in either direction.

Context

#1 identified that ssh-agent-lib's Extension encoding adds two extra u32 length frames when producing responses. This issue covers the opposite direction: ssh-agent-lib's client-side Extension decoding expects those same extra frames, so it rejects valid responses from agents that follow the spec (OpenSSH, pivy-agent, etc.).

How this manifests

In ssh-agent-mux, the catch-all extension handler forwards requests to upstream agents using ssh-agent-lib's client:

// ssh-agent-mux/src/lib.rs — catch-all extension handler
_ => {
    for sock_path in &self.socket_paths {
        let mut client = self.connect_upstream_agent(sock_path).await?;
        let result = client.extension(request.clone()).await;
        match result {
            Ok(v) => return Ok(v),           // first success wins
            Err(AgentError::Failure) => continue,  // try next upstream
            Err(e) => { log::error!(...); continue; }
        }
    }
    Err(AgentError::Failure)  // all upstreams failed
}

When pivy-agent responds to ecdh-rebox@joyent.com (or ecdh@joyent.com), ssh-agent-lib's client decoder tries to parse the response. The response is valid per the spec, but ssh-agent-lib expects its own non-standard framing, so parsing fails. The mux sees Err(AgentError::Failure) from every upstream and returns SSH_AGENT_FAILURE (code 5) to the calling client.

Observed error

.pivy-box-unwrapped: warning: failed to unlock ebox with agent
  Caused by SSHAgentError: SSH agent returned message code 5 to rebox request
    in piv_box_open_agent() at src/piv.c:7085

pivy-box falls back to a direct PIN prompt (second attempt via PCSC), so decrypt works end-to-end but with degraded UX.

Wire format comparison

Spec / OpenSSH / pivy-agent response to a data-bearing extension

Per draft-ietf-sshm-ssh-agent §3.8:

byte      SSH_AGENT_EXTENSION_RESPONSE (29)
string    extension type                        ← echo of the request name
byte[]    extension response-specific contents   ← raw bytes to end of message

Or for no-data responses (pivy currently uses this for ecdh extensions):

byte      SSH_AGENT_SUCCESS (6)

What ssh-agent-lib's client decoder expects

ssh-agent-lib decodes extension responses through Extension::decode, which expects:

byte      SSH_AGENT_EXTENSION_RESPONSE (29)
string    extension name                         ← u32 len + name bytes
string    details blob                           ← u32 len + payload bytes  ← EXTRA

The details field is decoded as an SSH string (u32 length-prefixed blob), but the spec says byte[] — raw remaining bytes with no length prefix. This means:

1. If the upstream responds with type 29 (spec-compliant data-bearing response), ssh-agent-lib reads the extension name echo correctly, then tries to read a u32 length prefix for the details blob. It interprets the first 4 bytes of the actual payload as a length, getting garbage.

2. If the upstream responds with type 6 (SSH_AGENT_SUCCESS, used by pivy for ecdh extensions), ssh-agent-lib doesn't recognize it as an extension response at all — it maps to Response::Success, which has no payload, so the ecdh response data is lost.

Relationship to other issues

• amarbel-llc/ssh-agent-lib#1 — server-side encoding adds extra framing (inverse of this issue)
• amarbel-llc/ssh-agent-mux#3 — query aggregation (working, but blocked by this + QueryResponse wire format does not match IETF spec or OpenSSH #1)
• amarbel-llc/pivy#15 — pivy protocol compliance fixes (complete, pivy now matches spec/OpenSSH)
• Testing done in amarbel-llc/piggy

Root cause

Same structural issue as #1 but in the decode direction. Extension's Decode impl reads details as a length-prefixed string, but the spec's byte[] extension response-specific contents means "all remaining bytes after the extension name" — no length prefix.

Additionally, the client needs to handle both type 29 (data-bearing) and type 6 (no-data) extension responses. Some agents (including pivy, currently) use type 6 for extensions that do return data — this is non-spec but exists in the wild and needs to be handled for interoperability.

Suggested fix

1. Extension::decode should read details as raw remaining bytes (reader.read_to_end()), not as a length-prefixed string
2. The client-side response handling should recognize that a type-6 response to an extension request may carry no data but still indicates success — the client should return Ok(None) rather than discarding the response
3. Optionally, handle type-6 responses that DO carry a trailing payload (pivy's legacy format) by reading remaining bytes as the extension response body

Verification plan

After fixing, ssh-agent-mux should be able to:

1. Forward ecdh@joyent.com to pivy-agent and relay the response back to pivy-box
2. Forward ecdh-rebox@joyent.com to pivy-agent and relay the response back to pivy-box
3. piggy show through the mux should decrypt on the first attempt without falling back to a PIN prompt

[sfriedenberg-etsy]

Analysis: believed addressed by #1 fix (ad23a6d)

After reviewing the current code, the three problems described in this issue appear to already be handled:

1. Extension::decode — already reads raw remaining bytes

// src/proto/message/extension.rs:97-104
fn decode(reader: &mut impl Reader) -> Result<Self> {
    let name = String::decode(reader)?;
    let mut details = vec![0; reader.remaining_len()];
    reader.read(&mut details)?;
    // ...
}

details is read as all remaining bytes after the name string — no length prefix. This was correct before #1.

2. Client handles both type 29 and type 6

// src/client.rs:185-191
async fn extension(&mut self, extension: Extension) -> Result<Option<Extension>, AgentError> {
    match self.handle(Request::Extension(extension)).await? {
        Response::Success => Ok(None),                           // type 6
        Response::ExtensionResponse(response) => Ok(Some(response)), // type 29
        _ => Err(ProtoError::UnexpectedResponse.into()),
    }
}

Type 6 returns Ok(None), type 29 returns Ok(Some(response)). Both are handled.

3. Extension::encode — already writes raw bytes (no length prefix)

// src/proto/message/unparsed.rs:43-49
fn encode(&self, writer: &mut impl Writer) -> ssh_encoding::Result<()> {
    // NOTE: Unparsed fields do not embed a length u32
    writer.write(&self.0[..])?;
    Ok(())
}

Unparsed::encode explicitly writes raw bytes without a length prefix.

Root cause was QueryResponse, not Extension

The actual wire format bug that caused pivy-box failures was in QueryResponse encoding — Vec<String>::encode from ssh-encoding added an outer u32 byte-count that the spec doesn't use. This was fixed in ad23a6d (#1).

The issue description attributed the extra framing to Extension itself, but Extension's encode/decode was already correct. The two extra u32 fields in the wire output came from QueryResponse's delegation to Vec<String>::encode (outer byte-count) — not from Extension.details.

Remaining work is operational

ssh-agent-mux's Cargo.lock already resolves to ad23a6d. To verify end-to-end:

1. Update ssh-agent-mux's Nix outputHash for ssh-agent-lib-0.5.2 (stale — predates QueryResponse wire format does not match IETF spec or OpenSSH #1 fix)
2. Rebuild and redeploy ssh-agent-mux
3. Test piggy show through the mux — should decrypt on first attempt without PIN fallback

Leaving open pending end-to-end verification.

[sfriedenberg-etsy]

Retest: issue confirmed with #1 fix already in binary

The previous comment's theory that this is an operational issue (stale outputHash) is incorrect. The fix from #1 (ad23a6d) is already in the running binary:

$ ps aux | grep ssh-agent-mux
/nix/store/1a1inh625fn50z84ql9k8kj20f3xmw7h-ssh-agent-mux-0.2.0/bin/ssh-agent-mux ...

$ nix build /Users/sfriedenberg/eng/repos/ssh-agent-mux --print-out-paths
/nix/store/1a1inh625fn50z84ql9k8kj20f3xmw7h-ssh-agent-mux-0.2.0

Same store path — the outputHash is correct and matches ad23a6d. The build succeeds without hash mismatch.

Decrypt still fails on first attempt:

Using key 'PIV_slot_9D C291D27B /CN=sfriedenberg' in ssh-agent...
.pivy-box-unwrapped: warning: failed to unlock ebox with agent
  Caused by SSHAgentError: SSH agent returned message code 5 to rebox request
    in piv_box_open_agent() at src/piv.c:7085

pivy-box falls back to PIN prompt on the second attempt, which succeeds. The query wire format fix from #1 is working (no more sshbuf_get_cstring errors), but the actual ecdh-rebox@joyent.com extension forwarding still fails.

What's happening

1. pivy-box sends ecdh-rebox@joyent.com through SSH_AUTH_SOCK (pointing at ssh-agent-mux)
2. ssh-agent-mux's catch-all extension handler forwards it to pivy-agent via client.extension(request)
3. pivy-agent processes the ecdh-rebox and responds
4. ssh-agent-lib's client parses the response
5. Something goes wrong — the mux returns SSH_AGENT_FAILURE (code 5) to pivy-box

The previous comment is correct that Extension::encode/decode and the client's type 6/29 handling are fine in isolation. But something in the round-trip through client.extension() → pivy-agent → response parsing is failing for the ecdh extension specifically.

This needs deeper investigation — likely a wire capture or debug logging at the mux to see what pivy-agent actually sends back and where parsing diverges.

[sfriedenberg-etsy]

Root cause identified: pivy-agent omits extension name echo for ecdh responses

What's happening

pivy-agent's ecdh-rebox@joyent.com (and ecdh@joyent.com) response sends:

byte    SSH2_AGENT_EXT_RESPONSE (29)
string  <reboxed PIV box binary>        ← data only, NO extension name echo

But the spec (draft-ietf-sshm-ssh-agent §3.8) requires:

byte    SSH_AGENT_EXTENSION_RESPONSE (29)
string  extension type                   ← MUST echo the request name
byte[]  extension response-specific contents

ssh-agent-lib's Extension::decode reads the first string as the extension name (correct per spec). When pivy-agent omits the name echo, ssh-agent-lib interprets the first 4 bytes of the PIV box binary as a u32 string length, then tries to read that many bytes as UTF-8 — which fails.

Why query works but ecdh doesn't

pivy#15 (0f2725e) added the extension name echo for query responses (line 2204 in pivy-agent.c), but the same fix was not applied to the ecdh/ecdh-rebox handlers (lines 1721-1722, 1869-1870).

Fix ownership

ssh-agent-lib's Extension::decode is correct per spec — the name echo is mandatory in all type-29 responses. The fix belongs in pivy-agent: add sshbuf_put_cstring(msg, "ecdh-rebox@joyent.com") (and "ecdh@joyent.com") after the type byte, before the response data.

Filing as a new issue on amarbel-llc/pivy.

[sfriedenberg-etsy]

Verified: end-to-end decrypt works through ssh-agent-mux

With pivy b359ce7 (amarbel-llc/pivy#16 fix) running as pivy-agent, piggy show through ssh-agent-mux decrypts on the first attempt with no warnings:

$ PIGGY_STORE_DIR=~/eng-etsy/.piggy piggy show jira-api-token
Using key 'PIV_slot_9D C291D27B /CN=sfriedenberg' in ssh-agent...
<secret decrypted successfully>

No "failed to unlock ebox with agent" warning. No PIN fallback. The ecdh-rebox extension round-trip through the mux works correctly.

Component versions verified

• pivy-agent: b359ce7 (includes ecdh name echo fix from pivy#16)
• ssh-agent-mux: ad23a6d (includes QueryResponse wire format fix from ssh-agent-lib#1)
• ssh-agent-lib: ad23a6d (correct Extension encode/decode, was already spec-compliant)

Conclusion

No changes needed in ssh-agent-lib. The root cause was pivy-agent omitting the extension name echo for ecdh responses (fixed in pivy#16). ssh-agent-lib's Extension::decode was correct per spec all along. This issue can be closed.