[FreeNX-kNX] nxclient and "challengeresponseauthentication no"

Fri Jan 27 14:11:33 UTC 2006

On 1/26/06, Brian Keener wrote:
> The config file doesn't exactly make it abundantly clear that "su" mode can
> be used in place of ssh authentication, or what the relationships actually
> are between any of those modes.
>
> Just based on what I know about the "su" command, and the fact that it's
> disabled by default in the config, would lead me to suspect it might not be
> the most secure method of authentication; I certainly wouldn't want joe
> schmoe being able to conceivably execute the "su" command remotely, even if
> it is just the nxserver doing the SU on his behalf..  I'm not saying that's
> the case, I'm just saying that it's not something that's immediately obvious
> as being a particularly good idea!

As the comments indicate, you are not required to place the user in
the wheel group (although some distros build su without any concept of
"wheel").  The nx user must be in the wheel group, so that he can
change to the user account.  Of course, this permits all your clueful
NX users to use su... because they own the nx login key.  In fact you
must use an other-than-NoMachine-NX-public private key, or else
everyone on the 'Net will be able to use su.

But, if you are using a NoMachine NX client, it is allowing
password-based login, giving the full capability of 'su' remotely....

Your remaining option is USERMODE_AUTHENTICATION with an alternate
client.  This allows your users to use their private key to login.

Essentially, if you have su-based login, you are allowing users with
your NX private key to "conceivably execute the "su" command remotely"
if they can guess/steal username/password.
If you enable ssh-based password login, you are allowing anyone with a
connection to port 22 to "conceivably execute the "su" command
remotely" if they can guess/steal username/password.
If you enable NX in any fashion, you are allowing anyone with a
connection to port 22 to "conceivably execute the "su" command
remotely" if they can guess/steal username/private key.

But this is common to remote login in general.  If you don't want
users executing commands remotely, either (a) pull the ethernet plug,
or (b) delete their account.

That said, you CAN configure your login scripts to block NX
connections to root, etc. so that using authorized accounts requires
(1) a user account to login remotely -or- a direct physical connection
to the console and (2) the root password.

>
> And of course, there's no "man nxclient", nxserver, freenx, knx, etc. etc.
> etc. so there's not a whole lot of documentation to go on...
>
> Brian K
>
>
> On 1/26/06, * * <richardvoigt at gmail.com> wrote:
> > On 1/26/06, ted creedon wrote:
> > > "Please ensure that SSHD on localhost accepts password authentication."
> > > The output from nxsetup seems to specifically disallow this...:
> > > see below.
> >
> > > tedc
> > >
> > > nxsetup --install --clean --purge
> > > Removing user nx ...no crontab for nx
> > > done
> > > Removing session database ...done
> > > Removing logfile ...done
> > > Removing nx home directory ...done
> > > Removing configuration files ...done
> > > Setting up /usr/NX/etc ...done
> > > Generating public/private dsa key pair.
> > > Your identification has been saved in /usr/NX/etc/users.id_dsa.
> > > Your public key has been saved in /usr/NX/etc/users.id_dsa.pub.
> > > The key fingerprint is:
> > > 65:70:a4:9f:70:83:10:98:77:c9:8c:59:f6:4d:39:df
> root at nome
> > > Setting up /usr/NX/var/db ...done
> > > Setting up /var/log/nxserver.log ...done
> > > Setting up user nx ...done
> > > Setting up known_hosts and authorized_keys2 ...Unique key generated;
> > > your users must install
> > >
> > >     /usr/NX/home/nx/.ssh/client.id_dsa.key
> > >
> > > on their computers.
> > > done
> > > Setting up permissions ...done
> > > Ok, nxserver is ready.
> > >
> > > PAM authentication enabled:
> > >   All users will be able to login with their normal passwords.
> > >
> > >   PAM authentication will be done through SSH.
> > >   Please ensure that SSHD on localhost accepts password authentication.
> > >
> >
> > You saw the line above, did you miss the line below?  freenx can also
> > use su for authentication instead of ssh.
> >
> > >   You can change this behaviour in the /usr/NX/etc/node.conf file.
> >
> > From /usr/NX/etc/node.conf.sample:
> > # This adds the usermode to the possible authentication methods
> > # Usermode means that a user can start the nxserver as his shell
> > # and connect directly to the right server via a custom client.
> > #ENABLE_USERMODE_AUTHENTICATION="0"
> >
> > # This adds the passdb to the possible authentication methods
> > #ENABLE_PASSDB_AUTHENTICATION="1"
> >
> > # This adds SSH to the possible authentication methods. For it to work
> sshd
> > # must be set up at localhost accepting password authentication.
> > #ENABLE_SSH_AUTHENTICATION="1"
> >
> > # This adds SU to the possible authentication methods. For it to work the
> > # "nx" user must be in the wheel (RedHat, Fedora) or the users group
> (SUSE)
> > # and the user logging in must have a valid shell that accepts the -c
> > # parameter.
> > #ENABLE_SU_AUTHENTICATION="0"
> >
> > So much complaining about multiple ssh servers.  So little
> > configuring.  Or did the required function disappear in a recent
> > version?
> >
> >
> > >
> > > Warning: Clients will not be able to login to this server with the
> > > standard key.
> > >          Please replace /usr/NX/share/client.id_dsa.key on all clients
> > > you want
> > >          to use with
> /usr/NX/home/nx/.ssh/client.id_dsa.key
> > >          and protect it accordingly.
> > >
> > >          If you really want to use the NoMachine key please remove
> > >          '/usr/NX/home/nx/.ssh/authorized_keys2'
> > >          and then run this script with the --setup-nomachine-key
> parameter.
> > > Have Fun!
> > > nome:~ #
> > >
> > > Brian Keener wrote:
> > > > Nobody has any thoughts on this problem?
> > > >
> > > > Brian K
> > > >
> > > >
> > > > On 1/23/06, *Brian Keener* <brikeener at gmail.com
> > > > <mailto:brikeener at gmail.com >> wrote:
> > > >
> > > >     I've got my SSH server configured to disallow password
> > > >     authentication, as an extra security measure since it's connected
> > > >     directly to the internet.
> > > >
> > > >     With "challengeresponseauthentication no" in my
> sshd_config,
> > > >     nxclient fails to make a connection.
> > > >
> > > >     How do I fix this?
> > > >
> > > >     Brian K
> > > >
> > > >
> > >
> >------------------------------------------------------------------------
> > > >
> > > >_______________________________________________
> > > >FreeNX-kNX mailing list
> > > >FreeNX-kNX at kde.org
> > > >https://mail.kde.org/mailman/listinfo/freenx-knx
> > > >
> > > _______________________________________________
> > > FreeNX-kNX mailing list
> > > FreeNX-kNX at kde.org
> > > https://mail.kde.org/mailman/listinfo/freenx-knx
> > >
> > _______________________________________________
> > FreeNX-kNX mailing list
> > FreeNX-kNX at kde.org
> > https://mail.kde.org/mailman/listinfo/freenx-knx
> >
>
>
> _______________________________________________
> FreeNX-kNX mailing list
> FreeNX-kNX at kde.org
> https://mail.kde.org/mailman/listinfo/freenx-knx
>
>
>