freenx

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



>> Which is of course totally screwed in the NX protocol.  What the hell 
>> for does it need an nx user for?  Pretty much nothing.  Indeed nothing 
>> at all.

> I'd say it is much, much better than trying to re-invent
> a different secure connection protocol.

Okay: let's evalute what it does and what it could do and explain to me 
how the current situation is better.

It currently logs in via ssh and privatekey to nx@servermachine, after 
which it takes the user supplied user/password combo and passes it to the 
nxserver which uses them to ssh user@localhost and passes the password. 
Effectively we're logged in as user@servermachine.  Furthermore sometimes 
the freenx server makes a mess of things and leaves around files which 
only nx (thus root) can delete making further use of nx impossible without 
root intervention.

Why can't we have: the client gets user/password combo (or even a 
privatekey for the user!) and ssh's directly into user@servermachine. 
Effectively we've achieved the same thing, except we've no need for an nx 
account and if freenx makes a booboo a user can clean out it's temporary 
files by himself.

>> It could just as well ssh directly into your account via ssh user@host 
>> /usr/bin/nxserver.

> The real login does not have to run over ssh or use encryption.
> That is optional and a waste of CPU if not needed.

I don't get this comment? We're running ssh on top of ssh - isn't that 
wasteful in and of itself? (is this only in freenx?)

The only use the 'nx' account design decision has is making stuff harder 
for the administrator.

>> But so much on bad design decisions.
>
> It's not that bad compared to a lot of other ways they might
> have tried to ensure that the real user password exchange is
> encrypted.

Sure they could have screwed up worse, but normal ssh already allows a 
user to login with user/password combo - and everything is encrypted.

And of course they could have used a different protocol or designed their 
own instead of ssh - that would have been a bigger mess.

> The nomachine server always uses the same key for for the nx user and 
> trusts the shell program to not permit anything but the next stage login 
> to happen.  That eliminates the key-setup issue that you have with the 
> freenx variation which builds new keys during the install on each 
> server.

OK, truthfully I don't trust the shell program to not permit anything 
else.  Why can't we leave authentication up to ssh?  Stop all the already 
ironed out bugs out of ssh from having an opportunity to show up in the 
nxserver shell?  Again what do we gain?

I'm lost... is there something I'm not seeing?
Maybe this is partly due to being freenx and not the nomachine server. 
But frankly I still don't see why the NX server - which _DOES_ not require 
any special priveledges can't run as the user you want to log in as.  Does 
it require special priveledges (which? what for?)

Enlighten me, please.

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