[FreeNX-kNX] Re: got: "cannot create directory `/home/.nx'"

[Kurt Pfeifle]

On Tuesday 19 October 2004 19:06, Rick Stout wrote:
> Jean-Eric Cuendet wrote:
> 
> > I find NX very interesting. It's incredibly fast, simple to install, etc...
> > But this key thing seems too bad. What if you would have a public NX 
> > server? You must add to the authorized_keys file everyone that would 
> > like to connect? Forget it...
> > It's like if you ask every sysadmin to where you would like to connect 
> > with SSH to add your key to the authorized_keys of a machine user.
> > The best IMO is to have only one key (let the user choose) that is "not 
> > secured", but then secure the NX server like SSH is secured.
> > This way you'll avoid this key mess...
> > -jec
> 
> Key replacement can be scripted 

True.

> and having one key is not secure.

Not entirely true.

Because that key doesn't give you access yet to the server's
file system or to an NX session. 

That key just "paves the way" to get to the real NX login prompt 
(which is invisible to the user, 'cause he doesn't need to type 
the password at that stage -- it has been typed and cached when 
starting up the NX Client), which is how the real session 
authenticates and authorizes the user. 

Why was it done that way? Because to run an NX session, you need
to setup a special environment: compression libraries need to be
used (which must not interfere with the standard Xlib and other
libraries on the NX server or cause them to malfunction for 
"normally" logged in users); the nxproxy, nxnode and 
nxagent/nxviewer/nxdesktop need to be started; the connection to 
the X11/RDP/RFB servers need to be established and so on. A big 
part of this "preparation work" is done by under the credentials
of the nx special user (which uses a special shell, the "nxserver",
with a few very special NX commands, and which doesn't have access 
to a normal login or shell!)

Think of this: You could of course devise an NX architecture which
does all this under the name of the respective NX end user. But it 
would be more complicated for this end user, no? But would it be 
more secure, by not using this "semi-public" nomachine-key? After 
all, this is how we all log into remote machines.

Why not use just the standard Unix password encryption? Maybe
because it has changed? Maybe because it is now less standard
recently and less-crossplatform than SSH? Maybe because it is 
*less* secure (the older version supports usernames with only 8 
chars and lower case chars) than the "designed-for-a-reason" and
currently used "nx"-user/nomachine-key scheme?

Why not use Kerberos with NX? Yes, why not? Maybe it will come upon 
us sometime soon too? Rome hasn't been built in 7 days either... 
(pun intended).

> Period. 

Hmmm....    Sometimes the world isnt black and white only   ;-)

> What might be a better option is to code the client to allow  
> multiple keys. Create profiles that allow you to specify the key you 
> want to connect with. SSH will allow you to specify key files(-i 
> option), so this shouldn't be too hard to implement.

We agree here. This idea has been raised before and it will
be implemented sometime soon.

Cheers,
Kurt