XDMCP over SSH - a better idea (hopefully)

[Vic Lee]

Hi,

Thanks for you comments.

Actually I am already quite familar with how NX works, and supporting NX
is one of my future goals in my project grdc. Although NX is based on X
+ SSH, to me it's like a new protocol. It has it's own SSH session
commands, X compression algorithms, etc. And it does not use XDMCP at
all.

But right now I am working on XDMCP. The good thing is that XDMCP is a
standard component of X.org server, and still lots of people out there
using it. The only thing that is really necessary is security - which I
want to put in a quick enhancement inside X.org; not a workaround.

And what I want to add is quite simple - just a binary that implements
the XDMCP protocol and forward request to an existing X server, like a
proxy program.

Thanks,

Vic

On Tue, 2009-08-04 at 15:09 +0200, walter harms wrote:
> 
> Vic Lee schrieb:
> > Hi,
> > 
> > Sorry I sent this email to xorg-devel but I realized that this should be
> > a feature discussion, not yet a development discussion... So I resend it
> > here.
> > 
> > Recently I want to implement XDMCP over SSH feature when doing my
> > project. I've done some research and understand that "XDMCP uses UDP
> > that natively cannot be tunnelled over SSH", however there's a
> > well-known workaound:
> > 
> > LOCAL$ ssh -X REMOTE Xephyr :1 -query localhost
> > 
> > which query XDMCP in a remote Xephyr, then to tunnel the Xephyr window
> > using X11 forwarding. However this is not working good enough for me
> > since (1) I don't want to ask users to install Xnest or Xephyr on SSH
> > server (2) Somehow the tunnelled Xephyr window won't recognize -parent
> > argument to embed into my app - it always create a top-level window;
> > well, this could be another bug but I don't want to waste my time
> > investigating on this, since now I came up with a better solution.
> > 
> > I would like to implement a new binary, let's temporarily call it
> > "xdmcp-bin". It will fully implement the XDMCP protocol and talks to any
> > Display Manager; however, instead of creating a new X server like Xephyr
> > or Xnest does, it simply ask the Display Manager to connect to an
> > existing one (usually this is the X server that $DISPLAY is pointing to
> > - like any other X clients).
> > 
> > So here comes the real thing. :) A typical XDMCP over SSH senario would
> > be:
> > 
> > LOCAL$ Xephyr :1 (or even X :1, whatever that creates a new X server)
> > LOCAL$ export DISPLAY=:1
> > LOCAL$ ssh -X REMOTE xdmcp-bin -query localhost
> > 
> > What happen in the third line is that, "xdmcp-bin" runs on REMOTE, query
> > its Display Manager to create a new session and connect to "xdmcp-bin"'s
> > DISPLAY environment, which is a X11 tunnel that connects back to :1 at
> > LOCAL. You know what should happen next: we tunnel XDMCP session.
> > 
> > I am totally new to X.org development. I would like to get your comments
> > before I get started with this new feature.
> > 
> 
> It sounds a bit like nx or neatx, are you aware of this solutions ?
> 
> re,
>  wh
>