SSH Compression - Block Deduplication

[Nico Kadel-Garcia]

On Wed, Sep 14, 2011 at 12:20 AM, Dan Kaminsky <dan at doxpara.com> wrote:

>> 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.

Mostly. Many X servers for non-UNIX and Linux systems are norrrible
and expensive, and the NX "client" with the embedded X server is very
good by comparison (and free).  And the variety of extremely poorly
managed X configurations creates tremendous security issues. The
common use of "xhost +", for example, to allow multiple user access
has been a popular security bad habit for many years. And the NX
server provides access control over the number of X sessions and
authorized users, separate from the list of users who have normal
shell access, even restricting the number of sessions per user and
allowing graceful reconnection to the *same* X sessions if a temporary
interruption occurs. VNC permits that, but quite badly, and individual
users can conflict with each other for the same port.

This level of control is very is very useful for shared servers, where
users have a bad tendency to leave their X sessions behind,
unattended, from multiple clients.

> 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).

True. Only the older GPL versions have been available to even try to
port to OpenBSD, which I might take a shot at if I can find the time.
Unfortunately, I don't see any bundles for the new version 4.x for any
of the BSD (unless you count MacOs as a FreeBSD variant).

Too bad it's not under GPL anymore. The ability to port across
platforms has been a very useful aspect of such licenses.

> 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.

*Interesting* is perhaps not the point.  *Useful*, and *feasible*, are
stronger points. A customized client with a built-in X server, such as
VNC or NX use, has historically been effective and has avoided the
protocol mangling necessary for optimizing SSH or SSL further. I just
think that NX has done a better job, already, than any reasonably
competent single developer can achieve, even if they're as smart as,
for example, me.