Les Mikesell <lesmikesell@gmail.com> wrote on
09/11/2009 23:51:53:

> Jeremy Wilkins wrote:

> > This doesn't solve the public key authentication issues that
he mentioned.

> > 

> > It just changes the NX user public key which ALL users need in
their NX

> > client after the changes you suggest.  Paul wants the users
to authenticate

> > via public key which is entirely different.

> 

> What other users do is irrelevant to NX - if they want to log in 

> directly with ssh and their own key they can, but they won't be running
NX.

> 

> > Paul:  The only way I know that this will work is by using
the open source

> > client, with freenx in su authentication mode, but I may be wrong.
 As far

> > as I know the NoMachine client won't work for that yet.  That
may change in

> > the near future hopefully.  Meanwhile what Les mentioned
is nearly as

> > secure.

> 

> The sequence of things is that NX makes the initial ssh connection
as 

> the nx user, using its key, then the real user login and password
are 

> passed encrypted over that connection - they are not handled separately

> by sshd again.
FreeNX uses ssh with authorized keys and a private
key file to log in
user nx.
This user ( nx ) has /usr/bin/nxserver as its login
shell.
FreeNX then does a local ssh login via nxserver, but
this time as the user's 
account, using password authentication, over the encrypted
link.
BUT
This means you have to have an ssh daemon listening
with password authentication
enabled.
This is not so good on port 22 on an outside IP address
as you will be blasted 
with script attacks and you will be relying on the
user's passwords.
A couple of user mode ways using suid etc are available,
but in my view the most 
reliable way, (if a little messy), is to have a first
sshd with password disabled
for the first user=nx public key connection, and then
run a second sshd listening
only on 127.0.0.1 on another port with password enabled,
which means ssh password
authentication is not available externally.
If you are using an exposed IP address then it is
better to have port 22 listening only
on localhost with password enabled, and have the "external"
sshd listening on another 
port.
I use this arrangement for an external sshd anyway
even without FreeNX.
You will need two sshd_config files in /etc/ssh/,
two start lines in /etc/init.d/sshd
with the appropriate sshd_config file selected with
the command line switch 
-f /etc/ssh/sshd_configNX for the second sshd.
You will need to make sure the password enabled sshd
is configured in 
/etc/nxserver/node.conf line 51 if you choode to have
that one not on port 22
NOTE:- If you have any interface exposed to the Internet
with sshd listening
and FreeNX enabled with the default key, then anyone
with the default key can
try a brute force attack !!!
It's not very likely, but if someone doesn't like
you they may well try.
So if you use external FreeNX connections, change
your FreeNX keys.

> 

> -- 

>    Les Mikesell

>     lesmikesell@gmail.com

> ________________________________________________________________

>      Were you helped on this list with your FreeNX
problem?

>     Then please write up the solution in the FreeNX Wiki/FAQ:

> 

> 
http://openfacts2.berlios.de/wikien/index.php/BerliosProject:FreeNX_-_FAQ

>   

>          Don't forget to check the NX Knowledge
Base:

>                  
http://www.nomachine.com/kb/

> 

> ________________________________________________________________

>        FreeNX-kNX mailing list --- FreeNX-kNX@kde.org

>       
https://mail.kde.org/mailman/listinfo/freenx-knx

> ________________________________________________________________