IETF-SSH archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: agent draft updated
> 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?
Fair point. I think you're right - that only the channels the request
has been made on will/should get agent access - but I agree it should
be made explicit, even if it is made explicitly up to the server.
> 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.
To the extent that this is true, it's a misfeature in the server's OS.
But it's very common misfeature, so I agree it's worth mentioning that
it likely will not work to send it after requesting the shell or
command.
>> 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?
Personally? I would say that if the client receives it before it's
sent the auth-agent-req@, it _should_ reject the channel open, since
the server is trying to do something the client hasn't requested. If
they cross in transit...well, that's fuzzier. I'd say the client could
be justified in accepting it. But if the client can prove somehow (eg,
responses to other requests) that the server sent the channel open
before receiving the client's channel request, I'd say the client would
also be justified in refusing it.
> I believe that OpenSSH in practice will honour the request, on the
> basis that the user did authorise agent forwarding.
So, OpenSSH makes agent forwarding all-or-nothing? You can't authorize
agent forwarding for only certain channels on a connection? Then I
guess that's kind-of reasonable. But I'd still call it a case of the
client waving off a server-side offense.
moussh does this righter, I think; it has a private analog of
auth-agent-req which includes a cookie which is returned in the
auth-agent analog, so the client can tell which forwarding request the
channel open is in response to. (See moussh/private-algs.txt in the
moussh source.) Something like this seems necessary to me to get auth
agent forwarding right in the presence of connection sharing - IIRC
OpenSSH now has some form of connection sharing; do you happen to know
what it does for this when connection sharing is in use?
> 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. [...]
> - 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.
...before any channel opens? Interesting. I'm not entirely sure what
I think.
My initial reaction is to say that this use case should be handled with
a global variant of the auth-agent-req request. I'm not sure what I
think the detailed semantics should be.
I'll have to think about this. I've added it to moussh's todo list.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index