freenx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



> On Tue, 2006-01-24 at 15:57, Maciej ?enczykowski wrote:
>
>> I've read through the thread you provided and I'm not convinced.  Indeed
>> it still seems like a bad design decision to me.  Why isn't the normal ssh
>> authentication good enough for NX?
>
> I think the idea was to have a minimally-privileged program that
> can't do anything but provide a tunnel.

I'm not sure I understand you there - isn't ssh already an encrypted 
tunnel provider with authorization?  What more do we need?

>> And if there is some need for a
>> different authentication than it should still - also support normal ssh by
>> default for all the other cases - like mine - where it's not needed.
>
> That's probably possible if you want to work at it.

Hmm, this would probably be a lot easier for someone who understands the 
code - and would require modifications to the (nomachine) nxclient as 
well.

> I don't see why all the components of the server couldn't run as you if 
> you trust them not to delete your files - unless sessions for different 
> users share a cache of some sort.

At least for freenx the server runs as you anyway - if I understand the 
way the code works - the NX user is used 'only' for authorization.
Maybe this has some deeper sense for the NX nomachine server???

And why can't we just have:
-- on the server:
a) a normal sshd server
b) an installed nxserver 'binary'
-- on the client:
c) a normal ssh client
d) an nxclient 'binary' which would call "ssh user@server nxserver"
==OR EVEN==
e) a patched ssh client with special commandline switch which would allow
"ssh -NX user@server" to allow X forwarding through the NX protocol?


FURTHERMORE!!!!  THE WAY I SEE IT the FREENX server has a BIG HOLE if 
using the nomachine standard keys.  Does the Nomachine server have the 
same hole? don't know.

private.key contains a privatekey which allows login to nx account - if 
your server accepts the nomachine standard keys than this is the key 
distributed with the nomachine nxclient.

$ ssh -i private.key -L 1111:localhost:631
Last login: Wed Jan 25 00:35:15 2006 from gaia.ifj.edu.pl
7 -- /var/log/nxserver.log -- HELLO NXSERVER - Version 1.4.0-44 OS (GPL)
7 -- /var/log/nxserver.log -- NX> 105

here we let it be, and in a different terminal

$ telnet localhost 1111
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
Host: localhost

HTTP/1.1 200 OK
Date: Tue, 24 Jan 2006 23:39:32 GMT
Server: CUPS/1.1
...etc...

<HTML>
<HEAD>
         <TITLE>Common UNIX Printing System</TITLE>
...etc...

Hmm - we're through the firewall! and we can connect to ANY port that the 
server is allowed to connect to (both on the server and in the 
local network).  We can use this to connect to the SMTP port and send mail 
as if from localhost - in effect we've an open relay.

Is the nomachine server vulnerable? don't know - but the freenx server IS.

Furthermore we can cause a DoS - how many open ssh sessions can your 
computer support before it runs out of resources etc?  The
"ssh -i private.key nx@server" command can be spawned multiple times and 
left to idle - there's no decent timeout (at least in freenx, I've had a 
connection opened for 8 minutes).

SSH has a means to protect against too many unauthorized connections - but 
since these connections are authorized (as user nx), this protection 
doesn't kick in.

In otherwords using default nomachine keys we can burrow a freenx server 
in authorized idle'ing nx connections - even if they can't do anything 
they're still wasting resources.

(Comments from the thread you recommended seem to suggest the nomachine 
server is immune to port forwarding, but haven't had  the opportunity to 
test this).


Where does the problem come from?  It comes from reinventing the wheel...

SSH exists.  SSH works.  SSH is used everywhere to authorize a user to a 
remote server.  NX uses SSH.  Why doesn't it use SSH like anybody else, 
like rsync for example, like sftp, etc?  Why does it do it differently.

Now, I love NX - the performance is remarkable.  I'm writing this mail in 
CentOS42 pine (from dag) in xterm in gnome in freeNX in nomachine nxclient 
in twm in X11 in Fedora Core 2.  It works awesome.  But authorization 
seems to be messed up - or at least _overcomplicated_.

I don't see nx requiring anything ssh doesn't already provide.

The way I see it ssh should be extended to accept extra switches:

-NX: X forwarding through NX protocol
-print: tunnel printer via portforwarding
-sound: tunnel sound...
...

I think all the stuff to make this a reality already exists - it's just a 
matter of putting it together now.  Now that sounds like a project...

Cheers,
MaZe.

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux