2

Working to set up the GnuPG keymanager for SSH and now FreeNX server on CentOS 6 and NoMachine NXclient on my new install of ArchLinux I've been reading more about keys than I've ever read before. I'm at the level of "A Postal Analogy" from Wikipedia. So, it makes perfect sense a private key is kept on the originating system and the public key is the one shared. And this message is repeated again and again:

"Once you have generated a key pair, you will need to copy the public key to the remote server [...] Note that the private key is not shared and remains on the local machine."

"The thing is that your private key must never be compromised."

However, instructions to set up NX From CentOS's FreeNX setup page (scroll down): "You will need to ssh into the server [...] Copy all the text (including the BEGIN DSA PRIVATE KEY and END DSA PRIVATE KEY lines."

From NoMachine's setup page: "Distribute the private key from the newly generated couple of keys located in the file [...] to all clients that have to be granted acccess to the specific NX server host."

The client can certainly generate its own private key.

EDIT: And... After trying to take the below comments into consideration, I reconfigured the user for nx. What's going on with the failed authentication asking for (what I expect) the public key?

NX> 203 NXSSH running with pid: 4523
NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: 192.168.2.8 on port: 22
NX> 202 Authenticating user: nx
**NX> 208 Using auth method: publickey**
NX> 204 Authentication failed.
Community
  • 1
xtian
  • 583
  • 5
  • 17

1 Answers1

1

The server needs it's own private key too, because the communication is two way. It is not all encrypted using the client's public key -- only stuff from the server to the client is done that way.

The reason is sort of obvious: if the client encrypts its transmissions using its own public key, the server would need the corresponding private key in order to decrypt it. Which defeats the point of a "private key". If the server does not have the client's private key, it can't decrypt messages made with the client's public key.

Instead, the server sends the client a public key, which the client uses to encrypt messages to the server. So the server needs its own public/private key pair -- presumably a completely different pair than the one used by the client.

The client keeps its private key private.

The server keeps its private key private.

They are not the same key.

Make sense? Note that this means that neither party can decrypt the messages it sends; only the receiver of the message can.

goldilocks
  • 86,451
  • 30
  • 200
  • 258
  • Yes. It makes sense when you say it. But the two NX pages cited talk about copying a private key from a remote system. – xtian Sep 13 '13 at 15:27
  • With NX, you are logging in as the 'nx' user over SSH, so your NX client needs a copy of the 'nx' user's private key, to use with the public key in the `authorized_keys` in the 'nx' user's homedir. – jsbillings Sep 15 '13 at 15:21
  • @jsbillings Okay, I think I follow now: there is *only one* nx user on the server. You do not create your own account, you log in as *the same* user as everybody else who uses that nx on that system. Hence, everybody has to copy *the same* nx user's private key, rather than uploading their own individual public keys. Yes? Which would also explain why it has been left publicly accessible in `/etc/nxserver/`. – goldilocks Sep 15 '13 at 17:22
  • And isn't that a *big* disconnect in the key-universe that someone should have mentioned it? – xtian Sep 15 '13 at 18:39
  • 1
    @xtian On reflection my last hypothesis is a little zany: the normative way to do that would be for everyone to upload their public key and add that to the nx user's list of `authorized_keys`. This way everyone can log in as the same user with their own key pair. So I dunno what is up in this case. – goldilocks Sep 16 '13 at 11:36