Re: Secure Shell WG: what's left?

[Jeffrey Hutzelman <jhutz%cmu.edu@localhost>]

On Tuesday, August 09, 2005 09:03:30 -0400 der Mouse 
<mouse%Rodents.Montreal.QC.CA@localhost> wrote:

> > 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 believe my implementation does it correctly according to some version
> of the draft (probably -01).  Does that count as "deployed"?

It does if anyone's running your code, I guess.  But having implemented it, 
you know there are problems, like what to do for the links that are not 
over IP.


> > > 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.
> > 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.
>
> That may or may not describe my implementation, depending on exactly
> what you mean by "the ssh client" and "some program".  In my case, the
> client and the agent are implemented in the same executable, but run in
> different processes.

In both cases I actually mean running processes.  So yes, I think that 
describes your implementation.

> > 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.
>
> Ports?  All the implementations I've used (including my own) use
> AF_LOCAL sockets in /tmp, rather than anything with "ports".

Sorry; my error.


> That aside, yes, it would mean either two rendezvous points (of
> whatever kind) or protocols different enough that the implementation
> can tell which version is in use from the first packet - and in the
> latter case you might as well use the same strings, as you say.
>
> > 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.
>
> Yes...but the method is an ugly kludge, because, as I read it, the
> messages *aren't* all different; there's a collision between agent-02's
> REQUEST_VERSION and 1.x please-list-identities.  If we're going to do a
> new agent protocol, I'd like to see that fixed so there's no message
> number overlap.

I believe that particular collision is deliberate, to allow a client to 
tell which version of the protocol is supported.  It's possible the 
mechanism needs some work, in which case we should do that.


Ultimately, what we're doing is providing connectivity between an ssh 
client and an agent, both of which implement unknown versions of the 
protocol.  It seems to me that if we can arrange to run either version of 
the protocol over the same channel, we've made things a lot simpler and 
more likely to interoperate.


> How can I best help this happen?  Should I sit down with the 1.x code
> and try to glark a spec for its agent forwarding protocol?  It seems
> inefficient for me to do that, as compared to someone who already knows
> the protocol, but if it'd help I can take a swing at it.

As I understand it, there isn't really an agent forwarding protocol, aside 
from the messages defined in the ssh spec for that purpose.  They basically 
just channel the same protocol that is spoken between ssh client and agent, 
with no changes.  It seems fairly straightforward to discover the basic 
form of the protocol from the code; it's essentially the same structure as 
what's defined in the agent draft, but the message numbers and contents are 
different.

I think it's premature to write up a spec based on the old protocol, 
unless/until we decide we want to document and extend that and abandon 
what's in the agent draft.  Before we can do that, I think we need to 
answer a few questions...

- Is the tracing of forwarded connections worth keeping?
- Are the messages used by the old protocol too limited, such that
 new messages need to be defined in order to do everything we need?
- Is there some way we can add extensions to the old protocol in a
 sane fashion, so we don't crash the agent or desync the protocol
 if one side doesn't understand an extension?

Some of that is a matter of opinion; some requires reading the old 
protocol.  I don't have time this week to analyze the ssh agent protocol, 
but I can probably spend some time on it in the near future.

-- Jeff