[Twisted-Python] potential connectSSH workflow

[Paul Swartz]

On 7/26/07, glyph at divmod.com <glyph at divmod.com> wrote:
> On 05:49 pm, paulswartz at gmail.com wrote:
> >I've written up a potential workflow for connectSSH, a simplified way
> >of using Twisted Conch.  It's available at
> >http://z3p.jot.com/WikiHome/SummerOfCode2007/connectSSH.  If those who
> >are interested could take a look, I'd love some feedback.
>
> Thanks a lot!  Here are my initial impressions:
>
> The bundle of crud that lives in ~/.ssh should be represented as an
> object.  connectSSH should really be a method on that object, so that
> things like host key verification can happen as normal and expected.
> This is especially true because that object can have references to other
> objects, such as the (Deferred-returning) UI for authorizing or denying
> an unexpected host key.  That object could also be more easily tested
> because the reactor could be an attribute of it rather than a global
> import.  Unfortunately there's a lot of code in Twisted that doesn't do
> this yet, but we should be building better use of that singleton.  See
> http://glyf.livejournal.com/70684.html


That makes sense:  a ConchConnection object which wraps some of the
nonsense that currently lives in t.c.scripts.conch like verifying a
host key and finding keys to use.  I still think that passing
authentication data in connect() is the right idea, but it can default
to using the keys that it finds in ~/.ssh or in a key agent.

> This also looks like an excellent use-case for endpoints.  Please see
> this ticket:
>     http://twistedmatrix.com/trac/ticket/1442
> and see if you have any feedback there.

I think making a ConchClientEndpoint which takes another
ClientEndpoint and some authentication data is a good interface, but
I'm not holding my breath for endpoints-1442 getting merged to trunk.
I'm already depending on at least 1-2 of my branches getting merged :)

-p
-- 
Paul Swartz
paulswartz at gmail dot com
http://z3p.livejournal.com/
AIM: z3penguin