[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Passswords not encrypted

From: Joseph Mocker <mock+svn_at_fakebelieve.org>
Date: 2007-06-14 00:47:02 CEST

Ahh, cool stuff! I did not understand this capability first time though.
Thanks for the info.


Ryan Schmidt wrote:
> On Jun 13, 2007, at 12:37, Joseph Mocker wrote:
>> Benjamin Podszun wrote:
>>> Joseph Mocker wrote:
>>>> What would be nice is an "ssh-agent" type of capability for
>>>> subversion. Where one could authenticate once for a session, and
>>>> the agent would keep track of the authentication/password. When
>>>> authentication is needed, subversion would query the agent first.
>>> Why don't you use svn+ssh then?
>> Main reasons, per the "red-bean" subversion book:
>> * Requires users to be in same system group, or use a shared ssh key.
>> * Can lead to file permissions problems.
>> Coming from similar headaches with CVS, I didn't want to deal with
>> that again, svnserve seemed a good choice to not have to deal with that.
>> Also, unless there is a trick I don't know about (which there
>> probably is), the svn+ssh URLs to the repository include full
>> pathnames to the location of the repository on the server. So if I
>> decide to move that location, I have to tell all my developers to
>> update their URLs. OTOH, svnserve abstracts that for you.
> The trick is described in the book:
> http://svnbook.red-bean.com/en/1.2/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks.fixedcmd
>> Controlling the invoked command
>> Because we can specify the executed server-side command, it's easy to
>> name a specific svnserve binary to run and to pass it extra arguments:
>> command="/path/to/svnserve -t -r /virtual/root" TYPE KEY COMMENT
>> In this example, /path/to/svnserve might be a custom wrapper script
>> around svnserve which sets the umask (see the section called
>> “Supporting Multiple Repository Access Methods”). It also shows how
>> to anchor svnserve in a virtual root directory, just as one often
>> does when running svnserve as a daemon process. This might be done
>> either to restrict access to parts of the system, or simply to
>> relieve the user of having to type an absolute path in the svn+ssh://
>> URL.
> Joseph Mocker wrote:
>> I do use svn+ssh for one (private) repository for myself, but
>> currently for the group repository we're only using svnserve.
>> Hmm, thinking about shared ssh keys, actually I could probably create
>> a single server account with the users keys added to
>> .ssh/authroized_keys file, and people would access svn via that
>> account. That would mitigate permissions issues, but then do changes
>> get logged as the original user, or the server account?
> The next paragraphs at the above book URL address that issue:
>> It's also possible to have multiple users share a single account.
>> Instead of creating a separate system account for each user, generate
>> a public/private keypair for each person. Then place each public key
>> into the authorized_users file, one per line, and use the
>> --tunnel-user option:
>> command="svnserve -t --tunnel-user=harry" TYPE1 KEY1 harry@example.com
>> command="svnserve -t --tunnel-user=sally" TYPE2 KEY2 sally@example.com
>> This example allows both Harry and Sally to connect to the same
>> account via public-key authentication. Each of them has a custom
>> command that will be executed; the --tunnel-user option tells
>> svnserve -t to assume that the named argument is the authenticated
>> user. Without --tunnel-user, it would appear as though all commits
>> were coming from the one shared system account.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 14 00:49:35 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.