SSH Compression - Block Deduplication

Dan Kaminsky dan at doxpara.com
Wed Sep 14 14:20:47 EST 2011



Sent from my iPhone

On Sep 13, 2011, at 9:07 PM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Tue, Sep 13, 2011 at 10:27 PM, Dan Kaminsky <dan at doxpara.com> wrote:
>>> NX's security model is much better, and you can review it. But all the
>>> freeware versions of NX are abandonware, and many of them do rude
>>> things to dead farm animals in the process. Do not get me *started* on
>>> the Google code published "neatx" toolkit. And *all* of them rely on
>>> the older GPL published NX from NoMachine.
>>> 
>>> I did have some concerns about their default NX private/public key
>>> management for the original SSH connection as the "nx" user, to open
>>> the session, but that can actually be replaced pretty easily if you're
>>> concerned.
>> 
>> SSH provides an excellent security model for X; I wouldn't object at all to
>> tearing the security out of NX *or* VNC and making either of them dependent
>> on what SSH provides.
> 
> Dan, NX *uses* SSH. It has a dedicated "nx" user with an sshd on an
> alternative port, with a public/private user key pair and host key
> management, dedicated back end that manages passing along
> authentication via normal sytem enabled means, such as anything
> supported by PAM, to the individual user authentication.
> 
> Basically, the X-Windows compression and user management is already
> done. If someone wants to write it from scratch, they can try, but I
> don't recommend it. And X is one of the few SSH access techniques
> where bandwidth squeezing is most helpful.

I'm sure NX isn't impossible to deploy, but its dependencies (including the nx user) do form a barrier to entry.

Meanwhile, ssh -X just works.

What's basically being talked about, is leveraging ssh user auth instead of leaving users to NX to multiplex. It's not necessarily a better approach, but it might potentially be simpler, and thus distributable by default (which NX has not been).

Of course it's possible that licensing prevents direct integration, in which case I'd imagine the client using a XCompressConmand provider and the server opening a channel to a serverside binary. Less elegant, though. 

What I think everyone can agree on, is that it's technically feasible to compress X better. Whether it's interesting to do so, is another story.


More information about the openssh-unix-dev mailing list