<div class="gmail_quote">On Thu, Jul 25, 2013 at 11:28 AM, <span dir="ltr"><<a href="mailto:chris@ccburton.com" target="_blank">chris@ccburton.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<br><tt><font>> I did go over the documentation here, but I still
have problems:<br>
> <br>
> </font></tt><a href="http://wiki.centos.org/HowTos/FreeNX" target="_blank"><tt><font>http://wiki.centos.org/HowTos/FreeNX</font></tt></a><tt><font>
</font></tt>
<br><tt><font>> <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" target="_blank"><tt><font>http://techblog.tgharold.com/2009/01/setting-up-freenxnx-on-centos-5.shtml</font></tt></a><tt><font><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></div><tt><font>I think you're getting mixed up ( by the sound of
it )</font></tt>
<br>
<br><tt><font>FreeNX sessions are by default set up as follows :-</font></tt>
<br>
<br><tt><font>1/ Initial ssh connection to form a tunnel</font></tt>
<br><tt><font>from</font></tt>
<br><tt><font> nxclient
to FreeNX server</font></tt>
<br><tt><font>as user "nx" using</font></tt>
<br><tt><font>either</font></tt>
<br><tt><font>the default nomachine key pair ( already in the client
)</font></tt>
<br><tt><font>or</font></tt>
<br><tt><font>a new one generated by nxkeygen</font></tt>
<br><tt><font>which</font></tt>
<br><tt><font>requires the nxclient (prive) key to be updated to
match the</font></tt>
<br><tt><font>new (public) one added to </font></tt>
<br>
<br><tt><font> /var/lib/nxserver/home/.ssh/authorized_keys</font></tt>
<br>
<br>
<br><tt><font>2/ once this has happened, the default is to log in
as the user</font></tt>
<br><tt><font>via the "nx" tunnel using the user-name
and password entered</font></tt>
<br><tt><font>into the nxclient.</font></tt>
<br>
<br><tt><font>This is carried out by a local ssh on the FreeNX server</font></tt>
<br><tt><font>i.e. to 127.0.0.1</font></tt>
<br><tt><font>using</font></tt>
<br><tt><font>password authentication,</font></tt>
<br><tt><font>which ssh session</font></tt>
<br><tt><font>is then redirected back along the tunnel to the nxclient.</font></tt>
<br>
<br>
<br><tt><font>You can't use your keypair on the server for this
login</font></tt>
<br><tt><font> instead
of password authentication</font></tt>
<br><tt><font>because</font></tt>
<br><tt><font>you aren't yet logged into the server at this stage,</font></tt>
<br><tt><font>only</font></tt>
<br><tt><font>sitting at the far end of a tunnel owned by user nx.</font></tt>
<br>
<br>
<br><tt><font>A way round this, called PASSDB uses a SEPARATE key
pair</font></tt>
<br><tt><font>which IS available to the tunnel set up account, ie.
user nx,</font></tt>
<br><tt><font>which</font></tt>
<br><tt><font>means the public key of this separate key pair has
to be added</font></tt>
<br><tt><font>to your authorized_keys file</font></tt>
<br><tt><font>allowing</font></tt>
<br><tt><font>user nx to log in locally over ssh in as your username</font></tt>
<br><tt><font>and</font></tt>
<br><tt><font>redirect that ssh session back down the tunnel to
your client.</font></tt>
<br>
<br><tt><font>PASSDB still uses your username and password tho to
make sure</font></tt>
<br><tt><font>you are who you say you are, but the separate key
isn't removed</font></tt>
<br><tt><font>from your authorized_keys file and anyone getting
into the nx</font></tt>
<br><tt><font>account can use it to log in as anyone else.</font></tt>
<br>
<br><tt><font>You also now have TWO password databases to keep in
sync</font></tt>
<br><tt><font> ( or keep out
sync )</font></tt>
<br>
<br>
<br><tt><font>The "advantage" of this mess is that the
sshd can be set not to have </font></tt>
<br><tt><font> passwordAuthentication
yes</font></tt>
<br><tt><font>which is not a good idea to have enabled if the sshd
is accessible</font></tt>
<br><tt><font>from the Internet</font></tt>
<br><tt><font>especially</font></tt>
<br><tt><font>on port 22, where you can reliably expect to have
a sucession of</font></tt>
<br><tt><font>script kiddies scan you,</font></tt>
<br><tt><font>and</font></tt>
<br><tt><font> try a few hundred "common user name"/silly
password"</font></tt>
<br><tt><font>"brute force" combos every 15 mins 24 hours
a day.</font></tt>
<br>
<br><tt><font>Try it if you don't believe me.</font></tt>
<br>
<br><tt><font>Ether you have to turn off logging from sshd or</font></tt>
<br><tt><font>see the logs full of :-</font></tt>
<br><tt><font> Failed password
for invalid user pete from a.b.c.d</font></tt>
<br><tt><font>etc</font></tt>
<br>
<br>
<br>
<br><tt><font>A better way in my view is to have ONE sshd on port
22 on your</font></tt>
<br><tt><font>external interface set to key pair only 9 no root
etc)</font></tt>
<br><tt><font>and</font></tt>
<br><tt><font>ANOTHER sshd listening only on 127.0.0.1 localhost
set to</font></tt>
<br><tt><font> PasswordAuthentication
yes</font></tt>
<br>
<br><tt><font>You can filter usage with</font></tt>
<br><tt><font> AllowGroups
freenxusers admins</font></tt>
<br>
<br>
<br>
<br><tt><font>You seem to have</font></tt>
<br><tt><font>neither</font></tt>
<br><tt><font> PASSDB set
up</font></tt>
<br><tt><font>or</font></tt>
<br><tt><font> your sshd accepting
PasswordAuthentication</font></tt>
<br><tt><font>which</font></tt>
<br><tt><font>would explain your error messages</font></tt>
<br>
<br><tt><font>What exactly have you done ?????</font></tt>
<br>
<br><tt><font>Maybe you could sanitize your sshd_config and node.conf</font></tt>
<br><tt><font>and send them over . . .</font></tt>
<br></blockquote><div><br>I am using PASSDB and PasswordAuthentication is set to "no". After the guides both failed and spending hours trying minor tweaks, I set it up almost exactly like my Ubuntu servers (which have no problems). Still the same issue. It doesn't work on CentOS for some reason. I also changed the default SSH port to begin with. By doing so, I had to edit an IPTables rule to allow it on the different port because CentOS doesn't detect this. Anyways, I know it's not a problem with IPTables because I disabled them while testing. <br>
<br>The public key generated using this command (from the blog linked in my previous message):<br><br>ssh-keygen -t dsa -N '' -f /etc/nxserver/client.id_dsa.key<br><br>Is included in both the nx user's home .ssh authorized_keys2 file and my user's .ssh authorized_keys2 file. PassDB authentication appears to work because a bogus login and password returns an authentication denied message... it appears it's the public key part failing, and I don't know why. After all, it does log me in using PASSDB, but fails when trying to use the key... any idea?<br>
</div></div>