[distcc] FAQ entry for distcc + ssh

[Tim Small]

Hi,

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...

Ciphers blowfish-cbc,aes128-cbc,3des-cbc,cast128-cbc,arcfour

It may well also be a win to turn on compression - probably worth 
experimenting with...

> 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
 locally.
 .
 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.



Tim.