[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ANN: cvssh - secure ext-to-pserver bridge
From: |
Douglas Finkle |
Subject: |
RE: ANN: cvssh - secure ext-to-pserver bridge |
Date: |
Thu, 21 Feb 2002 22:16:59 -0500 |
Sorry, I've gotta jump in for a minute... Greg is right about
SSH v pserver, however.
> > There's only _EXACTLY_ one case where cvspserver is in any way more
> > secure than giving out real accounts, and that's when
> > pserver is used to
> > give read-only anonymous access to a _copy_ of a repository.
>
> And if the copy needs to get sync'd back to the "real"
> repository (a
> definate requirement), there goes your security. Next idea?
Read up on rsync via an ssh tunnel to do this. Sudo, and noshell
for a non-priviliged role account are also advisable.
> > In other words if you've given an account to an user to access a CVS
> > repostitory hosted on your network then you _MUST_ do whatever is
> > necessary to isolate that user's access from the data and
> services on
> > your network and in your systems that you do not trust them
> to access.
> > I.e. you give them limited trust.
>
> i.e. you give them no access. Hence, pserver. I don't
> want to give
> out shells to hundreds and thousands of developers using ssh.
> Using pserver,
> this works today, and is much more secure. I don't need
> accountability, I
> need security. pserver vs. ssh are not even _CLOSE_ to a
> comparible item.
Well, you're right here... security between ssh and pserver is
not even close-- ssh is secure, and pserver is not.
Also, you do not _need_ to provide the user w/ the ability to
login. In fact, the account that gets created should be LOCKED
to ensure it is not used. Next, lock down the ssh key on the
server end; read up on how to tell SSH it can exec exactly ONE
command-- cvs only needs one.
> > In other words you must comparmentalize access to your shared CVS
> > repository so that remote users can gain secure access to
> it while not
> > gaining access to anything you don't want them to access.
>
> Gee, sounds like pserver again. Once you hand out an
> ssh account,
> you give them a huge truck to drive through your wall of security,
> authenticated and validated.. with absolutely _NO_
> verifyability that the
> user on the other end is who you think it is.
Not so. You're creating a tiny pin hole, and it's very easily
closed by revoking the user's key pair on the server.
> It's an interesting idea, however.. not usable as users
> scale into
> the thousands.
Well, key management is a bit of work, and so is setting up a
well hardened cvs server. The key mgmt part it's easily scripted.
If I had more than a dozen users that's what I'd advise scripting
the administration.
I'm actually completing a setup aas described, and will be happy
to share it w/ the list when I have a bit more time. I just wanted
to add my 0.02 in defense of the SSH solution. For an externally
facing server it's the only sane thing to do.
-Dou
- Re: ANN: cvssh - secure ext-to-pserver bridge, (continued)
Re: ANN: cvssh - secure ext-to-pserver bridge, David A. Desrosiers, 2002/02/21
RE: ANN: cvssh - secure ext-to-pserver bridge,
Douglas Finkle <=