Re: agent draft updated

Damien Miller <[email protected]> wrote:
> Good idea, I added a section on forwarding that captures the currently-
> used @openssh.com names and includes an ext-info mechanism to advertise
> new names.

Thanks! But I have a couple of nits about that one, too.

The auth-agent-req@ request is a CHANNEL_REQUEST and not a
GLOBAL_REQUEST. But nothing is said about what that channel in
particular has to do with anything. What happens if I have multiple
session channels and send auth-agent-req@ on only some of them?

I think I know what will _actually_ happen - only the channels on which
I sent auth-agent-req@ will get SSH_AUTH_SOCK in the environment of
their shell or command. Other channels _can_ access the forwarded agent,
but only by furtling about by hand and digging the details out of
another session channel. But the spec should say something about it.

Also, you should probably mention that auth-agent-req@ needs to be sent
before actually starting a shell in the session channel, because after
that, it's too late to modify the shell's environment. (That sounds
obvious, but there _are_ channel requests that can be sent at any time,
like signals or window resizes, so if this isn't one of them, we should
say so.)

> After a client has requested that a session have agent forwarding
> enabled, the server later may request a connection to the forwarded
> agent.

What happens if the client is configured to allow agent forwarding, and
the server sends an auth-agent@ CHANNEL_OPEN request very early in the
session, at a point when the client hasn't actually got round to sending
the auth-agent-req@ CHANNEL_REQUEST yet?

I believe that OpenSSH in practice will honour the request, on the basis
that the user did authorise agent forwarding. Moreover, I know of a use
case in which someone actually relies on this. There's a particular type
of proxy SSH server which uses the following workflow:

 - You connect to the proxy server and authenticate with a username that
   includes information about where you want to connect through the
   proxy to. (Something like "username%real.destination.host", or maybe
   you have to separately specify your username on the proxy server and
   the one on the dest host.)

 - Once authentication at the proxy host succeeds, the proxy server
   makes its own SSH connection to the destination host. It also opens
   an "auth-agent@" channel back to your client, and uses the keys found
   in your agent to authenticate with the dest host.

 - Once authentication at the destination host succeeds, the proxy
   server continues to run two separate SSH transport layers (with your
   client and with the dest host SSH server) for the rest of the
   connection, and it passes connection-layer packets back and forth
   unmodified.

(I found out about this because PuTTY _didn't_ accept auth-agent@
channel opens until after it had sent its auth-agent-req@ request, and
it broke this proxy server's workflow. I decided that since it was your
protocol, you got to decide whether that was legal or not, so I changed
PuTTY to accept auth-agent@ in advance. But if someone's relying on
this, we should specify it! Or alternatively explicitly forbid it, if
you didn't actually mean this to work...)

Cheers,
Simon

-- 
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
 print("".join([chr(32+3*((k>>x)&1))for x in range(79)])) # <[email protected]>