On Wednesday 22 March 2006 17:10, Grant <[EMAIL PROTECTED]> wrote about 'Re: [gentoo-user] Hosted server as distcc machine': > > > 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. -- "If there's one thing we've established over the years, it's that the vast majority of our users don't have the slightest clue what's best for them in terms of package stability." -- Gentoo Developer Ciaran McCreesh -- gentoo-user@gentoo.org mailing list
