Nina Pham <nina@gibbons.com> writes:
> I built a cvs server. But the problem with it is: using pserver
> is not safe for our server; using ssh, people can get on our
> main server. svn is better or it is just the same as svn for
> this security issues?
I'm guessing what you mean by "can get on our main server" is
that they can get a shell. This is not necessarily true. When
using cvs or svn with ssh tunneling, you have some options that
don't involve giving the users a shell.
For anonymous access, you create an anonymous user whose shell is
a tiny program which execs cvs server or svnserve -t.
For authenticated access, you can use a similar approach and set
the shells of the users you don't want to have shell access to a
tiny program which execs cvs or svnserve appropriately. Or you
can set their shell to /sbin/nologin or whatever you use on your
system to deny shell access and install ssh keys into the users'
accounts command-restricted. See the sshd(8) man page for
details on placing such restrictions on a key.
The last is the approach i prefer. With it, you don't even have
to allow password-authentication on the system, since you are
requiring that everyone have an ssh key.
If you are concerned with security, you may want to keep a few
other things in mind.
svn+ssh and https are the only two secure access methods. While
you can configure both svn and http methods so as not to send
cleartext passwords, neither provide server verification. That
is, a user attempting to contact the repository has no guarantee
that he has connected to the system he thinks he has connected
to.
If you go with https, you probably do not want to run your
repository from an httpd that does anything else. Normally,
httpd should not have write access to any files. mod-dav-svn
requires this, however. You want to run your svn httpd with as
few modules loaded as possible, and not overlapping with any
other tasks, to limit the potential damage of a compromise.
Finally, be careful of anonymous access. Even read-only access
to a Berkeley db repository requires write access. Thus, if your
anonymous access server is compromised, the attacker has write
access to your repository. The fsfs back-end in 1.1 does not
have this flaw.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 30 03:18:13 2004