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. _______________________________________________ distcc mailing list [EMAIL PROTECTED] http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
