General thinking here:

I'm authenticating the user on the destination service by having the proxying service connect with a trusted device key and a special flag that says "I'm acting on behalf of @alincoln". A different approach I could have taken is to generate a "cluster SSH key" for each user and use that instead, which would be more similar to what we do with Conduit.

I didn't do that because it's more complex and significantly more work (to write, and to build the keys, and to use the keys), and I don't think it really increases security (if anything, it probably decreases security slightly, because the device key is harder for an attacker to get access to than user keys would need to be). The biggest drawback I see with this approach is that it's not the same as what we do with Conduit, which makes it harder to understand, but I think that's balanced by the smaller amount of code.

So the overall flow here is something like this:

...if that makes any sense. The magic part there is in the third command, where we add @alincoln and the ssh-exec on the other end unpacks that to act as @alincoln.

The actual proxying is easy because in all cases we can just swap the VCS command out for one which has the exact same behavior but is nonlocal. We even get the whole SVN mess for free.

Caught a couple of things...