[FreeNX-kNX] connection to freeNX server with dsa keys ?

[Fabian Franz]

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

Am Dienstag, 15. März 2005 16:36 schrieb Gian Filippo Pinzari:
> Fabian Franz wrote:
> > You still need a password for "su - username". Its just that you no
> > longer use SSH to login the user with a password, but su.
>
> I thought it was something more elaborated, like for example by
> using a PAM module. Using su - + the password provided by the user
> has been experimented by NoMachine in the past but we went for
> using a DSA key for accessing the node because:
>
> - The DSA key allows both local and remote nodes with exactly
>    the same mechanism.
>
> - The DSA key forces the user to execute nxnode, instead of
>    arbitrary commands.

Yes, I see the advantages, but we had a FR for a server, where password logins 
are not allowed via SSH. But the Requester still wanted to use PAM 
authentication and not add all users to the internal DB.

>
> - As you are using the password provided by the user, the server
>    can't login to the node without a user requesting some sort of
>    operation. This prevents nxserver from performing maintenance
>    tasks (unless nxserver stores the password, that I don't think
>    it's the case).

As most users of FreeNX use PAM authentication anyway, we (in FreeNX) have 
lost this advantage long ago.

>
> - Some OSes don't allow 'su -' when not from a TTY.

Well, I think with "expect" we do have a tty. Thats why we can pass the 
password to normal ssh or su.

>
> - It may require that the system administrator puts the nx user
>    in groups that are a bit dangerous from the security point of
>    view.

I don't understand, why you need to be in the wheel group to do that.

Anyway:

SU authentication is disabled by default. If a administrator enables it, he 
must also add the nx user to the specified group.

>
> That said, I agree that offering this as an option can be a good
> idea. Just su-ing to a different user is surely straightforward.

> Anyway using the system passwords is inherently insecure as it
> makes very, very difficult to implement a layer of separation bet-
> ween system accounts and NX accounts, something you need if you
> are going to "rent" your server.

Yes, we are talking about the "big image" again :-).

>
> The way NX should work is by separating completely the virtual
> NX environment from the host system, including authentication. A
> better way to handle this would be a PAM module that integrates
> with NX and allows the nx user to become users that are in a NX
> DB, a possibility that we'll have to investigate in future. 

I'm still not sure how I want to handle those things in the long run.

I think at the present moment, most administrators are quite happy with the 
concept of allowing access for all "system users" to also use NX.

Talking about that. 

Would you be generally willing to add a flag to nxclient to login as the 
actual user and run the server as this users, thus loosing all advantages of 
central session management?

I think in FreeNX to have this work, it would be not more than setting the 
session directory to $HOME/.nx/db/.

But we need to have client support for it to be worth implementing.

Perhaps running a command like:

ssh user at host nxserver --user --login

And nxserver would look into SSH_ORIG_COMMAND to find out the command and just 
if its user and login, start the shell as the user.

I know that I'm going in the opposite direction, but as you once wrote that 
you thought about adding this feature to your NX server, I just wanted to ask 
again :-).

And yes: Even if I now do know plan9 (and got some great ideas from it), I 
still might not be able to get the big picture your are drawing, yet.

cu

Fabian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCN5yMI0lSH7CXz7MRAhNJAJ9cOaVgLa/iiuaYL9NqWWqdhq2pNwCfcNkU
Zscs35ku4Zw74F+LhYiu0Os=
=mkrf
-----END PGP SIGNATURE-----