svnserve’s built-in authentication (and SASL support) can be very handy because it avoids the need to create real system accounts. However, some administrators already have well-established SSH authentication frameworks in place. In these situations, all of the project’s users already have system accounts and the ability to “SSH into” the server machine.
It’s easy to use SSH in conjunction with svnserve. The client simply uses the svn+ssh://
URL
scheme to connect:
$ whoami harry $ svn list svn+ssh://host.example.com/repos/project [email protected]'s password: ***** foo bar baz ...
In this example, the Subversion client is invoking a local
ssh process, connecting to host.example.com
, authenticating as the user
harryssh
(according to SSH user
configuration), and then spawning a private svnserve process on the remote machine running
as the user harryssh
. The svnserve command is being invoked in tunnel
mode (-t
), and its network protocol is being
“tunneled” over the encrypted connection by ssh, the tunnel agent. If the client performs
a commit, the authenticated username harryssh
will be used as the author of the new
revision.
The important thing to understand here is that the Subversion client is not connecting to a running svnserve daemon. This method of access doesn’t require a daemon, nor does it notice one if present. It relies wholly on the ability of ssh to spawn a temporary svnserve process, which then terminates when the network connection is closed.
When using svn+ssh://
URLs to
access a repository, remember that it’s the ssh program prompting for authentication,
not the svn
client program. That means there’s no automatic password-caching going
on (see Client Credentials Caching). The
Subversion client often makes multiple connections to the repository,
though users don’t normally notice this due to the password-caching
feature. When using svn+ssh://
URLs, however, users may be
annoyed by ssh repeatedly asking for
a password for every outbound connection. The solution is to use a
separate SSH password-caching tool such as ssh-agent on a
Unix-like system, or pageant on
Windows.
When running over a tunnel, authorization is primarily controlled
by operating system permissions to the repository’s database files; it’s
very much the same as if Harry were accessing the repository directly
via a file://
URL. If multiple system
users are going to be accessing the repository directly, you may want to
place them into a common group, and you’ll need to be careful about
umasks (be sure to read Supporting Multiple Repository Access Methods
later in this chapter). But even in the case of tunneling, you can still
use the svnserve.conf file to block
access, simply by setting auth-access =
read
or auth-access =
none
.[42]
You’d think that the story of SSH tunneling would end here, but it
doesn’t. Subversion allows you to create custom tunnel behaviors in your
runtime config file (see Runtime Configuration Area). For example, suppose you want to
use RSH instead of SSH.[43] In the [tunnels]
section of your config file, simply
define it like this:
[tunnels] rsh = rsh
And now, you can use this new tunnel definition by using a URL
scheme that matches the name of your new variable: svn+rsh://host/path
. When using the new URL
scheme, the Subversion client will actually be running the command
rsh host svnserve -t
behind the scenes. If you
include a username in the URL (for example, svn+rsh://username@host/path
), the client
will also include that in its command (rsh username@host
svnserve -t
). But you can define new tunneling schemes to be
much more clever than that:
[tunnels] joessh = $JOESSH /opt/alternate/ssh -p 29934
This example demonstrates a couple of things. First, it shows how
to make the Subversion client launch a very specific tunneling binary
(the one located at /opt/alternate/ssh) with specific options. In
this case, accessing an svn+joessh://
URL would invoke the particular SSH binary with -p
29934
as arguments—useful if you want the tunnel program to
connect to a nonstandard port.
Second, it shows how to define a custom environment variable that
can override the name of the tunneling program. Setting the SVN_SSH
environment variable is a convenient way to override the default SSH
tunnel agent. But if you need to have several different overrides for
different servers, each perhaps contacting a different port or passing a
different set of options to SSH, you can use the mechanism demonstrated
in this example. Now if we were to set the JOESSH
environment variable, its value would
override the entire value of the tunnel variable—$JOESSH would be executed instead of
/opt/alternate/ssh -p 29934
.