Reid Priedhorsky <[EMAIL PROTECTED]> writes: > B) Work machine. Run by others, many users. I'd like to also run my > database client (Python) here.
Well, just how much do you distrust that machine? If you think it's totally pwned by attackers who will stop at nothing to subvert your client, you shouldn't run the client there. How do you propose to open an SSH connection from a completely untrusted box, for example? You can't type an SSH password into it since you have to assume that the keystrokes are being logged. If you only partially distrust the machine, then figure out what operations on it you do trust, and work from there. > What I'd like is functionality similar to what Subversion does with > "svn+ssh://" URLs: an SSH tunnel that accepts only one connection and > doesn't have race conditions. That doesn't sound like the right answer. It means you have to carefully arrange your application to open just one db connection and use it throughout its run. Many applications are somewhat cavalier about opening and closing db conns, and and it's sometimes convenient to write in that style. Some apps (e.g. multi-threaded ones) inherently require multiple db conns. And even if you have an SSH mode that accepts just one connection, since your db app is separate and has to connect to the forwarding port after you use a separate program open the port, how do you stop someone else from grabbing it first? I think what you really want is normal, multi-connection SSH port forwarding to the db server, but that works only for you and doesn't work for others. That seems to mean one of: 1) authentication (like a db password) in the db client, maybe using another process that the db client gets a credential from 2) authentication through SCM_CREDENTIALS on a PF_UNIX socket 3) authentication via identd on the client machine (i.e. you trust the admins on that machine to keep malicious stuff off of the privileged ports) 4) some other scheme yet to be identified Actually, looking at the doc for ssh-agent(1), it looks like it might do something like #2 above. If I understand it, you would run your db client as something like ssh-agent your-client & and the ssh agent would start your client, exporting an env variable that your client can use to start ssh without a password and connect to the db server. The env variable points to a PF_UNIX socket where the doc says "the socket is made accessible only to the current user". Although the docs aren't totally clear, this sounds sort of like what we're discussing, so I'd say it's worth looking into. Finally, lately for unrelated reasons I've been looking at Vtun (vtun.sf.net), a simple VPN program that might be easier to modify than OpenSSH. Its security features look worse than ssh's, but maybe they're enough for your purpose. -- http://mail.python.org/mailman/listinfo/python-list