On 7/26/07, email@example.com
On 05:49 pm, firstname.lastname@example.org 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