[distcc] Authentication patch

[Martin Pool]

On 22 Jul 2003, Grahame Bowland <grahame at arach.net.au> wrote:
> 
> Hi all,
> 
> Would a patch to add simple username and password authentication to
> distccd be taken? I was thinking of implementing a CHAP-like challenge
> response authentication scheme so the password doesn't go over the
> network in cleartext, and it would make distcc that little bit more
> secure.

You should be able to do this as a separate program that plugs in
through DISTCC_SSH.  I'm happy to add a link to the web page.  Doing
it in a separate process is pleasingly modular and avoids a distcc
protocol change.

Having said that I'm not sure it's a really good idea.  SSH has the
security features it has for mostly good reasons.

Firstly it adds a new major security boundary where there is not one
at present.  If there is a bug in your code then it might allow
somebody to break in through the authentication mechanism.  I don't
want the pressure of having to scramble to get out new security
releases, or for people to worry about whether it's a problem, and so
I didn't put this in distcc itself.

I think many programs which have tried to do even such a simple thing
have had security problems over the years and I don't want distcc to
follow, so I almost certainly wouldn't merge it.

Doing CHAP authentication would not protect against an active attacker
who can hijack your connection or observe the contents, both of which
are possible in plain TCP.  Given that hijacking the connection allows
them to completely control either machine I think you should not use
it on untrusted networks.  (OpenSSH does not allow unencrypted
connections basically for this reason, although the protocol would
support it.)

If you're thinking about using the username to switch to different
accounts depending on who connects then forget it: that would require
the server to listen as root, which I think is an outrageous risk.

> It's useful if you're on an unpredictable source address, as having the
> "distcc" service open wouldn't be such a big problem anymore.
> 
> Shouldn't add much code or protocol complexity. I'd run distcc over SSH
> but that's a lot slower.

It is slower.  Turning on LZO compression or using SSH port forwarding
makes it faster.

On one kernel-building benchmark for three machines:

  locally:                  441s
  over TCP with compr:      170s
  over SSH port forwarding: 224s
  over SSH:                 329s
  
-- 
Martin