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