[lug] VPN or SSH for cvs?

[D. Stimits]

Rob Nagler wrote:
> 
> > same effect as if you were leaving an SSH tunnel open.  If you leave
> > your keyboard open, anyone could come by and use your open tunnel, so
> > using ssh-agent is the same amount of risk.
> 
> Good point.  Interesting risk trade-off.  In the case of ssh-agent,
> you are opening up your private key to local snoopers.  The downside
> is that once the key is stolen, you can get to N machines, assuming
> you use the same private key for all your connections.

In my case, I am the only one using my machine, and my net connection is
a 56k modem, not left running 24/7. I am thoroughly firewalled, and
watch my logs continuously whenever connected. My reasoning is that if
someone were to boot my machine, I don't want to open things up via a
key, I want human intervention. But during the time I have my modem
connected (maybe an hour at a time), I don't want to have to supply a
password each time I do a cvs diff or log or status or checkin. Yet I
will never ever send my pass out on anything unencrypted. Now if I could
have a pass per session, with cvs staying open till I log out (this
works for non-ssh sessions...not exactly staying open, but it memorizes
the pass, useful for guests) or close my 56k connection, I'd be happy.
Being the solo user of this machine in my own home, I feel it's
reasonable to have a cvs that asks for my pass after I bring up the
modem, allowing me to do something like a login session instead of an
http hit-and-disconnect theme. I guess I'm looking for cvs session
management.

> 
> With tunneling, you leave the door open to just about anybody on the
> machine to get to one other machine and to a specific set of
> primitives.  The tunnel doesn't do user process auth.  (I would think
> ssh should do this, but it doesn't.)

Identd can be used at start of connection (I don't see why people
dislike auth port, there is a mistaken idea that it gives out
information...aside from being a verification against spoofing, it
doesn't really give out info to random requests). I would suspect man in
middle is rather difficult with strong encryption. The tunnel itself
should be OK against spoofing, it's just what goes through the tunnel
that you have to worry about. In my case, where I'm going from my home
machine to another machine that is firewalled and generally not open to
multiple users, I'm not too worried about someone getting in to a
machine at either end of the tunnel and using the tunnel...only
man-in-the-middle is relevant for my purposes, and it is a very low
threat.

> 
> I think tunneling cvs pserver has the best risk/reward ratio.  You get
> cvs without logins.  Your cvs password is different from your regular
> password because it is stored in ~/.csvpass.  In the worst case
> scenario, the cracker gains access to cvs on the remote machine.
> Since you can't delete anything with cvs, the damage is a denial of
> service attack by flooding the file system and/or packets.  This can
> be stopped by logging out.

Yes, tunneling pserver would be good, if I can guarantee that my cvs
requests will be forced to use the ssh or IPsec tunnel, and never ever
ever (did I mention never?) send even one request along a general
Internet route. The remote machine does not accept unencrypted
connections at all, so it would be useless for cvs to try to do so, it
would only broadcast unencrypted passwords with nobody listening. Now
assuming I create a virtual route that looks like an ordinary route via
IPsec (or any encrypted tunnel, even ssh), the next step would be to
find a way to force a static route over a particular interface for all
traffic going to this particular cvs machine. As a matter of fact, it is
ok if everything to that machine is forced over the tunnel. I suppose if
I manually ran an ssh command or scp or sftp to that machine's ssh port,
I would use the regular route, since there is no reason to encrypt
through an already encrypted route (since telnet is disabled on the
remote end, general telnet over the tunnel won't work).

> 
> The private key case is worse, because you have to delete all copies
> of the public key, which might be many machines.

Yes, I like the idea of only accepting particular keys, but I strongly
dislike having those keys be sufficient to get in without further
challenge. Anything that memorizes my pass is a "bad thing", unless the
memorized pass also depends on a route that itself needs my intervention
to bring it up. This is where I say I could accept pserver or ssh-agent
if-and-only-if the route to the remote machine is itself guaranteed to
require my intervention.

D. Stimits, stimits at idcomm.com

> 
> Rob
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug