Hello there. Nice work you do - reminds me the time we were
thinking to write a new source control in my previous company...
Here are some remarks/precisions/questions regarding svn+ssh
documentation. I am sorry I can't afford spending too much
time on sending you a proper patch (which I'd have liked to
do), but my english is not so good anyway.
If you really want a patch, please tell me and I could do it,
but I have something like 500 items with higher priority to
tackle with before and cannot promise anything for the next
6 months (at least ;-P)
Hoping this helps (and will help many people), here is the
Please Cc me for comments, I can't afford reading svn-devel
too (Oh yes, I would with pleasure, if only I had the time :-P).
FAQ: How do I set repository permissions correctly?
> If your clients are accessing via file:/// or svn+ssh://, then
> there's no way to avoid access by multiple users
NOK for svn+ssh, if the users don't have their own account on the server
but are using a shared svn account, with public keys in
SVNBOOK: Server Configuration - Overview
I would distinguish and emphasis on the two ways of using the
1. Using system accounts
2. Using only one subversion account, with public user keys
in .ssh/authorized keys.
This would add a fourth column in the Table 6.1:
* svnserve/ssh, one shared account
User account options: public keys in authorized_keys
Authorization options :
why does this differ from svnserve ?
Initial setup: somewhat simple.
(personally, I would not recommend the 'system accounts' solution,
for security reasons, and for the need to configure many accounts)
SVNBOOK: Choosing a Server configuration
Ditto, split svn+ssh in two:
* svnserve over ssh becomes svnserve over ssh (using many ssh accounts)
Cons: remove "or use a shared ssh key"
add bullet * Need to maintain many accounts (+security risks?)
add bullet * Can't set fine-grained permissions on the repository
* Add svnserve over ssh (one svn account, pubkeys in authorized_keys)
Pros: - Network protocol is stateful and noticeably faster than WebDAV.
- No need to define many user accounts
- All network traffic is encrypted
Cons: - Only one choice of authentication method.
- No logging of any kind, not even errors.
- Need to manage the keys for the users
Could someone tell me if the bullet "Can't set fine-grained permissions
on the repository" also applies ? Since svnserve can be notified
of the tunneled user (via --tunnel-user=...) why would it not be able
to handle permissions like standard svnserve ? (note that I did not
investigate this point yet.)
Recommendations, 4th bullet
"If you have an existing infrastructure heavily based on SSH accounts"
> If your deep desire for encrypted communication still draws you to
> this option, we recommend using Apache with SSL instead.
I would add "or use the svn+ssh method with a shared ssh account
and pubkeys listed in authorized_keys"
I would add the following recommendation: (not that I experienced it,
but it is obvious that it is dangerous)
If using svn+ssh, choose either the method using one ssh account
for each user, or the one using pubkeys in authorized_keys, but don't
mix them - oh no, don't.
Tunneling over SSH: should distinguish the 2 cases defined above.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Mar 11 00:16:59 2007