[prev in list] [next in list] [prev in thread] [next in thread]
List: freenx-knx
Subject: Re: [FreeNX-kNX] FreeNX with SSH key authentication fails
From: chris () ccburton ! com
Date: 2009-11-10 1:09:05
Message-ID: OF00F97504.8B24A263-ON8025766A.0003BAAA-8025766A.000653A6 () ccburton ! com
[Download RAW message or body]
This is a multipart message in MIME format.
This is a multipart message in MIME format.
--=_alternative 0006539E8025766A_=
Content-Type: text/plain; charset="US-ASCII"
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
> ________________________________________________________________
--=_alternative 0006539E8025766A_=
Content-Type: text/html; charset="US-ASCII"
<br>
<br><tt><font size=2>Les Mikesell <lesmikesell@gmail.com> wrote on
09/11/2009 23:51:53:<br>
<br>
> Jeremy Wilkins wrote:<br>
> > This doesn't solve the public key authentication issues that
he mentioned.<br>
> > <br>
> > It just changes the NX user public key which ALL users need in
their NX<br>
> > client after the changes you suggest. Paul wants the users
to authenticate<br>
> > via public key which is entirely different.<br>
> <br>
> What other users do is irrelevant to NX - if they want to log in <br>
> directly with ssh and their own key they can, but they won't be running
NX.<br>
> <br>
> > Paul: The only way I know that this will work is by using
the open source<br>
> > client, with freenx in su authentication mode, but I may be wrong.
As far<br>
> > as I know the NoMachine client won't work for that yet. That
may change in<br>
> > the near future hopefully. Meanwhile what Les mentioned
is nearly as<br>
> > secure.<br>
> <br>
> The sequence of things is that NX makes the initial ssh connection
as <br>
> the nx user, using its key, then the real user login and password
are <br>
> passed encrypted over that connection - they are not handled separately
<br>
> by sshd again.</font></tt>
<br>
<br>
<br><tt><font size=2>FreeNX uses ssh with authorized keys and a private
key file to log in</font></tt>
<br><tt><font size=2>user nx.</font></tt>
<br>
<br><tt><font size=2>This user ( nx ) has /usr/bin/nxserver as its login
shell.</font></tt>
<br>
<br><tt><font size=2>FreeNX then does a local ssh login via nxserver, but
this time as the user's </font></tt>
<br><tt><font size=2>account, using password authentication, over the encrypted
link.</font></tt>
<br>
<br><tt><font size=2>BUT</font></tt>
<br>
<br><tt><font size=2>This means you have to have an ssh daemon listening
with password authentication</font></tt>
<br><tt><font size=2>enabled.</font></tt>
<br>
<br><tt><font size=2>This is not so good on port 22 on an outside IP address
as you will be blasted </font></tt>
<br><tt><font size=2>with script attacks and you will be relying on the
user's passwords.</font></tt>
<br>
<br><tt><font size=2>A couple of user mode ways using suid etc are available,
but in my view the most </font></tt>
<br><tt><font size=2>reliable way, (if a little messy), is to have a first
sshd with password disabled</font></tt>
<br><tt><font size=2>for the first user=nx public key connection, and then
run a second sshd listening</font></tt>
<br><tt><font size=2>only on 127.0.0.1 on another port with password enabled,
which means ssh password</font></tt>
<br><tt><font size=2>authentication is not available externally.</font></tt>
<br>
<br><tt><font size=2>If you are using an exposed IP address then it is
better to have port 22 listening only</font></tt>
<br><tt><font size=2>on localhost with password enabled, and have the \
"external" sshd listening on another </font></tt>
<br><tt><font size=2>port.</font></tt>
<br>
<br><tt><font size=2>I use this arrangement for an external sshd anyway
even without FreeNX.</font></tt>
<br>
<br><tt><font size=2>You will need two sshd_config files in /etc/ssh/,
two start lines in /etc/init.d/sshd</font></tt>
<br><tt><font size=2>with the appropriate sshd_config file selected with
the command line switch </font></tt>
<br><tt><font size=2>-f /etc/ssh/sshd_configNX for the second sshd.</font></tt>
<br>
<br><tt><font size=2>You will need to make sure the password enabled sshd
is configured in </font></tt>
<br><tt><font size=2>/etc/nxserver/node.conf line 51 if you choode to have
that one not on port 22</font></tt>
<br>
<br>
<br><tt><font size=2>NOTE:- If you have any interface exposed to the Internet
with sshd listening</font></tt>
<br><tt><font size=2>and FreeNX enabled with the default key, then anyone
with the default key can</font></tt>
<br><tt><font size=2>try a brute force attack !!!</font></tt>
<br>
<br><tt><font size=2>It's not very likely, but if someone doesn't like
you they may well try.</font></tt>
<br>
<br><tt><font size=2>So if you use external FreeNX connections, change
your FreeNX keys.</font></tt>
<br>
<br>
<br><tt><font size=2><br>
> <br>
> -- <br>
> Les Mikesell<br>
> lesmikesell@gmail.com<br>
> ________________________________________________________________<br>
> Were you helped on this list with your FreeNX
problem?<br>
> Then please write up the solution in the FreeNX Wiki/FAQ:<br>
> <br>
> </font></tt><a href="http://openfacts2.berlios.de/wikien/index.php/BerliosProject:FreeNX_-_FAQ"><tt><font \
size=2>http://openfacts2.berlios.de/wikien/index.php/BerliosProject:FreeNX_-_FAQ</font></tt></a><tt><font \
size=2><br> > <br>
> Don't forget to check the NX Knowledge
Base:<br>
> </font></tt><a \
href=http://www.nomachine.com/kb/><tt><font \
size=2>http://www.nomachine.com/kb/</font></tt></a><tt><font size=2> <br>
> <br>
> ________________________________________________________________<br>
> FreeNX-kNX mailing list --- FreeNX-kNX@kde.org<br>
> </font></tt><a \
href="https://mail.kde.org/mailman/listinfo/freenx-knx"><tt><font \
size=2>https://mail.kde.org/mailman/listinfo/freenx-knx</font></tt></a><tt><font \
size=2><br> > ________________________________________________________________<br>
</font></tt>
--=_alternative 0006539E8025766A_=--
________________________________________________________________
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
________________________________________________________________
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic