<br><tt><font size=2>> I did go over the documentation here, but I still
have problems:<br>
> <br>
> </font></tt><a href=http://wiki.centos.org/HowTos/FreeNX><tt><font size=2>http://wiki.centos.org/HowTos/FreeNX</font></tt></a><tt><font size=2>
</font></tt>
<br><tt><font size=2>> <br>
> I followed this guide because I wanted to use different keys:<br>
> <br>
> </font></tt><a href="http://techblog.tgharold.com/2009/01/setting-up-freenxnx-on-centos-5.shtml"><tt><font size=2>http://techblog.tgharold.com/2009/01/setting-up-freenxnx-on-centos-5.shtml</font></tt></a><tt><font size=2><br>
> <br>
> No luck here either. I still get that message. My
SSHD_Config <br>
> specifies to allow the user nx and my user. The authorized_keys2
<br>
> file in /var/lib/nxserver/home/.ssh is owned by nx:root and has <br>
> chmod of 600. My user's ~/home/.ssh is owned by user:user and
has <br>
> chmod of 600. Both authorized_keys2 files have the nxserver
public <br>
> key in them.<br>
> <br>
> I'm still not sure why it's denying access when I can SSH via <br>
> terminal using a private key without issue.<br>
> <br>
> Logs don't seem to contain much either...<br>
</font></tt>
<br>
<br>
<br><tt><font size=2>I think you're getting mixed up ( by the sound of
it )</font></tt>
<br>
<br><tt><font size=2>FreeNX sessions are by default set up as follows :-</font></tt>
<br>
<br><tt><font size=2>1/ Initial ssh connection to form a tunnel</font></tt>
<br><tt><font size=2>from</font></tt>
<br><tt><font size=2> nxclient
to FreeNX server</font></tt>
<br><tt><font size=2>as user "nx" using</font></tt>
<br><tt><font size=2>either</font></tt>
<br><tt><font size=2>the default nomachine key pair ( already in the client
)</font></tt>
<br><tt><font size=2>or</font></tt>
<br><tt><font size=2>a new one generated by nxkeygen</font></tt>
<br><tt><font size=2>which</font></tt>
<br><tt><font size=2>requires the nxclient (prive) key to be updated to
match the</font></tt>
<br><tt><font size=2>new (public) one added to </font></tt>
<br>
<br><tt><font size=2> /var/lib/nxserver/home/.ssh/authorized_keys</font></tt>
<br>
<br>
<br><tt><font size=2>2/ once this has happened, the default is to log in
as the user</font></tt>
<br><tt><font size=2>via the "nx" tunnel using the user-name
and password entered</font></tt>
<br><tt><font size=2>into the nxclient.</font></tt>
<br>
<br><tt><font size=2>This is carried out by a local ssh on the FreeNX server</font></tt>
<br><tt><font size=2>i.e. to 127.0.0.1</font></tt>
<br><tt><font size=2>using</font></tt>
<br><tt><font size=2>password authentication,</font></tt>
<br><tt><font size=2>which ssh session</font></tt>
<br><tt><font size=2>is then redirected back along the tunnel to the nxclient.</font></tt>
<br>
<br>
<br><tt><font size=2>You can't use your keypair on the server for this
login</font></tt>
<br><tt><font size=2> instead
of password authentication</font></tt>
<br><tt><font size=2>because</font></tt>
<br><tt><font size=2>you aren't yet logged into the server at this stage,</font></tt>
<br><tt><font size=2>only</font></tt>
<br><tt><font size=2>sitting at the far end of a tunnel owned by user nx.</font></tt>
<br>
<br>
<br><tt><font size=2>A way round this, called PASSDB uses a SEPARATE key
pair</font></tt>
<br><tt><font size=2>which IS available to the tunnel set up account, ie.
user nx,</font></tt>
<br><tt><font size=2>which</font></tt>
<br><tt><font size=2>means the public key of this separate key pair has
to be added</font></tt>
<br><tt><font size=2>to your authorized_keys file</font></tt>
<br><tt><font size=2>allowing</font></tt>
<br><tt><font size=2>user nx to log in locally over ssh in as your username</font></tt>
<br><tt><font size=2>and</font></tt>
<br><tt><font size=2>redirect that ssh session back down the tunnel to
your client.</font></tt>
<br>
<br><tt><font size=2>PASSDB still uses your username and password tho to
make sure</font></tt>
<br><tt><font size=2>you are who you say you are, but the separate key
isn't removed</font></tt>
<br><tt><font size=2>from your authorized_keys file and anyone getting
into the nx</font></tt>
<br><tt><font size=2>account can use it to log in as anyone else.</font></tt>
<br>
<br><tt><font size=2>You also now have TWO password databases to keep in
sync</font></tt>
<br><tt><font size=2> ( or keep out
sync )</font></tt>
<br>
<br>
<br><tt><font size=2>The "advantage" of this mess is that the
sshd can be set not to have </font></tt>
<br><tt><font size=2> passwordAuthentication
yes</font></tt>
<br><tt><font size=2>which is not a good idea to have enabled if the sshd
is accessible</font></tt>
<br><tt><font size=2>from the Internet</font></tt>
<br><tt><font size=2>especially</font></tt>
<br><tt><font size=2>on port 22, where you can reliably expect to have
a sucession of</font></tt>
<br><tt><font size=2>script kiddies scan you,</font></tt>
<br><tt><font size=2>and</font></tt>
<br><tt><font size=2> try a few hundred "common user name"/silly
password"</font></tt>
<br><tt><font size=2>"brute force" combos every 15 mins 24 hours
a day.</font></tt>
<br>
<br><tt><font size=2>Try it if you don't believe me.</font></tt>
<br>
<br><tt><font size=2>Ether you have to turn off logging from sshd or</font></tt>
<br><tt><font size=2>see the logs full of :-</font></tt>
<br><tt><font size=2> Failed password
for invalid user pete from a.b.c.d</font></tt>
<br><tt><font size=2>etc</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>A better way in my view is to have ONE sshd on port
22 on your</font></tt>
<br><tt><font size=2>external interface set to key pair only 9 no root
etc)</font></tt>
<br><tt><font size=2>and</font></tt>
<br><tt><font size=2>ANOTHER sshd listening only on 127.0.0.1 localhost
set to</font></tt>
<br><tt><font size=2> PasswordAuthentication
yes</font></tt>
<br>
<br><tt><font size=2>You can filter usage with</font></tt>
<br><tt><font size=2> AllowGroups
freenxusers admins</font></tt>
<br>
<br>
<br>
<br><tt><font size=2>You seem to have</font></tt>
<br><tt><font size=2>neither</font></tt>
<br><tt><font size=2> PASSDB set
up</font></tt>
<br><tt><font size=2>or</font></tt>
<br><tt><font size=2> your sshd accepting
PasswordAuthentication</font></tt>
<br><tt><font size=2>which</font></tt>
<br><tt><font size=2>would explain your error messages</font></tt>
<br>
<br><tt><font size=2>What exactly have you done ?????</font></tt>
<br>
<br><tt><font size=2>Maybe you could sanitize your sshd_config and node.conf</font></tt>
<br><tt><font size=2>and send them over . . .</font></tt>
<br>
<br>
<br>
<br>
<br>
<br>