RE: ANN: cvssh - secure ext-to-pserver bridge

[Douglas Finkle]

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