Sahadeo Raskonda wrote:
> Further configured SVN+SSH access by
>
> 1) Creating System users on the Box.
>
> 2) Wrapper script to embed svnserve
>
> Like all steps in http://svn.haxx.se/dev/archive-2004-03/0253.shtml
> <http://svn.haxx.se/dev/archive-2004-03/0253.shtml>
>
> and it works fine....
>
> But problem is users can logon onto Box and delete entire REPO !!!
I've never bothered with a wrapper script on our SVN server. We're
running SVN inside a virtual server with the following restrictions:
1) The sshd daemon only allows use of public-keys to authenticate.
2) User accounts are created and assigned a very long randomized
password that they are never told.
3) User accounts get added to a group (i.e. "svn-reposname") for each
repository that they need to access. Each repository directory is owned
by that group with the following permissions:
# cd /var/svn
# svnadmin create reposname
# chmod -R 770 reposname
# chgrp -R svn-reposname reposname
# chmod -R g+s reposname/db
4) Users have SSH public keys that they use to authenticate to the SVN
server with (using PuTTY + Pageant). Those keys are locked down with:
command="/usr/bin/svnserve -t -r
/var/svn",no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding
5) We configure a session in PuTTY with the following steps:
a) New session
b) Host name: svn.example.com
c) Host port: 922
(we run SSH on a non-standard port to lessen the # of attacks)
d) Connection, Data, Auto-Login name: (fill in username)
e) Save session as "svn.example.com:922"
(we access SVN using "svn+ssh://svn.example.com:922/reposname")
6) Our Windows users run a batch file when they login that loads the SVN
SSH key into Pageant (prompting them for their password), after which
point everything is seamless.
...
AFAIK, all of the above means that our users cannot get a shell account
on our SVN server. We get a few thousand attack attempts per month on
port 22/tcp (which is why we're moving the SVN server to an alternate
port this month).
If you need to share the server with regular user accounts you could
create svn-specific user accounts, put the SSH public key in those
authorized_keys files and authenticate the users using those
svn-specific accounts.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 13 17:14:17 2007