[FreeNX-kNX] FreeNX CentOS Permission denied (publickey, gssapi-keyex, gssapi-with-mic)

[OwN-3m-All]

On Thu, Jul 25, 2013 at 11:28 AM, <chris at ccburton.com> wrote:

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

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.

The public key generated using this command (from the blog linked in my
previous message):

ssh-keygen -t dsa -N '' -f /etc/nxserver/client.id_dsa.key

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/freenx-knx/attachments/20130725/23dd15b9/attachment.html>