simon-git: putty (main): Simon Tatham

Wed Dec 23 22:30:02 GMT 2020

TL;DR:
  b4e11108 Relax criteria for accepting agent-forwarding channel-opens.
  e9e6c03c Uppity: add stunt for unauthorised agent forwarding attempts.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2020-12-23 22:30:02

commit b4e111089206daa3521b1f92d3d4cf05e799e518
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=b4e111089206daa3521b1f92d3d4cf05e799e518;hp=04c50b6cfd0004bae44fa135c8493561ed608f55
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Dec 23 22:26:44 2020 +0000

    Relax criteria for accepting agent-forwarding channel-opens.

    Previously, the instant at which we send to the server a request to
    enable agent forwarding (the "auth-agent-req at openssh.com" channel
    request, or SSH1_CMSG_AGENT_REQUEST_FORWARDING) was also the instant
    at which we set a flag indicating that we're prepared to accept
    attempts from the server to open a channel to talk to the forwarded
    agent. If the server attempts that when we haven't sent a forwarding
    request, we treat it with suspicion, and reject it.

    But it turns out that at least one SSH server does this, for what
    seems to be a _somewhat_ sensible purpose, and OpenSSH accepts it. So,
    on the basis that the @openssh.com domain suffix makes them the
    arbiters of this part of the spec, I'm following their practice. I've
    removed the 'agent_fwd_enabled' flag from both connection layer
    implementations, together with the ConnectionLayer method that sets
    it; now agent-forwarding CHANNEL_OPENs are gated only on the questions
    of whether agent forwarding was permitted in the configuration and
    whether an agent actually exists to talk to, and not also whether we
    had previously sent a message to the server announcing it.

    (The change to this condition is also applied in the SSH-1 agent
    forwarding code, mostly for the sake of keeping things parallel where
    possible. I think it doesn't actually make a difference in SSH-1,
    because in SSH-1, it's not _possible_ for the server to try to open an
    agent channel before the main channel is set up, due to the entirely
    separate setup phase of the protocol.)

    The use case is a proxy host which makes a secondary SSH connection to
    a real destination host. A user has run into one of these recently,
    announcing a version banner of "SSH-2.0-FudoSSH", which relies on
    agent forwarding to authenticate the secondary connection. You connect
    to the proxy host and authenticate with a username string of the form
    "realusername#real.destination.host", and then, at the start of the
    connection protocol, the server immediately opens a channel back to
    your SSH agent which it uses to authenticate to the destination host.
    And it delays answering any CHANNEL_OPEN requests from the client
    until that's all done. For example (seen from the client's POV,
    although the server's CHANNEL_OPEN may well have been _sent_ up front
    rather than in response to the client's):

    client: SSH2_MSG_CHANNEL_OPEN "session"
    server: SSH2_MSG_CHANNEL_OPEN "auth-agent at openssh.com"
    client: SSH2_MSG_CHANNEL_OPEN_CONFIRMATION to the auth-agent request
            <- data is exchanged on the agent channel; proxy host uses
               that signature to log in to the destination host ->
    server: SSH2_MSG_CHANNEL_OPEN_CONFIRMATION to the session request

    With PuTTY, this wasn't working, because at the point when the server
    sends the auth-agent CHANNEL_OPEN, we had not yet had any opportunity
    to send auth-agent-req (because that has to wait until we've had a
    CHANNEL_OPEN_CONFIRMATION). So we were rejecting the server's
    CHANNEL_OPEN, which broke this workflow:

    client: SSH2_MSG_CHANNEL_OPEN "session"
    server: SSH2_MSG_CHANNEL_OPEN "auth-agent at openssh.com"
    client: SSH2_MSG_CHANNEL_OPEN_FAILURE to the auth-agent request
            (hey, I haven't told you you can do that yet!)
    server: SSH2_MSG_CHANNEL_OPEN_FAILURE to the session request
            (in that case, no shell session for you!)

 mainchan.c              |  1 -
 ssh.h                   |  9 +++------
 ssh1connection-client.c |  2 +-
 ssh1connection.c        | 10 ----------
 ssh1connection.h        |  2 --
 ssh2connection-client.c |  2 +-
 ssh2connection.c        | 10 ----------
 ssh2connection.h        |  1 -
 8 files changed, 5 insertions(+), 32 deletions(-)

commit e9e6c03c6eba045f69ec402a528254d304b857d7
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=e9e6c03c6eba045f69ec402a528254d304b857d7;hp=b4e111089206daa3521b1f92d3d4cf05e799e518
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Dec 23 22:26:44 2020 +0000

    Uppity: add stunt for unauthorised agent forwarding attempts.

    With the new --open-unconditional-agent-socket option, every time
    Uppity receives an SSH connection, it will immediately open a Unix-
    domain socket and attempt to do agent forwarding on it, in the sense
    that any connection to that socket will be turned into an
    "auth-agent at openssh.com" CHANNEL_OPEN request on whichever SSH
    connection it was associated with.

    That connection-global socket is independent of any that are created
    as part of setting up a session channel. The pathname of the socket
    file is written to the server's event log (there being no other
    sensible place to send it).

    The aim is that this allows me to test the behaviour of an SSH client
    if the server tries to open an agent-forwarding channel outside the
    usual context. In particular, it allows me to test the change I just
    made in the previous commit, that if you enable agent forwarding in
    the client configuration, then auth-agent channels opened by the
    server are accepted even if no session channel opened by the client
    has sent an auth-agent-req. More importantly, it allows me to check
    that I _haven't_ accidentally arranged that those channels are
    accepted even when agent forwarding is _not_ permitted by the client
    configuration!

    Implementation details: the agent forwarding socket was previously
    implemented as part of the internal sesschan structure. I've moved it
    out into a little sub-struct of its own which can be created
    independently of a sesschan.

 sesschan.c      | 70 ++++++++++++++++++++++++++++++++++++++++-----------------
 sshserver.c     | 15 +++++++++++++
 sshserver.h     |  5 +++++
 unix/uxserver.c |  2 ++
 4 files changed, 71 insertions(+), 21 deletions(-)