On Tuesday, August 09, 2005 02:17:56 -0400 der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> wrote:
I see. I guess I tend not to consider undocumented protocols as worth considering. Perhaps it's just me, but I've never been much good at implementing undocumented protocols.
But figuring out what the protocol is supposed to be is half the fun!Seriously, I'm very interested in seeing an agent protocol documented, preferably one with a well-defined extension mechanism(*).
Out of curiosity, does it suffer from the same bugs as the existing agent draft (notably, assuming that it's running over IP)?
I don't believe so. The existing agent draft contains a lot of stuff about tagging forwarded agent connections at each hop, so you can tell where things came from. That might be interesting, but I don't see it being deployed any time soon.
I also can't see any reason an implementation couldn't support both, perhaps with a slight tweak to the more recent draft if, as it implies, the old protocol uses the same channel type string as agent-02. (I already have to use private versions of the requests to make agent forwarding work with connection sharing....)
In most cases the ssh client doesn't implement the agent protocol; it just forwards it off to some program running on the same machine. From a practical standpoint, I think the best option is to make the protocol backwards-compatible and use the same channel string. Otherwise implementations like OpenSSH end up having to export _two_ ports for talking to the agent, depending on which version of the protocol you want it to speak.
I would note that because all the messages are different, it should be possible to support both protocols on the same channel, and the current draft describes how a client can tell whether the agent supports the new protocol.
(*) Note that the current agent draft does _not_ have a well-defined extension mechanism, as the mechanism it defines requires sending a message code which does not fit in the 8-bit field defined for the purpose...
-- Jeff