Buffer problem in ssh agent forwarding

[payne1982]

AI found this bug in version 0.2.19 when I was trying to enable ssh agent forwarding. I tested the fix and it works for me now.

Bug: Buffer.skip() misuse in ChannelAgentForwarding.write() corrupts message framing

Where: ChannelAgentForwarding.java, method write(), the else branch handling unknown message types.

When it manifests: When the SSH client sends SSH2_AGENTC_EXTENSION (type 27), introduced in OpenSSH 8.x for session binding. Prior to OpenSSH 8.x this else branch was effectively dead code, so the bug went unnoticed.

Effect: One byte of the current message body is left unread in rbuf. On the next write() call it is prepended to the incoming data and interpreted as the first byte of the next message's 4-byte length field, completely corrupting its parsing (in our case producing a spurious type 115 instead of the expected type
11 SSH2_AGENTC_REQUEST_IDENTITIES, which caused agent forwarding to fail with "agent refused operation").

Root cause: Buffer.skip(n) performs index += n, advancing the write pointer, not the read pointer (s). The name "skip" is misleading for anyone expecting it to discard already-received bytes. The correct fix is to advance s directly:

- rbuf.skip(rbuf.getLength() - 1);
+ rbuf.s += rbuf.getLength();
mbuf.putByte(SSH_AGENT_FAILURE);

Note the additional - 1 in the original, which makes the off-by-one worse: even if skip() had advanced s, it would still have left one byte behind.

[payne1982]

Buffer.skip(n) advances the write pointer (Buffer.index), not the
read pointer (Buffer.s). In the else-branch for unknown message
types the original code calls rbuf.skip(rbuf.getLength() - 1), which
leaves the unread body bytes in place and shifts the write end instead.
On the next call to write(), rbuf.getLength() returns a bloated value,
so the next message header is read from the wrong offset and its type
byte is misidentified.

The symptom observed in practice: after a valid SSH2_AGENTC_SIGN_REQUEST
(type 13) the OpenSSH client sends an SSH2_AGENTC_EXTENSION (type 27)
introduced in OpenSSH 8.0. The else-branch is hit, skip() corrupts the
read position, and the subsequent message is parsed as type 115 (garbage),
causing the forwarding agent to return SSH_AGENT_FAILURE for every
following request.

Fix: advance rbuf.s by rbuf.getLength() to correctly consume all
remaining body bytes without touching the write pointer.

Note: the original code also has an off-by-one (getLength()-1 instead of
getLength()) because getByte() has already consumed the type byte, so
getLength() is already msgLen-1 at that point.

  --- a/src/main/java/com/jcraft/jsch/ChannelAgentForwarding.java
  +++ b/src/main/java/com/jcraft/jsch/ChannelAgentForwarding.java
  @@ -234,8 +234,12 @@ class ChannelAgentForwarding extends Channel {
       } else if (typ == SSH2_AGENTC_ADD_IDENTITY) {
         int fooo = rbuf.getLength();
         byte[] tmp = new byte[fooo];
         rbuf.getByte(tmp);
         boolean result = irepo.add(tmp);
         mbuf.putByte(result ? SSH_AGENT_SUCCESS : SSH_AGENT_FAILURE);
       } else {
  -      rbuf.skip(rbuf.getLength() - 1);
  +      // Advance the *read* pointer past the remaining body bytes so the
  +      // next message is not corrupted.  Buffer.skip(n) advances the write
  +      // pointer (index), not the read pointer (s) — do not use it here.
  +      rbuf.s += rbuf.getLength();
         mbuf.putByte(SSH_AGENT_FAILURE);
       }

ChannelSession.setAgentForwarding(true) sets the channel-level flag
agent_forwarding, which causes sendRequests() to send the
auth-agent@openssh.com channel request to the server. The server
then opens a reverse "auth-agent@openssh.com" channel back to the
client.

However, Session.run() guards acceptance of that reverse channel with
a separate field:

    if (!"forwarded-tcpip".equals(ctyp)
        && !("x11".equals(ctyp) && x11_forwarding)
        && !("auth-agent@openssh.com".equals(ctyp) && agent_forwarding)) {
        // reject with SSH_MSG_CHANNEL_OPEN_FAILURE
    }

This Session.agent_forwarding field is never set by
ChannelSession.setAgentForwarding(), so the reverse channel is always
rejected and agent forwarding silently fails even though the channel
request was sent correctly.

Fix: set _session.agent_forwarding = true in sendRequests() immediately
after the RequestAgentForwarding is dispatched. Both classes are in
the same package so the package-private field is accessible directly.

  --- a/src/main/java/com/jcraft/jsch/ChannelSession.java
  +++ b/src/main/java/com/jcraft/jsch/ChannelSession.java
  @@ -187,6 +187,7 @@ class ChannelSession extends Channel {
       if (agent_forwarding) {
         request = new RequestAgentForwarding();
         request.request(_session, this);
  +      _session.agent_forwarding = true;
       }

       if (xforwading) {

  ---

[norrisjeremy]

Have you actually validated and confirmed these bugs happen in practice?
And that the the suggested changes remedy them?
Is it possible to create ITs that actively trigger these issues and confirm they are then resolved with the suggested fixes?

[payne1982]

I have tested with my Android App that uses these classes and a Linux server that worked with other ssh client software.
I added a lot of debugging to find out. The communication between server and client skips one byte because of that skip() and the agent fails to authorize the forwarding.

If I overwrite the classes with the suggested code, the communication with the agent works as intended.

---

Bug: Buffer.skip() misuse in ChannelAgentForwarding.write() corrupts message framing

Where: ChannelAgentForwarding.java, method write(), the else branch handling unknown message types.

When it manifests: When the SSH client sends SSH2_AGENTC_EXTENSION (type 27), introduced in OpenSSH 8.x for session binding. Prior to OpenSSH 8.x this else branch was effectively dead code, so the bug went unnoticed.

Root cause: Buffer.skip(n) advances the write pointer (index), not the read pointer (s). The original code rbuf.skip(rbuf.getLength() - 1) leaves all unread body bytes in place and shifts the write end instead. On the next write()
call, rbuf.getLength() returns a bloated value, so the next message's length field and type byte are read from the wrong offset.

Symptom observed: After SSH2_AGENTC_EXTENSION (type 27) hits the else-branch, the subsequent SSH2_AGENTC_REQUEST_IDENTITIES (type 11) is parsed as type 115 (garbage), causing agent forwarding to fail with SSH_AGENT_FAILURE for every
request after the extension message.

Additional off-by-one: the original uses getLength() - 1 instead of getLength() — getByte() has already consumed the type byte, so getLength() is already msgLen - 1 at that point, making the skip short by one extra byte.

---

[payne1982]

The server ssh is:

$ ssh -V
OpenSSH_10.2p1, OpenSSL 3.5.5 27 Jan 2026

to reproduce I connect to this server and then I ssh again to jump on another server. You can see with ssh -vvv that agent refuses connection.

[norrisjeremy]

And to confirm: you have confirmed the problem exists with the current release (2.27.9)?
You mention a much earlier release (0.2.19).

[payne1982]

the snippet of code from ChannelAgentForwarding.java seems unchanged from 0.2.19. I think the behavior is the same. I can try to update if you think it's a valid test.

[norrisjeremy]

Yes, please validate that the problems you are having still occur with the current release.
There have been changes to ChannelAgentForwarding.java between 0.2.19 & 2.27.9 (see 91d1cc3).

[payne1982]

Hello, I updated my app code to include JSCH 2.27.9. Unfortunately I'm getting the same behavior.