Excerpts from Andrew Pimlott's message of Thu Apr 23 10:53:36 -0700 2009: > On Wed, Apr 22, 2009 at 06:11:40PM -0700, Jon Dugan wrote: > > dumbplumbd listens on port 9937 on your local system for requests. > > dumbplumb > > sends requests to dumbplumbd. ssh port forwarding is used to proxy the two > > together, eg: > > > > ssh -R 9937:localhost:9937 remotehost > > You probably realize this, but... A well-known port doesn't work for > this, because you need one plumber per display session. So the SSH > forwarding needs to use the right plumber on this end and establish a > corresponding session on the other end.
That is definitely and issue and I should probably add that to the README. However in practice it doesn't seem to be a problem for me, I only forward the port for the first connection to my sup box. When I leave a display I log out of the sup box thus freeing the well known port for the next display I sit at. (Or if I forget I can log in and kill that ssh process by hand.) However, this whole fiasco is part of the reason I call it dumb. There is also a significant security issue which is anyone on the sup box can send a dumbplumb request if they know what port to talk to. In my case this is a fairly minor risk as I am the only person who uses my sup box. This too is part of the reason I call it dumb. > The obvious model for this is SSH agent forwarding. You'd have a > PLUMBER_SOCK variable containing the path to a unix socket, and ssh > would create a unix socket on the other end, forward it there, and set a > new PLUMBER_SOCK variable. The obstacle is, the SSH developers haven't > shown any interest in making the SSH agent forward mechanism availble to > others. See for example > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294148 > > If you don't do this, you'll have plumbers stepping on each other, or > you'll have to manage ports manually. I've wanted this kind of forwarding for a long, long time. I was unaware of the patch listed there. I'll have to take a look. This would be especially cool if it was forwardable like the agent socket, since sometimes I have to ssh through intermediate boxes. (But see my ssh-gw script for a cute trick for getting around this: http://bitbucket.org/jdugan/ssh-gw/). The unix socket forwarding would make the whole thing much, much cleaner. One hack to work around the port collision problem is to enable environment variable forwarding (see SendEnv in ssh_config(5)) and use that to dynamically choose a port per session. This could be used to forward unix domain sockets by combining this with something like socat. This, however, starts to become a huge tangle of duct tape and bailing wire... Also SendEnv has some security implications. In short I'd love something less dumb, but for now this scratches an itch. Jon -- Jon M. Dugan <jdu...@es.net> | GTalk: jdugan.esnet ESnet Network Engineering Group | http://www.es.net/ Lawrence Berkeley National Laboratory | http://www.lbl.gov/ _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
