[FreeNX-kNX] FreeNX, SSH, and su

[Jon Severinsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

dewey hylton skrev:
> pat, fwiw i have 6 customers all using freenx (on freebsd) and in each case
> the ssh server only allows pk auth. this works perfectly well without su_auth.
> if the users are setup via "nxserver --adduser" then freenx copies its own
> self-generated keys to the user's authorized keys file, allowing nx to login
> as said user without passwords. i've never had a problem using this method.

Dear Pat and Dewey

The passdb method of authentication described above is an alternative to su
auth, but might not be the best. Think of a large corporate system already
containing hundreds of users, and no administrator knowing all passwords (as the
users change them periodically). In such an environment it would be a great
hassle to maintain a separate database with nx paswords. That is why freenx
offer two alternative methods using the system password system with different
strengths and weaknesses. These are ssh and su.
The strengths and weaknesses of the different authentication methods is:

Passdb require the maintenance of a separate password database (the user still
has to be in the unix user database, but may be disabled), and require the
pressense of a ssh key in the user home directory on all application servers.
This is managed automatically on the freenx server, and thus only matter if
loadbalancing is enabled and the application servers doesn't share home
directories (through NFS or similar). The benefits with passdb is the separate
password database (users can have different passwords on freenx and the rest of
the system) and that it works on all computers that can run freenx (no extra
requirements).

SSH authentication requires that the sshd daemon allows password authentication.
If you do not want remote users to log in with passwords, it is reportedly
possibly to enable password authentication for specific hosts only (only for the
nxserver, eg localhost on non-loadbalancing setups).
The benefits is that it does not require a separate password database, nor any
hassle with ssh keys. System passwords is used.

SU authentication does not use sshd for authentication or forwarding to the
application server. As such it *does not work with loadbalancing*. In addition
some distros (eg ubuntu) has su disabled by default, and in such case it won't
work without some hacking. In most distros a user has to be member of a special
group (wheel, users, adm, or admin depending on distro) to be allowed to use su,
and thus nx has to be member of this group for su authentication to work. The
benefits include the same as for ssh auth, as well as the removal of and
intermediate ssh connection, which in addition to not requiring password
authentication in sshd also might speed up the connection marginally (you use
unix pipes instead of the loopback ethernet card, thus you need no TCP/IP
overhead). System passwords is used.

In the default freenx setup passdb and ssh is enabled. SSH because it is the
simplest to setup (most ssh servers accept password authentication by default,
giving a "plug-n-play" feeling), and passdb because of backwards compability
with !M's nxserver.
If your sshd does not accept password authentication I recommend using su,
unless you want loadbalancing or use a su disabled distro, in which case I
recommend reconfiguring sshd. Passdb is only supported because of legacy
combability and the odd case of someone actually wanting separate passwords for
freenx.

Pat Regan skrev:
> I have two questions.  Besides RedHat/Fedora requiring the nx user to be
> in the wheel group, is there any other reason why this is not the default?
It does not work with loadbalancing and some specific distros. See above.

> Also, are there any plans to allow "real" public key authentication when
> logging into a FreeNX server?
Yes, but not anytime soon. The nx protocol does support the addition of more
authentication methods, but currently only password is implemented. To
implemented more you'll have to add support to both the client and the server,
and as there is no good oss clients to add support to (current ones is mainly
prof-of-consept clients), this won't happen without !M, and last I heard this
feature was not planed for 1.5, so perhaps next year...

I hope this clarified most (if not all) authentication questions.

Best Regards
- - Jonno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC29AyOOpxqcksWu4RAhFHAJ4tAX+0SkjYPQUFq71k+g++v2U+QACcDYvC
sovGq+HTRyWMeyTNf522qLg=
=6GHZ
-----END PGP SIGNATURE-----