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.fixed
cmd
> 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
Received on Wed Jun 13 20:04:53 2007