From: jdugan@es.net (Jon Dugan)
Subject: [sup-talk] mime-view hook
Date: Thu, 23 Apr 2009 11:14:48 -0700 [thread overview]
Message-ID: <1240509574-sup-3576@junction.es.net> (raw)
In-Reply-To: <20090423175336.GX11701@pimlott.net>
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 <jdugan at es.net> | GTalk: jdugan.esnet
ESnet Network Engineering Group | http://www.es.net/
Lawrence Berkeley National Laboratory | http://www.lbl.gov/
next prev parent reply other threads:[~2009-04-23 18:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-23 1:11 Jon Dugan
2009-04-23 12:47 ` William Morgan
2009-04-23 17:53 ` Andrew Pimlott
2009-04-23 18:14 ` Jon Dugan [this message]
2009-04-23 22:59 ` Andrew Pimlott
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1240509574-sup-3576@junction.es.net \
--to=jdugan@es.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox