Re: [gentoo-user] Hosted server as distcc machine

["Boyd Stephen Smith Jr." <bss03@volumehost.net>]

On Wednesday 22 March 2006 17:10, Grant <emailgrant@gmail.com> 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 shell_account@server 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