On Thu, Mar 19, 2009 at 5:29 PM, Joseph <email@example.com> wrote:
> On 03/19/09 13:07, Paul Hartman wrote:
>> In my sshd_config I've got:
>> PermitRootLogin No
>> RSAAuthentication no
>> PubkeyAuthentication yes
>> AuthorizedKeysFile .ssh/authorized_keys
>> PasswordAuthentication no
>> PermitEmptyPasswords no
>> ChallengeResponseAuthentication no
>> UsePAM no
>> Then in /usr/NX/etc/server.cfg I have:
>> EnableUserDB = "1"
>> EnablePasswordDB = "1"
>> then run "/usr//NX/bin/nxserver --useradd yourusername" which will add
>> that user to the NX user database as well as create/add an SSH key to
>> that user (which is only used by NX on the local machine, it will SSH
>> to itself). The password you create for this user is what you'll use
>> in nxclient when connecting to the remote machine, and the SSH key in
>> nxclient is the one that user would normally use to login to the box
>> with regular SSH.
>> If you don't use key authentication with SSH, you should be able to
>> have the two NX server options above set to 0, and use the user's
>> normal password to login. You will still need to put your NX server
>> key into nxclient (unless you use the default key which is already in
>> It is tricky to set up, but once it works it is awesome.
>> VNC or RDP easily.
> I've tried to duplicate this setting but I can only log-in with my username
> and password I created from a nxclient when I have in sshd.config
> UsePAM yes
> If I set it to no I can not log-in.
> In your last section on coping keys, I'm not sure I follow it.
> For now I used the default key that the server came with.
> What do you call nxclient?
> Is it the user account name on the server I created with "...nxserver
> --useradd joseph"?
> This command copied the nxserver key to my home ~.ssh/authorized_keys file.
In my setup I do not use passwords for SSH, or even allow them at all,
I only use the public key auth. So "UsePAM no" and the other options
gets rid of the interactive password prompt entirely.
Here is my understanding of how the NX bits all fit together:
Think of it as a 2-step connection. The first step is connecting from
the remote nxclient to the nxserver. For this step, it uses the SSH
key that you can put into nxclient. That only authenticates you as
being able to connect to the NX server, it doesn't get you into any
user files or desktops. By keeping the default NX key, anyone with NX
client can connect to your box and get to this point.
The second step, now that you are authenticated and connected to the
NX server, is connecting to the remote desktop. Only users granted
access to NX by --useradd are allowed to proceed past step 1, so even
using default NX key won't let someone in any further unless they know
your NX user's name and password. In the case of Linux remote desktops
(the usual case), the key it installed into your user's
authorized_keys is what NX server then uses to make an SSH login to
your user's desktop environment. (I believe the NX user's key is set
to only work when logging in from localhost).
NX can also be used as a proxy to connect to VNC or RDP. When the VNC
or RDP machine is on the local network of the NX server, the
connection between those two machines is very fast. Then, that VNC/RDP
is re-encoded using NX between the server and the client. Since NX's
protocol is faster over the internet, you can actually get a faster
RDP than if you had connected directly to the Windows machine using