On 7/26/07, glyph@divmod.com <glyph@divmod.com> wrote:
On 09:14 pm, paulswartz@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 actually meant Connector :) There's also Creator (in comparison with t.i.protocol.ClientCreator).
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@foo.com", they're both very necessary use-cases.
So how about this: class IConch<C word>(Interface): def connect(host, port=22, user=None, knownHosts=None, authentications=None): where user defaults to the current username, knownHosts defaults to the to hosts in known_hosts, and authentications defaults to a key agent or the keys in .ssh/id_*. To keep the current use case of verifying a host key with a function, knownHosts could be a filename string, in which case it would be read for host keys, or a function in which case it is called with the key and fingerprint. authentications would be a list functioning the same was as in my initial outline. This would make the default .connect(hostname) work equivalently to the default 'ssh hostname' but still give options for the other overrides. -p -- Paul Swartz paulswartz at gmail dot com http://z3p.livejournal.com/ AIM: z3penguin