[Twisted-Python] potential connectSSH workflow
glyph at divmod.com
glyph at divmod.com
Thu Jul 26 15:24:15 MDT 2007
On 09:14 pm, paulswartz at gmail.com wrote:
>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.
"Connection" seems like a weird name for that to me, as it applies it is
attached to a particular ... well, connection. Connector, maybe?
Client? ClientStorage? I guess those names have some pretty serious
problems too, but it's worth thinking about a better one.
>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.
I agree emphatically, but both the default and non-default cases are
equally important. There's a direct analogue in the user interface:
"ssh foo.com" will use your default key or agent, and your default
username, and that's 99% of usage. That, of course, doesn't mean you
can get rid of "ssh -i mykey.id_rsa foo.com" or "ssh otheruser at foo.com",
they're both very necessary use-cases.
>>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 :)
Definitely. This should be a separate ticket. In fact, far from asking
you to wait for it to be merged, I was wondering if you had any comments
on the interface that might come from use-cases that would arise in the
conch endpoint implementation that might even further delay it :).
More information about the Twisted-Python
mailing list