Add our own ssh replacement for standardizing on behavior.

Review Request #2023 — Created Dec. 29, 2010 and submitted


Review Board


Add our own ssh replacement for standardizing on behavior.

Our usage of the system ssh for ssh-backed repositories had some
behavioral problems that, on newer systems, made working with ssh
difficult. In particular, ssh no longer uses $HOME/.ssh, but rather
checks /etc/passwd for the home directory and uses that. Even when
using the options to specify a custom configuration file or private key.
This meant we couldn't use the Review Board instance's data/.ssh directory,
making ssh not work out of the box without tweaks to /etc/passwd. Even
with these tweaks, the change would apply to all websites on that system.

We now provide a new ssh replacement called rbssh. This provides the
remote execution operations of ssh that many SCMTools care about. The
SCMTools we ship use ssh to run a command on the remote end to grab
information on the repository or to perform operations. rbssh implements
this, through the paramiko library, which we already depend on.

rbssh links up stdin, stdout, and stderr between the caller and the
remote end. It does this both on Windows and Posix-compliant platforms.

All the SCMTools that allow for ssh-backed repositories are now set up
to use rbssh instead of ssh. For the most part, this is just done through
environment variables. In Mercurial's case, we just set a config option on
the client.

  1. This gets installed to /usr/bin? We might want to stick it somewhere libexec-ey instead.
    1. I tried this originally, by having it use "python{version} /path/to/", but for git it wouldn't even work. It expects a single value for $GIT_SSH, due to how it invokes it. So, it needs to be made executable, which setuptools handles, in order to reference that exact script. Unfortunately, as far as I know, I can't tell the setuptools stuff to install it to a different location, so I'm out of luck there.