> > > > Is there anything wrong with > > > > making a remote machine [a] distcc system? > > > > > > Not really, but you do need to realize that distcc doesn't guarantee > > > that jobs will be sent to the remote machines and will not prevent > > > jobs from being run locally. > > > > Good to know for sure. > > I was kinda surprised at the behavior. I was sort of hoping distcc would > just sort of "hold" the job until a slot opened up. It's not a big deal, > but something that you should be aware of. > > > > Also, distccd is a wide-open security hole. > > > > Not good. The remote machine I'm considering using distcc on is my > > business's server. I can't have break-ins there. > > Then I don't suggest distccd open to the internet (or any public network) > -- it was never designed to be secure. It's not a big target ATM for > hackers AFAIK, but it's still a large vulnerability. > > > > It's probably better to use distcc over ssh, using an ssh-agent and > > > PKI authentication. > > > > So using distcc along with ssh and PKI would be sufficient to prevent > > the rooted box mentioned above? > > It won't /completely/ prevent it. But, it will bring down the risk > significantly. Random attackers will no longer simply be able to spoof > IPs, instead the attacker will have to have the username and private key > of a user known to have shell access. (Malicious users or a healthy dose > of paranoia may force you to limit shell access anyway.) > > > How would ssh and PKI be set up in > > the workflow? It isn't mentioned here: > > http://www.gentoo.org/doc/en/distcc.xml > > Yeah, I started with that document, too. distcc/ssh/PKI is not covered, > since it is moderately advanced. > > 1) On the server, set up the shell account that will use distcc via ssh. > 2) On the client, generate the private key for that account and use > ssh-copy-id to give the server the public key. Please, please, give your > private key a good passphrase -- I've seen some people use an empty > passphrase! > 3) On the server, if possible, disable password logins to force the use of > the private key for that user. > 4) On the client, add a line like [EMAIL PROTECTED] to your > distcc_hosts. You can leave out the shell_account part if you want to log > in to the server as the user invoking distcc, but you must include the @ > since that's how distcc knows the host is accessed via ssh. You can add > a :port section if the server runs ssh on a port other than 22; You can > add a /limit section (after or in lieu of the :port section) to have the > client limit the number of distcc jobs that will be sent to the server > 5) Prior to invoking distcc on the client, start an ssh-agent (I prefer the > keychain "meta-"agent.) and optionally add your private key to the agent. > (If you don't start an agent, each compile that goes to an ssh host will > ask for a password -- very troublesome with parallel make; If you don't > add your private key to the agent, you'll get prompted for the passphrase > the first time you need a key -- still moderately troublesome.) > > There is no need to run distccd on the server at all. You /will/ need > sshd. > > Remember, since these are standard ssh connections, you'll limit the number > of simultaneous jobs on the server by limiting the number of simultaneous > ssh logins -- not by using any distccd settings. > > As far as compile jobs from cron, I just don't suggest them. If you /have/ > to use them, have them compile locally. If they /have/ to use your distcc > hosts, you'll have to figure out some way to give your cron jobs access to > your private key without compromising it's security -- not an easy feat.
That's great, thank you! It sounds like this would make the remote distcc idea as secure as ssh and I won't have to worry about the fact that distcc wasn't built with security in mind. Is that right? Also, I'm the only user on all of my systems so it would be OK to use plain ssh without PKI right? - Grant -- gentoo-user@gentoo.org mailing list
