[FreeNX-kNX] FreeNX with SSH key authentication fails

chris at ccburton.com chris at ccburton.com
Tue Nov 10 01:09:05 UTC 2009


Les Mikesell <lesmikesell at 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 at 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 at kde.org
>       https://mail.kde.org/mailman/listinfo/freenx-knx
> ________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20091110/9a2e847b/attachment.html>


More information about the FreeNX-kNX mailing list