[distcc] FAQ entry for distcc + ssh
tim at digitalbrain.com
Mon Sep 30 13:27:01 GMT 2002
I took a look at the FAQ, and noticed this bit:
> /It would be nice to run over ssh/
> Yes, it would. There is some framework code in place and it will be
> supported soon.
> For the time being, you can use port forwarding as a stop-gap, which
> will at least keep things encrypted on the network. There are at least
> two major problems with this, though: any local user on the client can
> run arbitrary commands on the server, and you must configure TCP
> access control on the server.
You can get around this (definitely with ssh2, and prob with ssh1 as
well, if you fudged the command bit to a sleep, or similar), by putting
something like this in the authorized_keys file for the ssh key in question:
command="/bin/true",permitopen="127.0.0.1:4200" ssh-rsa AAAAB3Nza.....
And then running "ssh -N -L 4201:127.0.0.1:4200" on the client box. No
commands can be executed, and only the named port can be connected to...
> Rough measurements by Aaron Lehmann and Martin Pool (1
> <http://lists.samba.org/pipermail/distcc/2002q3/000230.html>, 2
> <http://lists.samba.org/pipermail/distcc/2002q3/000231.html>) seem to
> show that SSH should be feasible, although of course not as efficient
> as plain TCP.
Indeed, we used it for quite a while as an inhouse system. It's worth
changing the default cipher - 3des is pretty greedy on CPU cycles...
It may well also be a win to turn on compression - probably worth
> The initial implementation will probably simply just run ssh for every
> connection. Opening an ssh connection is pretty expensive, so this may
> not be very practical. A better implementation would be to hoard
> connections from each client to each server. This should not be too
> hard to implement by having a long-lived client process. A small
> amount of server support will be required too.
This could also be achieved simply using 'fsh' (I think I may have
suggested this already - apologies if I have). From the Apt description:
Description: Fast remote command execution over rsh/ssh/lsh
The problem: logging in to a remote system with a cryptographic
solution such as lsh or ssh takes time, due to the computationally
expensive key exchanges that occur when the connection is established.
It is common to trigger a lot of remote logins while using remote CVS,
which makes it painfully slow compared to having the repository
The solution: reuse the secure tunnel once it has been established.
fsh is a drop-in rsh-compatible replacement for ssh that automatically
reuses ssh tunnels.
More information about the distcc