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

Re: SVN+SSH access not advisable

From: Michael L Brown <michael.l.brown_at_philips.com>
Date: Fri, 25 Jul 2008 09:41:48 -0500

We use svn+rsh (in the building) and svn+ssh for those who work in the
building and remotely.

If someone was able to get a shell, so what. Why? Because they have an
account and a login on the system anyway, so if they want a shell, they can
get one by either doing rsh or ssh to any system on the internal LAN. The
ssh login to SVN is not a SVN only use login.

Using svn+rsh/svn+ssh has never given us any trouble.

YMMV :-)

MB
 --
Mike Brown (Michael.L.Brown_at_Philips.com)
            Blackberry: vidiot_at_uscellular.blackberry.com
Philips Medical, Fitchburg, WI
Desk: 608-288-6969 Fax: 608-298-2101
PMS direct: 164-6969
You design it, I'll build it!

                                                                           
                                                                           
                                                                           
                                                                        To
                                       Marko Käning <mk362_at_mch.osram.de>
                                                                        cc
     Stefan Sperling Paul Koning <Paul_Koning_at_Dell.com>
     <stsp_at_elego.de> users_at_subversion.tigris.org
                                                                   Subject
     07/25/2008 08:55 AM Re: SVN+SSH access not advisable
                                                            Classification
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           

On Fri, Jul 25, 2008 at 01:07:55PM +0200, Marko Käning wrote:
> > That doesn't sound right. What exactly does it say, and where does it
> > say it? I can't find anything like this.
>
> Well, see Chapter six of the 1.4 SVN book on page 144:
>
> <qote>
> If you have an existing infrastructure heavily based on SSH accounts, and

> if your users already have system accounts on your server machine, then
it
> makes sense to deploy an svnserve-over-ssh solution. Otherwise, we don't
> widely recommend this option to the public. It's generally considered
> safer to have your users access the repository via (imaginary) accounts
> managed by svnserve or Apache, rather than by full-blown system accounts.

> If your deep desire for encrypted communication still draws you to this
> option, we recommend using Apache with SSL instead.
> </quote>
>
> My users must be members of a certain group. This groups gets full write
> access to the corresponding repository files. So everything (seems) to
> work fine. Perhaps it only seems so?

That's just saying "ssh might give your users a shell if not
configured otherwise, but apache won't EVER do that'.

If you don't want users to be able to launch a shell on the
server via ssh, force them to use key authentication and
set the command to be run from the authorized_keys files
of your users, by prepending a command= flag to every key in
these files:

  command="/usr/bin/svnserve
-t",no-agent-forwarding,no-X11-forwarding,no-port-forwarding ssh-rsa
AAA....

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org

graycol.gif pic20900.gif ecblank.gif
Received on 2008-07-25 16:39:50 CEST

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.