On Wednesday, June 08, 2005 03:20:03 AM -0400 der Mouse <mouse%Rodents.Montreal.QC.CA@localhost> wrote:
I notice that the FORWARDING_NOTICE agent message (see agent-01) is inextricably entangled with the assumption that ssh is running over IP. What is the thinking on what will happen to it when someone implements what we're doing over something else, like (say) DECnet? While (as mentioned when I brought up the same issue with connection forwarding) we cannot be expected to standardize hwo to handle arbitrary underlying protocols, it does seem rather short-sighted to me to build a protocol that is unnecessarily difficult to extend. With connection forwarding the issue could be finessed by noting that the connection forwarding request is implicitly IP-specific; connection forwarding for some other protocol would use other request and channel type strings. But there is nothing similar available for agent FORWARDING_NOTICE messages, as far as I can see. Thoughts?
First of all, the most recent agent draft appears to be -02, which was published over a year ago. It's unfortunate that there doesn't seem to have been any more recent work on this; I'd very much like to see an extensible, interoperable agent protocol.
Second, it looks like it actually needs a fair bit of work before it will really be ready. In addition to the problem you point out, there's also another issue with forwarding. The normal case is that an SSH server receives an agent connection on a UNIX-domain socket, forwards over a channel to an SSH client, which establishes a UNIX-domain connection to an agent (or another SSH server). Now, who is supposed to insert the forwarding notice? The ssh server? The ssh client? Both? This does not appear to be well-specified.
There's also a significant problem with the extension mechanism. According to section 1.1, SSH_AGENT_EXTENSION is packet type 301. The problem is, that value doesn't fit in a byte! I understand the motiviation for representing packet types in a single byte and for avoiding the first 30 or so message numbers. But can we allocate the rest of the space more intelligently?
-- Jeff