1 |
> > > > Is there anything wrong with |
2 |
> > > > making a remote machine [a] distcc system? |
3 |
> > > |
4 |
> > > Not really, but you do need to realize that distcc doesn't guarantee |
5 |
> > > that jobs will be sent to the remote machines and will not prevent |
6 |
> > > jobs from being run locally. |
7 |
> > |
8 |
> > Good to know for sure. |
9 |
> |
10 |
> I was kinda surprised at the behavior. I was sort of hoping distcc would |
11 |
> just sort of "hold" the job until a slot opened up. It's not a big deal, |
12 |
> but something that you should be aware of. |
13 |
> |
14 |
> > > Also, distccd is a wide-open security hole. |
15 |
> > |
16 |
> > Not good. The remote machine I'm considering using distcc on is my |
17 |
> > business's server. I can't have break-ins there. |
18 |
> |
19 |
> Then I don't suggest distccd open to the internet (or any public network) |
20 |
> -- it was never designed to be secure. It's not a big target ATM for |
21 |
> hackers AFAIK, but it's still a large vulnerability. |
22 |
> |
23 |
> > > It's probably better to use distcc over ssh, using an ssh-agent and |
24 |
> > > PKI authentication. |
25 |
> > |
26 |
> > So using distcc along with ssh and PKI would be sufficient to prevent |
27 |
> > the rooted box mentioned above? |
28 |
> |
29 |
> It won't /completely/ prevent it. But, it will bring down the risk |
30 |
> significantly. Random attackers will no longer simply be able to spoof |
31 |
> IPs, instead the attacker will have to have the username and private key |
32 |
> of a user known to have shell access. (Malicious users or a healthy dose |
33 |
> of paranoia may force you to limit shell access anyway.) |
34 |
> |
35 |
> > How would ssh and PKI be set up in |
36 |
> > the workflow? It isn't mentioned here: |
37 |
> > http://www.gentoo.org/doc/en/distcc.xml |
38 |
> |
39 |
> Yeah, I started with that document, too. distcc/ssh/PKI is not covered, |
40 |
> since it is moderately advanced. |
41 |
> |
42 |
> 1) On the server, set up the shell account that will use distcc via ssh. |
43 |
> 2) On the client, generate the private key for that account and use |
44 |
> ssh-copy-id to give the server the public key. Please, please, give your |
45 |
> private key a good passphrase -- I've seen some people use an empty |
46 |
> passphrase! |
47 |
> 3) On the server, if possible, disable password logins to force the use of |
48 |
> the private key for that user. |
49 |
> 4) On the client, add a line like shell_account@server to your |
50 |
> distcc_hosts. You can leave out the shell_account part if you want to log |
51 |
> in to the server as the user invoking distcc, but you must include the @ |
52 |
> since that's how distcc knows the host is accessed via ssh. You can add |
53 |
> a :port section if the server runs ssh on a port other than 22; You can |
54 |
> add a /limit section (after or in lieu of the :port section) to have the |
55 |
> client limit the number of distcc jobs that will be sent to the server |
56 |
> 5) Prior to invoking distcc on the client, start an ssh-agent (I prefer the |
57 |
> keychain "meta-"agent.) and optionally add your private key to the agent. |
58 |
> (If you don't start an agent, each compile that goes to an ssh host will |
59 |
> ask for a password -- very troublesome with parallel make; If you don't |
60 |
> add your private key to the agent, you'll get prompted for the passphrase |
61 |
> the first time you need a key -- still moderately troublesome.) |
62 |
> |
63 |
> There is no need to run distccd on the server at all. You /will/ need |
64 |
> sshd. |
65 |
> |
66 |
> Remember, since these are standard ssh connections, you'll limit the number |
67 |
> of simultaneous jobs on the server by limiting the number of simultaneous |
68 |
> ssh logins -- not by using any distccd settings. |
69 |
> |
70 |
> As far as compile jobs from cron, I just don't suggest them. If you /have/ |
71 |
> to use them, have them compile locally. If they /have/ to use your distcc |
72 |
> hosts, you'll have to figure out some way to give your cron jobs access to |
73 |
> your private key without compromising it's security -- not an easy feat. |
74 |
|
75 |
That's great, thank you! It sounds like this would make the remote |
76 |
distcc idea as secure as ssh and I won't have to worry about the fact |
77 |
that distcc wasn't built with security in mind. Is that right? Also, |
78 |
I'm the only user on all of my systems so it would be OK to use plain |
79 |
ssh without PKI right? |
80 |
|
81 |
- Grant |
82 |
|
83 |
-- |
84 |
gentoo-user@g.o mailing list |