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
scheme to connect:
$ whoami harry $ svn list svn+ssh://host.example.com/repos/project firstname.lastname@example.org'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
-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
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. ...