Version Control with Subversion - Login

Server ConfigurationA few words of warning: first, make sure the “realm” argument to saslpasswd2 matchesthe same realm you've defined in your repository's svnserve.conf file; if they don'tmatch, authentication will fail. Also, due to a shortcoming in SASL, the common realm mustbe a string with no space characters. Finally, if you decide to go with the standard SASLpassword database, make sure the svnserve program has read access to the file (andpossibly write access as well, if you're using a mechanism such as OTP).This is just one simple way of configuring SASL. Many other authentication mechanismsare available, and passwords can be stored in other places such as in LDAP or a SQLdatabase. Consult the full SASL documentation for details.Remember that if you configure your server to only allow certain SASL authenticationmechanisms, this forces all connecting clients to have SASL support as well. Any Subversionclient built without SASL support (which includes all pre-1.5 clients) will be unable toauthenticate. On the one hand, this sort of restriction may be exactly what you want (“Myclients must all use Kerberos!”). However, if you still want non-SASL clients to be able toauthenticate, be sure to advertise the CRAM-MD5 mechanism as an option. All clients areable to use CRAM-MD5, whether they have SASL capabilities or not.SASL encryptionSASL is also able to perform data encryption if a particular mechanism supports it. Thebuilt-in CRAM-MD5 mechanism doesn't support encryption, but DIGEST-MD5 does, andmechanisms such as SRP actually require use of the OpenSSL library. To enable or disabledifferent levels of encryption, you can set two values in your repository's svnserve.conffile:[sasl]use-sasl = truemin-encryption = 128max-encryption = 256The min-encryption and max-encryption variables control the level of encryption demandedby the server. To disable encryption completely, set both values to 0. To enablesimple checksumming of data (i.e., prevent tampering and guarantee data integrity withoutencryption), set both values to 1. If you wish to allow—but not require—encryption, set theminimum value to 0, and the maximum value to some bit length. To require encryption unconditionally,set both values to numbers greater than 1. In our previous example, we requireclients to do at least 128-bit encryption, but no more than 256-bit encryption.Tunneling over SSHsvnserve's built-in authentication (and SASL support) can be very handy, because itavoids the need to create real system accounts. On the other hand, some administratorsalready 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” theserver machine.It's easy to use SSH in conjunction with svnserve. The client simply uses thesvn+ssh:// URL scheme to connect:$ whoamiharry$ svn list svn+ssh://host.example.com/repos/projectharryssh@host.example.com's password: *****foobar166