On 22 Jul 2003, Grahame Bowland <[EMAIL PROTECTED]> 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 __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
