Informing the SSH agent of the target user at server

[Hector Martin 'marcan']

On 2018-03-22 01:52, Peter Stuge wrote:
> Hector Martin 'marcan' wrote:
>>> Since forwarding ssh processes just forward agent socket bytes
>>> without tracking the protocol state in that stream adding a packet
>>> isn't trivial.
>>
>> It's reasonably trivial if the definition is that the forwarded-for
>> extension chain happens once when agent connections are opened. Then the
>> ssh process just needs to send the extension, wait for the reply
>> (whether positive or not-supported), eat it, and move on with forwarding
>> the remaining bytestream.
> 
> I wouldn't like to introduce a hard requirement for agent socket
> connections to only perform private key operations for a single nexthop.
> 
> The OpenSSH ssh client is but one agent socket consumer...

As far as I know, every downstream agent connection results in a new
upstream agent connection (agent connections are not muxed together into
one, but rather are independently forwarded). Therefore we can always
uniquely tag a given agent connection with the sequence of hops it
passed through at the start. I think this would add no extra latency if
implemented properly.

This would by necessity all be optional anyway (since older clients
won't do it). However, the final returned path should be secure in the
sense that a trusted node with a client that supports this will always
prepend the identity of the nexthop, so an "untrusted"/unexpected hop
will always be tagged by its parent, regardless or what it itself
chooses to do. I.e. a complete sequence of trusted (and known
implementing) hops guarantees that the request didn't inadvertently
traverse an untrusted/unexpected hop. The absence of forwarded-for
extensions means the consumer is on the local machine (e.g. a plain ssh
client without forwarding, or anything else).

It could be argued that a different forwarding client/design might want
to reuse agent connections across different paths... but that opens up a
bit of a can of worms regarding the protocol. At that point forwarders
would need to be able to parse everything, and I could see a lot of
interesting gotchas if a given forwarding client's understanding of the
protocol and the agent's differs, in the presence of a malicious target.
There's value in the clean break of using a new connection for each
forwarding path.

This is different from the remote-id (case 1). It's entirely reasonable
to want to be able to change that binding during a single session, e.g.
a single client authenticating to different targets reusing a single
agent connection.

> But I'm all for the idea for case 1.

FWIW I'm not too particular about this case, my main usecase is case 1.
I just think it would be neat to be able to display/log some metadata on
what the forwarding path is for any given operation too. This helps
secure against attacks when multiple forwardings are in use at once, by
making it explicit who is making the request.

-- 
Hector Martin "marcan" (marcan at marcan.st)
Public Key: https://mrcn.st/pub