Re: agent draft updated

Niels Möller <[email protected]> wrote:
> But to make that work properly if agent forwarding is requested on
> multiple channels, it would help if the CHANNEL_OPEN request includes
> the id of that associated channel (which it doesn't, according to the
> draft. iirc, x11 forwarding has the same issue).

Yes! This was an inconvenience to me when developing PuTTY's connection
sharing support, because two instances of PuTTY sharing an SSH
connection aren't able to independently forward different agents to
their particular session channel.

I was able to work around the issue for X11 connections (don't look at
how I did it unless you have a strong stomach :-), but for agent
connections, there doesn't seem to be any way round it. If you're doing
agent forwarding within an SSH connection, there must be exactly one
agent that is forwarded to all participating session channels.

If we're defining new message names anyway then it would be nice to fix
that, although on the other hand there is a risk that this is the start
of feature creep that won't stop until the draft is twice the size...

> The client could still keep track of number of active sessions with
> agent forwarding enabled, and refuse auth-agent@ CHANNEL_OPEN once that
> count goes down to zero.

I'm pretty sure that in OpenSSH, this isn't done: auth-agent@
CHANNEL_OPENs are accepted unconditionally if the user has authorised
the client to forward the agent at all.

Cheers,
Simon

-- 
import hashlib; print((lambda p,q,g,y,r,s,m: (lambda w:(pow(g,int(hashlib.sha1(
m.encode('ascii')).hexdigest(),16)*w%q,p)*pow(y,r*w%q,p)%p)%q)(pow(s,q-2,q))==r
and s%q!=0 and m)(12342649995480866419, 2278082317364501, 1670428356600652640,
5398151833726432125, 645223105888478, 1916678356240619, "<[email protected]>"))